Какая самая оптимальная БД для хранения больших объемов информации?

Question

[skylabs]

Нужно хранить несколько десятков (а то и сотен) миллионов записей в таблице базе данных, штук 5-8 полей, типы например такие - bigint, string, bool, integer, float. Для быстрого поиска нужна индексация по полям id, и title. При этом требуется, чтобы база данных на диске занимала как можно меньше места. Возможно есть какие-нибудь бенчмарки СУБД, в которых тестируется размер базы данных при одинаковом содержимом?

Answer 1

[bnytiki]

1. Миллионы записей это вовсе НЕ большая БД. Для современной СУБД - это ерунда. Нынче и миллиарды записей не большая проблема, а вы о миллионах каких-то.

2. В БД очень много места занимают индексы. Если вы не будете их делать (и не будете использовать СУБД, которая сама создает индексы) - можете сэкономить и в 2 раза. Как вариант - индексировать каждый раз при запуске приложения.

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

4. Есть append only СУБД. Там нет фрагментации. Там нет журнала транзакций (или он сильно упрощен).

5. У вас не такие уж и большие объемы. Допустим даже у вас будет 8 строковых полей по 120 символов в каждом. Это около килобайта без индексов. Допустим их будет 1 миллион. Это около 1 гигабайта без индексов.

6. Можно прекрасно разместить в оперативной памяти.
Если нужно прям-таки жестко сэкономить на дисковом пространстве, например, я бы взял СУБД in-memory (1 гигабайт данных + индексы на полгигабайта даже если - это не много для современного компьютера). А данные бы сжимал.

Comments

[skylabs]

извините, немного ошибся в описании, я имел в виду десятки и сотни миллионов записей. Я в курсе что теоретически это не много, но когда размер таблицы mysql становится 20-30 Гб, то хотелось бы найти что-то поэкономнее именно с точки зрения хранения данных на диске :)

[bnytiki]

skylabs: существует 3 основных вещи, которые увеличивают размер на диске:

1. Индексы
2. Журнал транзакций
3. Фрагментация из-за изменений/удалений.

Если что-то в вашей задаче позволяет минимизировать пункты 1, 2 или 3 - можно здорово (может и в полтора раза запросто, а то и больше) сэкономить.

А еще можно попробовать разные виды движков.

Умозрительно MyISAM экономичнее, чем InnoDB.

[bnytiki]

Так как в MyISAM отсутствует дополнительная фрагментация в межтабличных пространствах.

[bnytiki]

skylabs: Также было бы неплохо присмотреться на то - а какие данные не изменяются вовсе. Или изменяются крайне редко. В этом есть задел для оптимизации.

[bnytiki]

bnytiki: А еще можно просто воспользоваться средствами сжатия файловой системы.
Файлы для хранения автоматически сжимаются.

[bnytiki]

bnytiki: Минимизировать ID - это сэкономит индекс на ID.
Возможно, достаточно по частичному Name искать, а не по полному (например, по первым 10 символам) - тогда и для индексации использовать только начало Name.
Есть еще индексы разного типа, тут тоже можно повыбирать. Пусть они будут работать чуть медленнее, но будут занимать значительно меньше времени.

[bnytiki]

skylabs: Насколько я понял из описания - у вас почти что Key-Value хранилище.
Имхо, реляционная СУБД будет избыточна.
Что-то ближе к key-value без SQL-фич, умозрительно-предположительно, было бы эффективнее по расходу дискового пространства.

[skylabs]

ок, спасибо, вот это как раз и интересует, может уже есть результаты проведенных тестов на одном и том же наборе данных, по которым было бы видно размер "накладных расходов" формата хранение данных в разных СУБД и движках.

[bnytiki]

skylabs:
Если у вас однопользовательская среда, то имеет смысл глянуть на файловые вещи. Вплоть до Berkley DB и т.п. А также на встраиваемые. Типа BoltDB и т.п.

[bnytiki]

А еще

MySQL в InnoDB поддерживает сжатие

Позволяет и в 2 раза сэкономить.
Проведите эксперимент - включите это сжатие, может вас и устроит.

[bnytiki]

skylabs:
Чужие тесты для вас бесполезны.
Разные данные по разному совершенно сжимаются и индексируются.

[bnytiki]

skylabs:
Только собственные тесты и дадут ответ.
Попробуйте самое простое - просто включить сжатие в InnoDB

Answer 2

[xmoonlight]

Для малого объёма - только работа с узлами "дерева" Вас спасёт (и создание начального дерева).
А по остальным критериям - можно брать любую.

Answer 3

[al_gon]

Что есть для вас быстый поиск?
Нужен по title полноценный полнотекстовый поиск?
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D...

Если да, то без поискового движка никуда.

Если у вас поиск по катологу, то варинты типа

SELECT * FROM documents WHERE MATCH (title) AGAINST ('поиск');

не подходят.