dmitriyecho
@dmitriyecho

Правильность применяемого решения?

Всем привет.

Итак, дано:

Некая база сущностей, с порядка 15 text полями и 15-20 int полями.

Ожидаемый максимальный объем — порядка 30 млн строк.

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

Нагрузка на вывод — не более 2-3 тыс. поисковых запросов в сутки.

Нагрузка на ввод — 100-200 записей в сутки и менее.


В кач-ве бд использую Mysql.


Основной вопрос — необходимо-ли при таком объеме использовать шардирование при следующей архитектуре:

— Поиск по текстовым полям и справочникам осуществляется сфинксом.

— Поиск по полям с числовыми значениями будет осуществляться с помощью индексных таблиц, в которых будет 2 intа

: id сущности и id значения словаря.

— Данные сущности, необходимые для формирования списков (основные поля типа названия, краткого описания и тд) кешируются в memcached для всех 30 млн, кеш обновляется в момент изменения сущности.

— Непосредственная выборка из основной таблицы будет осуществляться только по Primary ключу, который является уникальным числовым идентификатором типа int или bigint


Ну и вопросы.

1. Следует ли при таких нагрузках применять шардирование таблицы сущностей, или же 30 млн при указанных данных это не проблема?

2. Следует ли денормализовать таблицу сущностей на две — с интами и с текстовыми данными и не замарачиваться с лишними таблицами-индексами для поиска и искать прям по таблице с интами?
  • Вопрос задан
  • 3018 просмотров
Пригласить эксперта
Ответы на вопрос 2
@Renius
дурак восторженный
1. 30 млн строк и 200 записей в сутки
150000 суток — 410 лет
С учетом «десятка мелких таблиц связанных» 41 год, даже в этом случае записи устареют
2. Вменяемая структура, с грамотными индексами даст вам производительность сопоставимую с 1к записей и 10м.
3. Денормализация таблицы может быть полезна для организации эффективной системы индексов.
4. 86400 секунд в сутках, 8640 запросов в сутки может обработать ваша система, даже если длительность запроса будет доходить до 10 секунд.
5. Обратите внимание на то, каков будет результат выборки, может ли результат каждой выборки содержать 1м записей? Ограничивайте результаты.
6. Шардинги необходимы на больших нагрузках, в случае тысяч записей в сутки, шардинг, как мне кажется не нужен.
7. При таком объеме, база будет занимать 15-150Гб ориентировочно, опять же, как мне кажется шардинг снова не нужен.
Ответ написан
Комментировать
bolnikh
@bolnikh
Привет
По описанию нагрузка небольшая. Так что вопрос такой «справляется ли система с нагрузкой»?
Если да, то трогать ее не надо. Рост данных незначительный.
Если нет, то надо искать решение. Возможно это будет шардинг, возможно что-то еще — добавить памяти, диск ssd и т.д.

Если планируется существенный рост нагрузки, то надо попробовать собрать еще такую машину и нагрузить ее. Выдержит планируемую нагрузку — ок.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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