Какую БД лучше всего использовать для хранения 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)?
Хотел бы получить советов от тех, кто уже сталкивался с подобными задачами и ссылки на мануалы, которые могут помочь разобраться в хранении большого количества данных
Добрый день. СУБД под ваши нагрузки и правда можете выбирать любую. Лишь бы секционирование таблиц поддерживало. Postgres- очень хороший выбор. Есть нюанс Postgres, в некоторых случаях, может зависит от прямоты рук(т.е. как вы составите sql запрос). Как и у любой другой БД, есть свои особенности, с которыми вы можете встретиться, а можете не встретиться.
Ключ category+key вместо ID - не очень хорошая идея. Хотя бы поскольку только category имеет 100 символов, еще и key в придачу явно не пустой. Т.к. это первичный ключ по ним будет построен индекс. Ну и представьте, как будут выглядеть листовые блоки в индексах- при поиске в индексе нужного ключа придется по-битово сравнить 100 символов. Не критично, но идея не очень.
Если category повторяется- нормализуйте таблицу(Т.е. значения category вынесите в отдельную таблицу(сущность)) и в таблице MainTable храните внешний ключ(id ключа).
Смысла в поле key не вижу.
Я бы добавил, что в случае с PostgreSQL'ом - в 99% случаев, всё будет зависеть от "прямоты рук", остальное можно списать на статистическую погрешность :)))