Какую БД лучше всего использовать для хранения 100 млн записей и больше?

MainTable, примерно следующая структура:
-id
-category(~ 100 символов)
-title (~ 200 символов)
-key (на основе title, без пробелов, латиница+цифры+дефис+нижнее подчеркивание)
-content (основная часть записи, может быть большой 10-100 тыс символов)
-date

category+key- уникальное значение

MetaTable (для хранения доп информации):
-meta_id
-id
-meta_key
-meta_value

В MainTable рассчитывается хранить до 100млн, следовательно в MetaTable может быть больше.

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

Для каждого category будет примерно 50-300 тыс записей.

Какую БД лучше всего использовать для хранения большого количества данных в такой структуре?

И еще хочу поинтересоваться, стоит ли использовать составной ключ category+key, вместо ID. По идее это же должно потом помочь в партиципировании по столбцу category (и в MainTable, и в MetaTable)?

Хотел бы получить советов от тех, кто уже сталкивался с подобными задачами и ссылки на мануалы, которые могут помочь разобраться в хранении большого количества данных
  • Вопрос задан
  • 1085 просмотров
Пригласить эксперта
Ответы на вопрос 5
Stalker_RED
@Stalker_RED
Для каждого category будет примерно 50-300 тыс записей.
тогда логично вынести категорию в отдельную таблицу. Почитайте какой-нибудь учебник о проектировании БД и о нормальной форме, что-ли.

100 млн записей - это не много, и подойдет почти любая СУБД.
Ответ написан
Добрый день. СУБД под ваши нагрузки и правда можете выбирать любую. Лишь бы секционирование таблиц поддерживало. Postgres- очень хороший выбор. Есть нюанс Postgres, в некоторых случаях, может зависит от прямоты рук(т.е. как вы составите sql запрос). Как и у любой другой БД, есть свои особенности, с которыми вы можете встретиться, а можете не встретиться.
Ключ category+key вместо ID - не очень хорошая идея. Хотя бы поскольку только category имеет 100 символов, еще и key в придачу явно не пустой. Т.к. это первичный ключ по ним будет построен индекс. Ну и представьте, как будут выглядеть листовые блоки в индексах- при поиске в индексе нужного ключа придется по-битово сравнить 100 символов. Не критично, но идея не очень.
Если category повторяется- нормализуйте таблицу(Т.е. значения category вынесите в отдельную таблицу(сущность)) и в таблице MainTable храните внешний ключ(id ключа).
Смысла в поле key не вижу.
Ответ написан
Zoominger
@Zoominger
Сись админ
в хранении большого количества данных

Пффф, у вас детская база-то.
Ну ставьте MSSQL, делов-то.
Можно Postgre, тоже неплохо.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Вы поисковик делаете для себя?)
Тогда лучше использовать cassandra.apache.org
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
стоит ли использовать составной ключ category+key, вместо ID. По идее это же должно потом помочь в партиципировании по столбцу category (и в MainTable, и в MetaTable)?

нет. не поможет

-content (основная часть записи, может быть большой 10-100 тыс символов)

это сложите на диск, в базу ссылку. и любая база без проблем справится с индексом по 100М записям
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы