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

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

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

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

но есть риски повредить весь файл, но в only read опускается этот момент
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
Zoominger
@Zoominger
System Engineer
Во что мне конвертировать csv файл, чтобы максимально быстро получать доступ к строке по индексу?

В SQL-таблицу.
MySQL к вашим услугам. SQLite тоже подойдёт.
Ответ написан
эта БД поддерживает многопользовательскую запись, репликации- всё это мне не нужно, оверкилл
В чём конкретно минус-то? Не нужно — не пользуйтесь.

Г) файлы с индексами - обработка python-ом
Я думаю что вариант Г) - оптимальный.
На каждое изменение требований потом придётся всё переделывать. Учитывая объёмы данных, лучше сразу взять что-то относительно гибкое.
Ответ написан
WinPooh32
@WinPooh32
Stack Overflow answer searching expert
Встраиваемое kv-хранилище от гугла - leveldb вам в помощь. Обертки есть почти под каждый популярный ЯП.

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

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

Т.к. это встраиваемое хранилище, то всю сетевую обвязку придется реализовывать самому.
Ответ написан
@Viktor_T2
python developer
Lightning Memory-Mapped Database (LMDB)
Tokyo Cabinet
Ответ написан
firedragon
@firedragon
Senior .NET developer
https://www.quora.com/What-tools-are-data-scientis... Посмотрите на ответы в этом топике, похоже это ваши задачи
Ответ написан
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
Будет именно чтение одним пользователем, никаких записей в файл.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы