Привет, ребят, подскажите как делать, хотя вопрос и арихитектурный, но

проект на ларавел.

Итак, у меня есть 3 таблички, в них данные пишут джобы, данных много: сотни тысяч, будут десятки миллионов строк,
в табличках хранится статистика, например какой товар, когда заказали, когда за него перевели деньги и кто, на каких складах он сейчас есть (движения по складу) из этой статистики можно считать процент выкупов (отношение всех заказов к выдачам товаров) и прочее прочее.
те хранятся "сырые данные" из которых нужные бизнесу графики собираются..


так вот встала задача сделать большую отчетную таблицу, пока конечно не большую, но все же, мне нужно вывести процент успешных продаж (отношение заказов к выдачам) все эти данные есть в этих 3ех табличках.
Я набросал метод который получает данные, на пыхе считает, выводит, метод большой и запросы даже на тестовых данных тяжелые (индексы есть) что же будет когда будет выборка из 10 млн... думаю упрусь в memeory_limit..

Вообще мне нужен текущий процент и за последние 3месяца (за каждый из 3ех месяцев), щас я просто их считаю на пыхе (могу на sql перебросить) но для этго мне нужно получить ну прям очень много строк и сделать эту математику (100% переброшу на sql с агрегатными функциями сегодня), но даже на sql... зайдет 10 клиентов одновременно у каждого по 2млн строк, нормально ли шерстить это все "на живую", в голове крутится идея какого-то кеша, те считать эту таблицу где-то в фоне и из кеша уже показывать людям.

Вопрос, какие инструменты и подходы для этого есть? (редис не подойдет, он больше для горячих данных.., тут же в mysqlскладывать, кажется старнным, я конеччно не DB-ninga, но слышал про какие-то хранимые процедуры, но особо не понял зачем, про view table (хотя не уверен о их наличии в mysql)...
Вобщем путей решния вроде как несколько, но не могу выбрать верный, подскажите пожалуйста. (как бы делали вы)

Может стоит такую обработку переложить на mysql сервер? Процедуры, функции..

поднимите рядом инстанс в копией БД и делайте отчеты на не. Отчеты обычно не нужны в реалтайме

Нифигасебе, спасибо, а это решение хорошее, оно как сферический конь или реально где-то используется? Но опять же… придет 100 клиентов и тот инстанс бд так же будет ворочать милиионами строк, это норм.. отвалится он тогда, вот и все, разве нет?

надо ли вам сырые данные в mysql сразу писать ? при innoDB - оно 4 раза диск будет дергать, только чтобы сделать insert . Есть Кликхаус для всякого шлака начального

Хороший вопрос, а почему 4 раза на инскрт, расскажите пожалуйста?

посмотри кликхаус под такую задачу

Я смотрел, дело в том что данные не просто мне летят и я сохраняю, там есть логика обновления, а на сколько погуглил и кликхауса с обновлением строк беда

да

было на какой то конференции. Запись в лог, в кэш, мб неявная транзации , запись в БД ... тут помню что 4 раза, там не помню

Может какие-то триггеры в бд можно использовать, вот гуглю но пока не понимаю как их прикрутить, или это вообще я не туда ушел?

пока ничего не скажу, абстрактный вопрос. на самом деле да, можно считать данные отдельно, на отдельном серваке, на реплике, частичной или полной. Но, это надо исходить из проблемы. Оценивать характер нагрузки и сами данные. Бывает такое, что сначала кажется, что все данные нужды сразу, а в процессе оптимизации можно найти другие подходы к выборкам, может оказаться что не всё надо. Т.е. какого-то универсального решения нет. Можно попробовать хранить какие-то агрегированные данные отдельно.

Вот да, а где их хранят обычно? Тут же в базе?

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