Некая база сущностей, с порядка 15 text полями и 15-20 int полями.
Ожидаемый максимальный объем — порядка 30 млн строк.
Также к основной таблице идет десяток мелких таблиц связанных с ней м-м, т.е. таблицы связей с некоторыми справочниками, т.к. значения некоторых атрибутов сущности могут быть множественные и по ним может быть сделана выборка.
Нагрузка на вывод — не более 2-3 тыс. поисковых запросов в сутки.
Нагрузка на ввод — 100-200 записей в сутки и менее.
В кач-ве бд использую Mysql.
Основной вопрос — необходимо-ли при таком объеме использовать шардирование при следующей архитектуре:
— Поиск по текстовым полям и справочникам осуществляется сфинксом.
— Поиск по полям с числовыми значениями будет осуществляться с помощью индексных таблиц, в которых будет 2 intа
: id сущности и id значения словаря.
— Данные сущности, необходимые для формирования списков (основные поля типа названия, краткого описания и тд) кешируются в memcached для всех 30 млн, кеш обновляется в момент изменения сущности.
— Непосредственная выборка из основной таблицы будет осуществляться только по Primary ключу, который является уникальным числовым идентификатором типа int или bigint
Ну и вопросы.
1. Следует ли при таких нагрузках применять шардирование таблицы сущностей, или же 30 млн при указанных данных это не проблема?
2. Следует ли денормализовать таблицу сущностей на две — с интами и с текстовыми данными и не замарачиваться с лишними таблицами-индексами для поиска и искать прям по таблице с интами?
Привет
По описанию нагрузка небольшая. Так что вопрос такой «справляется ли система с нагрузкой»?
Если да, то трогать ее не надо. Рост данных незначительный.
Если нет, то надо искать решение. Возможно это будет шардинг, возможно что-то еще — добавить памяти, диск ssd и т.д.
Если планируется существенный рост нагрузки, то надо попробовать собрать еще такую машину и нагрузить ее. Выдержит планируемую нагрузку — ок.
