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

Возьми PostgreSQL, реши проблему. После чего уже сравнивай и думай, что оптимальнее.

по крайней мере в 2015 писали, что в районе 1 ТБ могут быть проблемы «If you’re under 1 TB of data, Postgres will give you a good price to performance ratio» наверняка сейчас стало лучше. хотелось бы услышать от тех кто гонял такие базы

Если файл уместится в лимит файла для твоей ФС, то sqlite норм
https://www.sqlite.org/whentouse.html#:~:text=An SQLite database is limited,t....


CSV там искаропки поддерживается, поэтому ты в одну команду можешь сделать базу и проверить proof-of-concept уже сегодня.
Но я конечно не верю, что ты сможешь

вариант Г - полное Г, ибо костылишь свой велосипед на дороге, наезжанной базами данных по самое не балуйся.
с оверкилами можещь тыкать некрософт, там оверкилл прямолинейно облегчает карман и как следствие давит на жабу.
лежит куча лишних функций и ладно. а то так доиграешься до переписывания линукса на ассемблер с низкоуровневой оптмизацией…
бери любую базу засовывай туда набор твоих данных и используй без лишних мозговых завихрений или, ежеля чешется, проведи тест по скорости выборки твоих данных и выбери «лутшего».

Если статика - запихай в кликхаус

Ну, как выше сказали, PostgreSQL, и неважно про твой написанный оверкилл, ты же не будешь его юзать. Главное правильные индексы сделай под свои поля.

Теоретически можешь ещё попробовать ElasticSearch + Kibana(для красоты). Заодно побенчишь для ЛОРа лучшее из двух решений :)

вроде sqlite не умеет хеши?- "hash indexes are O(1) and Btree indexes are O(log n)

выбери «лутшего»

конфига для одной единственной опробованой бд.

Разместить в памяти (заранее подготлвить и грузить его с диска) вектор пар хэш:смещение в исходном файле (отсортированный по хэшам) и делать в нем поиск половинным делением. Если не лезет в память отмапировать с диска.

Исходный толстый файл и вектор разместить на ssd.

Если будет тормозить можно поиск по вектору переписать на плюсах.

Что подразумевается под «уметь хеши»?
Судя по описанию, это же просто готовое текстовое поле, движку ничего не надо вычислять самому для его заполнения

спасибо! звучит интересно. может уже что то сделано? «Разместить в памяти вектор пар хэш:смещение»

Конечно сделано, так БД работают:-)

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

Это меньше 100 строк кода и хорошее упражнение, если такого раньше не делали.

см для mysql - Comparison of B-Tree and Hash Indexes а sqlite вроде только B-Tree поддерживает SQLite indexes are B-Tree based. https://pythontic.com/database/sqlite/create%20index -"Что подразумевается под «уметь хеши»?

спасибо! займусь!

ClickHouse, говорят, под такие данные и создавалась.

Ну я потому и сказал что не верю, что вы сможете.
Вместо того, чтобы прямо сейчас потратить всего 20 минут и проверить на практике, вы увлеклись теоретизированием.

поскольку у меня индекс в память не влезает - желательно бы еще и patitioning уметь делать. ClickHouse вроде делает но как то под капотом, без явного указания на что делить. например у google bigquery можно сделать партиции по дням, удобно же.

https://cr.yp.to/cdb.html

Если в sqlite отключить транзакции то быстро

А ты рядом индекс сделай :) с помощью awk и sed :)

rocksdb?

https://cr.yp.to/cdb.html

No random limits: cdb can handle any database up to 4 gigabytes.

Это идеальный кейс для ScyllaDB

Это если у ТС есть ssd’шка на которой можно выделить раздел с xfs :). Но да, быстрее scylla сейчас мало что есть.

Ещё хороший вариант - lmdb

ScyllaDB

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

Разумеется, сначала надо именно sqlite и postgress попробовать. И другие решения И уж сильно потом (или ежели очень руки чешутся) можно велосипед свелосипедить.

