LINUX.ORG.RU

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

 , , ,


0

3

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

В таблицах есть уникальное поле, «хеш». Во что мне конвертировать csv файл, чтобы максимально быстро получать доступ к строке по индексу?-

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

Б) sql типа sqllight. на малых объемах летает. но не уверен что она хорошо работает с большими файлами, в том числе сможет быстро создавать индексы

В) nosql база типа mongo?

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

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


Ответ на: комментарий от anonymous

А толку, ТС всё равно слился.
Мя таки из любопытства прикрутил bulk insert, и время импорта снизилось до 35 минут.

izzholtik ★★★
()
Ответ на: комментарий от izzholtik

Мя таки из любопытства прикрутил bulk insert, и время импорта снизилось до 35 минут.

После перезагрузки компьютера попробуйте сделать копию 1 ТБ файла и вы поймете «где затык».

Владимир

anonymous
()
Ответ на: комментарий от izzholtik

Можно еще было взять ssdb (leveldb с интерфейсом redis). Тестить лень, правда.

anonymous
()
Ответ на: комментарий от izzholtik

Затык в объёме свободного места, вестимо.

Конечно пошутили.
Не зря CDX Microsoft сделала а-ля «сжатый» …

Владимир

anonymous
()

2all:

топик-стартеру по какому ключу индекс то нужен - по тому у которого уникальный хэш - т.е само поле хэш-уникально

ибо чёт ваще не ясно в чём затруднение то?

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

ибо чёт ваще не ясно в чём затруднение то?

Затруднение в выборе модного базворда.

anonymous
()
Ответ на: комментарий от AntonI

Да по всем. Производительность, надежность и прочие. Нет я полагаю, можно потратить время на исследования, анализ, оптимизацию и отладку. Но будешь ли ты этим заниматься? БД разрабатывают на протяжении нескольких лет, и всякие камни подводные там смотрят и т.д. Поэтому для работы я бы взял готовое решение, а если хочется потренироваться, то только тогда пилил бы сам.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

Как правило узкоспециализированное решение работает в области своей специализации лучше чем общее. В этом смысле БД это общее решение.

Задача ТС достаточно примитивна что бы хорошо сделать ее на коленке за относительно небольшое время.

AntonI ★★★★★
()
Ответ на: комментарий от rumgot

Нормально делай - нормально будет(с)

Если у ТС какие то специфические требования, то это может оказаться быстрее чем настройка существующей БД.

AntonI ★★★★★
()
Ответ на: комментарий от romanlinux

Эта ерунда с мелкими то таблицами не работает, куда ей терабайты.

stave ★★★★★
()

Скан в любой базе будет напряженным для таких данных. Поэтому обычно и первичный ключ задают не хешем, а составным осмысленным - чтобы можно было держать данные отсортированными и помогать скану - смотри устройство hbase, clickhouse.

stave ★★★★★
()

К выше перечисленному можно добавить dask. Он умеет разбивать большие датафреймы на сегменты и делать ленивые вычисления. Поддерживает разные форматы, в т.ч. и csv. Просто попробуй разные решения и выбери наиболее быстрое и простое.

yvv ★★☆
()
Последнее исправление: yvv (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.