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

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

А что не так? Как правильно?

+100500 тоже самое хотел предложить.

а у тебя данные вообще без структуры? всмысле нельзя разбить csv’шку на куски, по какому-нить ключу?

у меня похожее использование - данных суммарно >10Тб, но они приходят медленно, и время - основной критерий, за сутки обычно от 100 до 1000Мб всего, в итоге данные просто лежат в xml или json, по нужде обработать ключи грузится только блок нужного дня и оттуда выдергиваются нужные строки, благо моя нужда обычно именно найти нужную строку и 5-50 соседних в обе стороны.

postgresql всем хорош, но «на круг» у меня он получается в 10-1000 раз медленее чем файлы (с учётом записи, в файл дозапись почти бесплатно, у меня запись 99% операций) + заморочки с передачей блоков туда-сюда.

А что не так? Как правильно?

Хотя бы DBF что-ли …

Есть csv, от десятков ГБ до 1 ТБ, то есть,сильно больше чем моя RAM.

Почему бы вместо CSV не использовать DBF файлы.
DBF не может быть больше 2 ГБ.
Вместо CSV 1 ТБ у вас будет 500 DBF файлов, которые по существу являются массивами.

Вместо CSV 1 ТБ у вас будет 500 DBF файлов, которые по существу являются массивами.

Ладно, 500 DBF предположим не хотите.
Но ведь можно же в txt файл добавлять строки одинаковый длины.
Вот вам и массив размером 100 ТБ.

CSV …
Скорее всего конечно вы здесь ни причем и вам такой файл получаете от какой-либо программы.
Для sqlite имеется расширение, которое позволяет в нее добавлять данные из CSV файлов.
Если на диске место есть, то разработайте демон, который периодически запускаться и конвертировать новые порции данных CSV в txt или dbf.

Но ведь можно же в txt файл добавлять строки одинаковый длины.

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

CSV достаточно удобный формат для импорта/экспорта и не имеет ограничений по размеру. Я ни разу не удивлён, что у ТС так стоит задача.

CSV достаточно удобный формат для импорта/экспорта и не имеет ограничений по размеру. Я ни разу не удивлён, что у ТС так стоит задача

Если бы был DBF или txt, содержащий строки одинаковой длины, то можно было бы без труда работать с файлом и 100 ТБ …

Если бы он таким был, то «лишние» данные используемые для выравнивания большую часть этих 100ТБ и заняли бы.

Если бы он таким был, то «лишние» данные используемые для выравнивания большую часть этих 100ТБ и заняли бы.

Зато доступ к любому полю любой строки был бы как в массиве.
Конечно речь идет о снятии данных и сохранении их.
Если бы ТС рассказал о технических требованиях, …, то можно было бы и «внятно» помочь, а так лишь одни догадки.

Если бы он таким был, то «лишние» данные используемые для выравнивания большую часть этих 100ТБ и заняли бы.

Вместо записи в CSV можно «на лету» компрессировать данные и будет файл не 1 ТБ, а 1 ГБ.

patitioning
ClickHouse вроде делает но как то под капотом, без явного указания

Там можно явно указать.

Лорчую, но там желательно ещё дату иметь.

Так то экспорт, нёбось.

XML, лол.

Вместо записи в CSV можно «на лету» компрессировать данные и будет файл не 1 ТБ, а 1 ГБ.

Но тогда не будет случайного доступа.

Щас бы провалидировать терабайт XML

Но тогда не будет случайного доступа.

Так и в CSV нет.
Как «не крути» CSV нужно преобразовать в vector + index /если скорость доступа важна/.

Щас бы провалидировать терабайт XML…

полтерабайтной xml-схемой.

Щас бы провалидировать терабайт XML

Здесь уже не по морде, а табуреткой по голове.

Пристальным взглядом.

что в этом сложного?

Пристальным

Прогретым

Мы тут для Творога стараемся, а он молчит …

Занят, валидирует. Через пару лет ответит.

Постгри без вариантов, если оракловскую БД не рассматривать.

PS

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

хех, я такой файл кусочками по 10 гигов грузил и по кусочку обрабатывал.