Лучший велосипед, имхо, такой: Получить пары хеш-смещение, отсортировать по хешу, положить в файл в виде записей равной длины, искать двоичным поиском (или поиском по хешу, у Кнута всё есть). Я такое даже на баше делал.

docker run scylladb/scylla

clickhouse? key/value запросы? мыши кололись но кликхаус не тормозит :)

ОП:

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

Это ж логи по описанию. Какой-такой кей-валуй? )

Г) файлы с индексами - обработка python-ом

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

docker

Это еще что за зверь? Сколько узлов этого зверя надо настроить и запустить, чтобы прочитать локальный файл?

так вопрос то был какой?)

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

Если советуешь ClickHouse то посчитай хотя бы какую granularity надо выставить чтоб и файл засечек в память влезал и чтоб оно 50кб*8000 с диска не поднимало на каждый запрос по индексу.

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

А вообще ты не сказал какая…

…локальность запросов будет. Какой сценарий использования - последовательный доступ вперед или назад по индексу, случайный доступ, специально подобранный наихудщий для построенного индекса доступ?

Плюсую кликхаус.

Оптимальный - это тот, при котором у тебя меньше телодвижений будет.

И это варианты А, Б, В. Какой выбрать? Какой быстрее применишь. Я бы взял постгрес, потому что могу быстро.

Если хочется экстравагантного - modin. В pandas’e однозначно упрёшься по раме и скорости.

Я бы тупо взял и сравнил варианты А и Б. И написал бы на ЛОРе о результатах.

Только не «sqllight», а sqlite.

И поскольку я не уверен, как такой файл будет жеваться стандартной импортилкой, возможно, целесообразно набросать свою, в два потока (чтобы она адекватно отдавала информацию о прогрессе, по которой можно сделать вывод, сколько ещё осталось ждать, 10 минут или двое суток). Но это не точно, возможно, что и стандартная постгряшная серверная COPY нормально справится.

Оптимальный - это тот, при котором у тебя меньше телодвижений будет.

Это оптимизация первого запроса - как быстро будет выполнен первый запрос (включая настройку-запуск всех необхоимых узлов).

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

Быстрый поиск по гитхабу выдал https://github.com/BurntSushi/xsv

Не читал, но…

Rust. Работает с сырым csv (нет бесконечно долгого импорта базы!), умеет строить индекс.

Может так оказаться, что данные прекрасно сжимаются в десятки-сотни раз. Тогда есть шанс провернуть трюк с zram или аналогами.

свою, в два потока (чтобы она адекватно отдавала информацию о прогрессе, по которой можно сделать вывод, сколько ещё осталось ждат

Для этого есть pv и pv -d <pid>.

индекс это номер?

тогда как уже сказали создаёшь индекс смещений - и тогда для чтения i-строки читаешь с [i] смещения по [i+1] смещения не включая.

для однородности при генерации индекса добавляешь лишнее нулевое поле - смотрящее за конец последнего кортежа

тогда чтение i- сsv строки

есть fseek(pos(i)), read(pos(i+1)-pos(i))

т.е если ещё более в низ то два чтения

если размер смещения это n То

fseek(fileofindex,i*n)
indexes=read(fileofindex,n*2)
fseek(rawcsv,indexes[0])
data=read(rawcsv,index[1]-index[0])

Решал подобную задачу. Использовал Postgres.

Возможно эксперты по СУБД поправят, но для больших объёмов при импорте часто лучше отключить индексы и пересоздать после наполнения, чем импортировать с подключенным индексом.

А если оно всё в транзакции или вообще COPY, то сама СУБД не догадается соптимизировать? Ведь пока транзакция не завершена индекс не нужен, это можно доказать.

Это если в лоб брать сырой pandas, у data scientists целая куча инструментов для обработки данных, которые не влазят в память.

«Куча инструментов» - это spark и всё что работает вокруг него, но судя по вопросу у ТСа нет под рукой кластера hadoop’a.

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

Вы морду уже набили «создателю» таких CSV?