AlekseySQLЕсть 50 ГБ текстовой информации (csv- формат). Для ускорения обращения я перегнал ее в двоичные файлы (выполнив преобразования из текста в нужные типы данных), получив 33 ГБ. В итоге скорость чтения увеличилась в 50/33 раз, т.е. узким местом является не необходимость напрягать процессор для конвертации из текста, а только работа с жестким диском.

В первом вашем шаге вы отказались от текстового представления данных и перешли к двоичному и
это дало производительность в 50/33 (пять третьих чтоли?) раз. В целом - это правильное направление
но только для тех данных которые почти всегда NOT NULL. Для множества строк содержащих вакуум
подобное преобразование могло дать обратный эффект (одно из полей было VARCHAR(255) но реально
из них использовался полный размер только 1 раз а остальные строки не превышали 10-20 символов).
И вы-бы потеряли перформанс на дисковых чтениях "пустоты".

Второй поинт - где вы говорите о том что узкое место - жесткий диск 80% правильный. Это я могу просто
говорить про любую СУБД и выигрывать пари в большем количестве споров. Почти всегда I/O узкое место
за исключением специальных In-memory dbms.

AlekseySQLНе могу поверить, что это правда, а всё SQL- программирование не более чем бутафория.
Хуже чем ложь может быть только полу-правда. На самом деле SQL программирование как было так и осталось.
Просто были пересмотрены "универсальные" подходы 20-го века. И к ним добавили специализированные
подходы которые исключали некоторые реляционные операции (NoSQL) но при этом добавляли гарантии
того что документ к примеру всегда денормализован (MongoDB) и лежит физически консолидировано на диске.

По поводу статьи на Хабре. Я ее не читал полностью. Но по поводу column-oriented-dbms. Это компромисс
между OLTP и аналитикой с "перекосом" в сторону аналитики. Тоесть вы теряете перформанс будущих
inserts/updates за счет того что нужно поддерживать вертикальную организацию данных но получаете
более экономный режим чтения. И даже не чтения конкретной строки а агрегации (sum/avg/count/min/max)
групп строк.

Кстати подобного эффекта можно ближе достичь если рациональнее разложить колонки в обычной DBMS.
Здесь принцип един. Мы можем разойтись лишь в цифрах. На сколько % больше или быстрее? ХЗ.
Надо делать макет и моделировать. Как вариант - положить ваши 3 горячие колонки в отдельную
табличку. И обеспечивать синхронность через триггеры или mviews.

Кстати по поводу макетов. Я много лет наблюдаю работу DBMS Oracle и убеждаюсь в том что нет универсальной
пули которая всегда подойдет к любым данным + к нагрузке. Поэтому все кто в топике будут вам убедительно советовать
использовать "свою любимую DBMS" или DBMS о которой они 5 минут назад прочитали в Хабре - лжецы.
Они подходят безответственно потому что не им потом разгребать issues - а вам.

Не верьте им.

Чему нужно верить? 1) Нужно взять вашу DBMS и загрузить туда вашу табличку.
2) Нужно смоделировать workload. Тоесть создать программу-симулятор которая будет
максимально близко. Близко настолько насколько это возможно грузить чтениями
вашу табличку. 3) Замерять среднее время на каждом классе реквестов.

После этого можно приступать ко 2-й фазе. Собственно к оптимизации. Это процесс
кропотлиый и сложный. Он - уравнение со многими неизвестными. И вобщем-то дальше
говорить о нем рано. Надо дождаться от вас цифр.

Если у вас вообще нет сведений о workload то - мои поздравления. Мы с вами не сможем
в топике разработать подход который вас спасет.

Ну и конечно-же я повторю слова Джонатана Льюиса. Он говорит - Вы должны "знать" ваши данные.
Тоесть на уровне бизнеса понимать где есть внутренние зависимости и перекосы (skew) в области
статистики. К примеру одно значение foreign key может заполнять 99% строк. Этого невидно
на реляционной диаграмме никогда. Но как знаток системы вы должны знать этот факт
и предотвращать бесполезные планы которые включают к примеру инексную выборку
этого магического ключа.