Уж лучше пачки csv чем пачки dbf, первый хотя бы любым говном открывается и поддержка его в 2 пинка на любом ЯП пишется. csv это если что такой txt

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

Вы недооцениваете вылизанность утилит, работающих с XML. 100G файл, лежащий на HDD:

$ time xmllint --stream --schema test.xsd test.xml
real 39m19,197s

А вдруг на тб оно экспоненциально скаканёт?

Не вижу предпосылок, замерял на 1, 10 и 100, зависимость очень линейная, 23-25 секунд на гигабайт.
Вообще, необходимость валидации вызывает у меня некоторого рода сомнения.

Вообще, необходимость валидации вызывает у меня некоторого рода сомнения.

Если валидация не нужна, значит и xml не нужен.

И у меня такое бывало, но если серьезно - ТСу по хорошему бы сложить данные на HDFS, построить external tables вокруг них в hive и забыть о существовании проблемы.

p.s. Совсем по хорошему надо ещё csv перегнать бы в parquet.

Да блин! Зачем ведосипедить неоптимальную реализацию, когда в базах это уже давно сделано.

Вот про MongoDB для таких объемов мне бы тоже было бы интересно послушать.

Просто из любопытства: сколько по времени будет строиться индекс в любой из реляционок на табличке в 2+тб?

ТСу разве что clickhouse помочь может.

В этой задаче он может пригодиться разве что в качестве промежуточного формата, индексов-то никаких нет. Просто как одинэсника джависта меня немного удручает пренебрежительное отношение к XML.

Ну ёлки-моталки, зачем тут xml? Данные плоские, неирархичные. Вполне возможно, что они создавались методом дописывания в конец (xmlю недоступному by design). Программа, которая их произвела явго не xml-ориентированная. Задача, которую тс решает - поиск записи по ключу - тоже xml не решается.

Ну ведь построится же.

Не знаю, но видел вживую базу на PostgreSQL в 300тб. Yahoo в 2008 году ещё поднимала базу на модифицированном PostgreSQL в 2ПБ. Так что в адекватные сроки скорее всего.

Я тоже видел БД такого размера, любой чих в их строну приводил к суткам потерянного времени, переключению на slave (в зависимости от организации блокировок) и всё такое прочее. В 2020 для подобных кейсов разумнее использовать hadoop. Сейчас кстати и занимаюсь миграцией очень большой и не очень известной РСУБД в туда - причины ровно те же что и описал выше. И да, для эксплуатации такого рода баз - нужен прямой контакт с их разработчиками (читай купленный саппорт) т.к. маленькие косячки имеют свойство превращаться в гигантские проблемы вместе с ростом объемов данных.

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

в MUMPS

Затаращил в SQLite 1G записей вида ключ-значение (int + text), заняло это счастье ~50 Гб. Поиск по индексу, если в кэш не попадать, с SSD занимает 25-40 мс, с HDD 150-250. Как по мне, выглядит довольно неплохо, учитывая околонулевые трудозатраты.

В 2020 для подобных кейсов разумнее использовать hadoop

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

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

С одной стороны, почти 2 часа.
С другой, я не заморачивался оптимизацией и просто добавлял по одной записи в цикле. Плюс это было на HDD, плюс журнал не был отключен. Хз, сильно ли можно было ускорить.
Алсо, после этого запустил создание индекса по колонке с текстом, там случайные гуиды набиты. На HDD отработало за 2399894ms, на SSD - хз, случайно прибил терминал с результатом, а повторять лень.

Спасибо (хоть я и не ТС).

Офтоп: у тебя в игнор-листе из профиля уже двое забаненных. А у t184256 аватарка, скорее всего уже не та, про которую ты писал (а если та, то это довольно оригинально).

Туда им и дорога.
А аватарка всё ещё та, лол.

С одной стороны, почти 2 часа. С другой, я не заморачивался оптимизацией и просто добавлял по одной записи в цикле.

Молодец.
Теперь сделай из 1ТБ CSV 1ГБ файл в котором каждая строка будет находиться в компрессированном формате и попробуй отработать тот же самый алгоритм.
Скорее всего он у тебя отработает минут за пятнадцать.

Владимир