Во что конвертировать огромный, сотни ГБ, CSV-файл для максимально быстрого чтения по «ключу»?

Question

[hostovik]

Есть csv, от десятков ГБ до 1 ТБ, то есть,сильно больше чем моя RAM.
В строке таблицы порядка 5 полей. Размер одного поля можно считать нефиксированным.
Число строк от 100 млн до 2 млрд. Будет именно чтение одним пользователем, никаких записей в файл.

В таблицах есть уникальное поле, "хеш". Во что мне конвертировать csv файл, чтобы максимально быстро получать доступ к строке по индексу?-
А) sql. типа postgre. удобно но эта БД поддерживает многопользовательскую запись, репликации- всё это мне не нужно, оверкилл
Б) sql типа sqllight. на малых объемах летает. но не уверен что она хорошо работает с большими файлами, в том числе сможет быстро создавать индексы
В) nosql база типа mongo?
Г) файлы с индексами - обработка python-ом
Я думаю что вариант Г) - оптимальный. или есть иные варианты? куда именно смотреть?

Comments

[Сергей Горностаев]

У MongoDB оверкилла будет ещё больше, чем у PostgreSQL.

Answer 1

[h4r7w3l1]

apache parquet

колоночный тип в бинарном формате, решение для экономичного хранения данных в частности csv таблицы.
Компрессия 1тб csv исходных порядка 80-85% = ~120гб в parquet
Скорость чтения ~ х34 раза быстрее чем raw csv файл
Благодаря колоночному типу возможно делать выборки без чтения полностью файла


но это решение под хранение / чтения данных, на счет тонкостей работы с данным форматом данных смотрите документацию, тонкостей много, возможно категорически буду противоречить поставленной задаче.

Answer 2

[Рональд Макдональд]

Во что мне конвертировать csv файл, чтобы максимально быстро получать доступ к строке по индексу?

В SQL-таблицу.
MySQL к вашим услугам. SQLite тоже подойдёт.

Comments

[hostovik]

данные тестирования бы глянуть. слишком сильное утверждение чтобы без них

[Рональд Макдональд]

hostovik, а чего сильного-то? У вас грамм примитивных данных без сложных связей, с этим и массивы в ОЗУ бы справился.

[Hemul GM]

hostovik, sqlite с проиндексированной таблицей имеет очень хорошие показатели скорости в запросах.
Грубо могу рассказать о сравнениях, которые я делал несколько лет назад, когда необходимо было сформировать БД для ФИАС. ФИАС - это огромная база данных адресов России. Государственная БД. Она предоставляется в XML или в dbf.
Когда я перенёс бд из dbf в SQLite, то скорость запросов была примерно секунд 40 (иногда до минуты), после индексации таблиц скорость запросов была около ~1-2 сек.

PS. БД ФИАС весит сейчас 7гб. (xml - 9гб, на тот момент весила 6+ гб dbf и 8+ xml))

[hostovik]

Рональд Макдональд, для 1 млрд записей даже если размер пар "ключ -значение" 100 байт, нужно 100 ГБ ram, у меня такого нет - "массивы в ОЗУ бы справился."

[hostovik]

Hemul GM, 7 гб это совсем иное. Это умещается в RAM, и диск вообще вторичен, а у меня в память не запихнуть и узкое место -диск

[Hemul GM]

hostovik, ОЗУ там не играли большой роли.

[ComodoHacker]

hostovik, Реляционные СУБД как раз оптимизированы для случая, когда все данные не вмещаются в ОЗУ. Именно так они работали всегда, за исключением последних 10 лет. А вот среди NoSQL таких — единицы.

Попробуйте SQLite, если не устроит, MySQL. Но я уверен, что SQLite справится.

Answer 3

[Алексей Уколов]

эта БД поддерживает многопользовательскую запись, репликации- всё это мне не нужно, оверкилл

В чём конкретно минус-то? Не нужно — не пользуйтесь.

Г) файлы с индексами - обработка python-ом
Я думаю что вариант Г) - оптимальный.

На каждое изменение требований потом придётся всё переделывать. Учитывая объёмы данных, лучше сразу взять что-то относительно гибкое.

Comments

[hostovik]

"эта БД поддерживает многопользовательскую запись, репликации- всё это мне не нужно, оверкилл
В чём конкретно минус-то? "
- думаю в требованиях к памяти может быть проблема. фиг знает может postgre летает на таких данных, но только например с величины RAM от 100 ГБ.

[Сергей Горностаев]

hostovik, у меня в одном из проектов PostgreSQL на стандартных настройках резво обрабатывал запросы к таблице с 23 миллиардами записей, а стандартные настройки выставлены для очень хилого железа.

[hostovik]

Сергей Горностаев, обалдеть. спасибо, удивительная информация.

[hostovik]

Сергей Горностаев, а индексы к такой таблице изначально как долго создавались?

[Сергей Горностаев]

hostovik, точно не скажу, но да, это могло бы быть проблемой, если бы у вас и частые записи в таблицу были бы.

[hostovik]

Сергей Горностаев, а на диске ваша база сколько примерно места занимала?

[Сергей Горностаев]

hostovik, 37 гигов, если мне память не изменяет. Но в ней было ещё много чего, кроме этой длиной таблицы.

[hostovik]

Сергей Горностаев, странно малый размер 37 ГБ. Ведь если у вас 23 млрд рядов, в каждом 1 байт (!) всего это уже 23 ГБ

[15432]

hostovik, может дедупликация, сжатие

[Everything_is_not_so_bad]

15432, может, 370 ГБ.

Answer 4

[WinPooh32]

Встраиваемое kv-хранилище от гугла - leveldb вам в помощь. Обертки есть почти под каждый популярный ЯП.

leveldb используется для хранения транзакций в клиенте биткоиана, а там уже, на минуточку, объем БД перевалил за 200 гигов.

Только учитывайте, что магии не будет, когда БД в RAM не вмещается, и боттлнек будет на дисковой подсистеме. Сильное ускорение будет давать быстрый ssd, особенно который nvme через pci.
Поэтому на частые запросы обмазываемся кэшами и, возможно, радуемся.

Т.к. это встраиваемое хранилище, то всю сетевую обвязку придется реализовывать самому.

Comments

[hostovik]

оч интересно. мне как раз для подобных дел. в google bigquery есть такая штука как "партицирование и кластеринг". я это к тому, что набор пар "индекс-значение" в мою RAM не влезет даже для очень короткого значения(. postgre тоже умеет делать партиции

жаль , но похоже leveldb не умеет делать партиции - https://db-engines.com/en/system/LevelDB

[WinPooh32]

hostovik, вы в вопросе не описали что вы хотите получить :)
Например, с какой частотой запросы будут и т.д.

жаль , но похоже leveldb не умеет делать партиции

Так и не должен, это же встраиваямая бд. Потому что разбиение на части используется в системах с несколькими узлами.

Вы можете сами шардировать данные, используя хеширование, это достаточно просто реализуется.

[hostovik]

речь про аналитику. то есть сидит один пользвователь и делает ручные запросы к базе, опрос еще и осмыслить надо и обычно сделать визуализацию. то есть запросы думаю ну не чаще чем раз в 10 минут "Например, с какой частотой запросы будут и т.д."

[WinPooh32]

hostovik, а разбиение для чего вам?

[hostovik]

WinPooh32, разбиение для чего? хм. я думал что индексы работают быстро если в память влезают полностью. если 2 млрд записей "ключ-значение" хотя бы по 100 байт длиной это 200 гбайт, у меня такой памяти нет,

[WinPooh32]

hostovik, leveldb построен на lsm-tree, поэтому там нет понятия "индекс".

Архитектура LSM-дерева позволяет удовлетворить запрос на чтение либо из оперативной памяти, либо за одно обращение к устройствам постоянного хранения. Запись тоже всегда быстра независимо от размеров хранилища.

Answer 5

[Viktor T2]

Lightning Memory-Mapped Database (LMDB)
Tokyo Cabinet

Answer 6

[Владимир Коротенко]

https://www.quora.com/What-tools-are-data-scientis... Посмотрите на ответы в этом топике, похоже это ваши задачи

Answer 7

[uvelichitel]

Будет именно чтение одним пользователем, никаких записей в файл.

Примерно для такого D. J. Bernstein придумал ConstantDataBase (CDB) Вот современная реализация на Python https://github.com/bbayles/python-pure-cdb (есть на PyPI)

Comments

[lukoie]

а ничо что там пишет "No random limits: cdb can handle any database up to 4 gigabytes."?

[uvelichitel]

lukoie,

Г) файлы с индексами - обработка python-ом Я думаю что вариант Г) - оптимальный

Вот современная реализация на Python https://github.com/bbayles/python-pure-cdb (есть на PyPI)

this package can produce and consume "64-bit" constant databases that don't have the usual 4 GiB restriction.