Как правильно разгрузить таблицу статистики для такого проекта?

Question

[Solvik74]

Всем привет!

Сейчас занимаюсь разработкой большого проекта, в котором ведётся учёт уникальных посетителей, добавление товаров от пользователей системы, оформление заказов, приём оплаты , построение отчётов и подробной статистики по всем данным.

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

Необходимо давать пользователям детальную статистику по посещениям и оформленным заказам с минимальной задержкой.

Для статистики существует отдельная таблица, в которой суммируются все необходимые показатели из других таблиц (по триггерам вставки) с точностью до дня. Но и эта таблица через год будет минимум на 350 миллионов строк.

В статистике пользователи могут составлять отчеты, как суммарно, так и по дням/неделям/месяцам.

Сейчас в качестве БД используется MySQL 5.6 с InnoDB. Таблицы проиндексированы.
Движок написан на Laravel.

Подскажите, стоит ли разбивать таблицу статистики партиционированием, например по месяцам, или лучше заводить отдельные таблицы?

P.S.: в архитектуре БД я не силён, так что с удовольствием выслушаю любые ваши предложения! Всем спасибо!)

Answer 1

[terrier]

Да, партиционирование по времени здесь вполне подходит. Разницы между партиционированием и отдельными таблицами в вашем случае особо нет, но с партиционированием, скорее всего окажется меньше мороки.
Статистику и аналитику лучше читать с отдельной реплики, не с той, на которую идет активная запись.
В 5.7 есть релевантные для вас улучшения, но на самом деле после минимальной настройки все вполне себе взлетит.
P.S.

не менее 150 тысяч записей в сутки.

Почти 2 записи в секунду. Можно хоть на айфоне базу гонять :)

Comments

[Solvik74]

Спасибо за ответ!)
А вот тот момент, что таблица статистики собирается по триггерам это же норм?) ничего страшного же не будет даже при 1000 записей в секунду?

[terrier]

ничего страшного же не будет даже при 1000 записей в секунду?

Это, конечно же, зависит от железа. Ну, сейчас, пока не запустили проект самое время провести нагрузочное тестирование и узнать точно. ( И потом нагрузочное тестирование периодически проводить. И в мониторинг смотреть, чтобы быть готовым к повышению нагрузки. )

Answer 2

[Dimonchik]

берешь что-нибудь такое, заполняешь, строишь бизнес-логику, осознаешь

например, для отчетов (но не для хранения основных данных) подойдет и Clickhouse, а в качестве основной - PostgreSQL

а так проблем где хранить и быстро доставать нету, та же Монга по-быстрому сойдет, или Эластик

Comments

[Solvik74]

Спасибо за ответ!)
Я скорее всего неправильно указал вопрос, сейчас изменил. В целом архитектура уже построена. Тут больше проблема в последующей разгрузке.

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

Может быть стоить сделать репликацию БД, партиционирование таблицы статистики?