База данных на 32 гигабайта, как сделать?

Question

[Galaxy773]

У меня есть 2^32 (4 миллиарда) записей, общим размером ~32 гигабайта, мне нужно как то быстро поместить их в какую нибудь базу данных, чтобы потом проверять на наличие в ней значения из программы. Как можно такое быстро реализовать? Если бы размер был < 16 гигабайт, я бы просто загружал в озу из файла.

Comments

[Drno]

использовать NVME ?)
или ПК с бОльшим количеством памяти?)

[Rsa97]

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

[d'Ivan]

На чём остановился выбор в итоге?

Answer 1

[alexalexes]

Если цель хранения данных - логирование состояния приложения, и это нужно делать только локально, то подойдет SQLite. Если нужно общее хранилище данных для нескольких экземпляров приложения, или нужно иметь общий доступ к данным по сети, то нужно брать СУБД по-функциональнее, например, PostgreSQL или MySQL (желательно 8 версии).
Для решения данной задачи нужно изучить следующие моменты:
1. Какими средствами администрировать СУБД: чтобы создать пользователя, создать базу данных, создать необходимые таблицы, просматривать данные.
2. Как подключиться к СУБД из программной среды.
3. Как выполнять запросы вставки, выборки по условию, с параметрами запроса средствами SQL с использованием библиотеки работы с СУБД из программной среды.

Comments

[Galaxy773]

Основной вопрос в том, как быстро занести все 4 миллиарда записей в базу данных

[alexalexes]

За какой-то разумный срок они занесутся, даже если их записывать построчно или пакетами по пару тысяч за запрос (часы, пару суток).
Другой вопрос, насколько быстро у вас образуется такой объем данных. Если в течение тех же часов или суток или даже в несколько минут, то вам классические СУБД не подходят. Нужны базы данных, большей частью объема, работающие в оперативной памяти - это Tarantool или Clickhouse.

Answer 2

[Александр Нестеров]

Читать файл построчно и заносить данные постепенно.

Comments

[Galaxy773]

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

[toxa82]

А у тебя выбора нет, многвенно ты их никак не внесешь а бд. Можешь читать построчно и вносить пачками по 100-500 строк, будет быстрее.

[Александр Нестеров]

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

[Алексей Горбунов]

toxa82, А еще и в несколько потоков.

[toxa82]

Ну это если несколько файлов и можно их разделить на потоки. Если оно одним файлом то врядли.

Answer 3

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

32 гигабайта это ни о чем.
Посмотрите мой проект fias основные фишки это пакетная вставка. Причём это именно вставка с довольно сложной логикой. Едем дальше, быстрый поиск тут важны правильные индексы и некоторая денормализация данных, тут уж думайте сами. И кстати у datasventistov есть инструменты именно для вашей задачи быстрые срезы по файлам когда датасет не помещается в память

Answer 4

[mayton2019]

Между ОЗУ и БД есть еще промежуточный вариант. Это различные key-value библиотеки для работы с хранением и поиском больших объемов данных. Из таковых я помню

• BerkeleyDb
  
• LevelDb https://github.com/google/leveldb/blob/main/doc/in...
  
• RocksDb
  

На самом деле их гораздо больше. Но автору и этих хватит. LevelDb создавался гуглом и под него есть разные API (C++, Java, C#). Почти все эти key-value библиотеки поддерживают 2 базовые структуры данных на диске (это HashTable, B+Tree).

Для твоей задачи прекрасно подходит дисковая хеш-таблица.

А если разумно партицировать твой объем - то можно и просто в CSV файлы разложить с гарантийным временем доступа.

Answer 5

[Dimonchik]

manticoresearch проще , быстрее, и нетребователен к ресурсам

туториалы посмотри, если SQL знаешь то достаточно