На "чём" смоделировал.

Arm79Можно составной индекс делать, по нужным колонкам, тогда данные будут браться из листьев индекса.

И в MS SQL (про другие не знаю) есть возможность добавлять к индексу значения неиндексных столбцов (create index ... include ...)
Автор пишет
Думаю надо попробовать записывать данные не массивом структур, а структурой массивов. Тогда при чтении можно будет "перепрыгивать" ненужные данные. У меня в среднем 1 файл занимает 700 кб и содержит ~7 полей, т.е. 100 кб на поле. Если учесть, что ssd читает страницами по 4 кб, то подобные пропуски ненужных данных могут привести к повышению производительности.
Рассмотрим тривиальные кейсы.
1) Автор делает аналитику по 1-2-3 столбцам (hotfield1, hotfield2, hotfield3). В таком случае (ох как я люблю это делать... додумывать
за автора постановки и названия... это не шутка!) можно :


и в запросах указать оптимизатору что мы рекомендуем INDEX_FAST_FULL_SCAN. И таблица уходит из плана.
Profit.
2) Делаем копию. Маленькую табличку


Profit.

AlekseySQLmaytonНа "чём" смоделировал.

Я не моделировал, а УЖЕ написал программу для реальных данных. И после ее написания увидел прирост в скорости чтения только за счет сокращения размера данных (а не за счет отсутствия конвертации из csv в уже готовые двоичные данные).

Сейчас уже написал процедуры сохранения данных по столбцам с возможностью хранить количество повторяющихся данных (чтобы уменьшить размер там где данные часто повторяются). Завтра проверю какая у таких данных скорость записи / чтения / размер.
Когда я говорил о моделировании - я имел в виду моделирование нагрузки на конкретную DBMS.

Ты ведь поднял топик по выбору DBMS. Было-бы странно если-б мы моделировали только С++ приложения. Верно?

Arm79AlekseySQLпропущено...


MS SQL- темная сторона силы :)

Наименование БД не критично. Если требуется над данными совершать много действий, я бы выбрал хранение в БД. Если обработка потоковая, то БД не нужна
Потоковая обработка на С++ (а ведь мы находимся в С++) предполагает простые алгоритмы.
Когда мы единовременно обрабатывает только 1 dataRow а после обработки выбрасываем
ее из алгоритма и переходим к следующией со спулом в файл или stdout. Как актор. Или как Rest.

Но если вам нужно сгенерировать отчот с Group By/Order By или не дай бох с оконными функциями
- то complexity вашего решения лавинообразно возрастает. Я могу себе представить SQL отчот
с исходником на 1-2 скролла экрана. Но я не могу себе представить аналогичный ему исходник
С++ с аналогичной бизнес-постановкой. Особенно в части поддержки и развития.

Я не вижу темы сравнения пока. Сравнение предполагает перечислимое множество вариантов.

AlekseySQLWhite OwlА ниче что у нас есть специальный форум "Сравнение СУБД"?

У меня достаточно широко стоит вопрос, включая файлы и различные форматы типа dbf, xml... Не думаю, что эти варианты там можно обсудить.
В твоей задаче xml не дает никаких преимуществ. Это тот же csv по роду доступа.

По поводу dbf. Скорее всего не взлетит.
Программные продукты такие как
Dbase, clipper, e. T. C. Создавались в эпоху 32 битного железа и софта со всеми вытекающими последствиями. Нельзя открыть файл размером больше 2 гб. И тому подобное.

Если под dbf ты имел в виду другое - то уточни что.

Нам нужны хоть какие-то цифры.
АлексейSQL. Сделай пожалуйса в консоли:

$ cp file.csv /dev/null

И сообщи нам сколько это заняло времени в секундах.