Большая статистика из таблиц. Как правильно считать данные в БД, как вы это делаете?

Question

[dimonchu]

Как правильно проектировать статистику чего-то?
Считать БД можно/нужно? Или лучше вся статистика должна быть уже обработана, и просто лежать в БД?
Имею ввиду всякие COUNT, AVG, SUM и так дальше, на стороне БД. Либо делать пред-обработку сразу по поступлению данных?
Адекватно ли будет это все считать силами самой БД в реальном времени, или это глупый подход?
Пускай мы должны работать с 3 таблицами(Joins + subquery), которые выводят результат в 100 строк, и в каждой строке по 10 колонок. Все 10 колонок это данные операторов агрегации.
Сами таблицы в себе вмещают до 100к строк данных каждая.

Comments

[Владимир Коротенко]

Ниже уже ответили. Проверьте на живых данных. Если не устраивает агрегируйте данные и заносите во временную таблицу.

Кроме этого в отчетных системах есть кэширование, например в SSRS можно выставить время генерации отчетов и условия отдачи готовых отчетов из кэша.

Answer 1

[ky0]

Всё зависит от конкретного случая, универсального ответа на ваш вопрос нет. Как человек, более близкий к админству, могу сказать, что на объёмах в сотни тысяч строк, то есть вполне помещающихся в оперативную память, вполне можно не заморачиваться преждевременной оптимизацией, главное, чтобы в таблицах были нужные индексы.

Comments

[dimonchu]

Ваш ответ самый адекватный и по теме, спасибо)

Answer 2

[xmoonlight]

Create Event
Или, периодически, через cron и микросервис: делаем независимые промежуточные расчёты - асинхронно, затем - итоговый из промежуточных.

Comments

[dimonchu]

Спасибо за идею) Но акцент вопроса был немного в другом :)

[xmoonlight]

dimonchu, про адекватный ответ - могу сказать, что до поры до времени.
Потом, придётся применять то, что я посоветовал: иначе - ничего не сможете сделать.

Answer 3

[Dimonchik]

Clickhouse

Comments

[dimonchu]

У вас на любой чих идёт смена технологий?

[Dimonchik]

какая смена? в clickhouse UPDATE / DEL отсутствует / кривой

примерно как Mysql / postgre для OLAP

[dimonchu]

dimonchik2013, кликхаус разве не отдельная СУБД? ;)

[Dimonchik]

dimonchu, вы предлагаете ее заюзать для CRUD операций ?

[dimonchu]

dimonchik2013, я б её вообще не использовал в моем случае) потому что для выборки статистики это через чур. То, что она работает при больших масивах данных, хорошо известно. Но следует ли использовать отдельную СУБД для решения локальной задачи? - нет, тем более, что для неё тоже нужны выделять ресурсы. Это не рационально.

Answer 4

[Developer]

Всё зависит от конкретной задачи.
Одни статистики считаются сразу, если они выполняются редко и/или быстро.
Если статистика тяжело считается, но её актуальность суточная, то выбирается время наименьшей активности юзеров. У нас это 4 часа утра в текущем регионе (+ в выходные ещё меньше). В это время запускается и считается тяжёлая статистика. Результаты отправляются в отдельную таблицу, откуда эти данные потом быстро забираются. Либо сразу подготавливается html-страница с отчётом.
Примерно то же самое, если актуальность в несколько часов или минут.

100к строк в таблице - это вообще ни о чём. Крохотулечная табличка. Тут всё зависит от самого запроса, как он написан.