Агрегаты в БД — зачем, как, а стоит ли?

[devopg]

не нужно, когда есть кафка

[vmalyutin]

С трудом представляю себе руководителя, который анализирует данные ежесекундно. Скорее человек подождет, когда день закроется, встанет с утра, выпьет кофе, доедет до работы и уж тогда посмотрит на итоги дня. В общем, лаг часов 12. А стало быть заморачиваться с транзакционностью смысла нет (а делов с ней куча). Даже особого смысла в агрегатах нет. Потому что оперативный анализ не подразумевает больших объёмов.
Другое дело бизнес аналитик. К слову, у таких лаг еще больше, т.к. это анализ тенденций, а для него нужны большие и закрытые периоды. А еще им надо «крутить» данные, чего реляционная БД не умеет.
Конечно, не у всех есть бизнес аналитики, и некоторым надо, чтобы то решение, за которое они платят, выдавало им статистику, пусть и без особых вариантов слайсинга. Таким Excel подошел бы больше. Был бы набор данных. Кстати, Excel очень резко отличается от статичного набора отчетов в лучшую сторону.
Что же касается технологий. Я все-таки за ETL(или ELT). Почему? Row-by-row не применяют в аналитике. Там применяют специальные структуры данных оптимизированные для быстрого чтения больших объёмов.

[x_shader]

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

[igoresz]

'Стоит ли'?
СтОит конечно. Есть очень жесткие инструменты на эту тему: олапкубы, кликтех/поверби/табл, колоночные бд, кодеки в кликхаус…
Движение — жизнь, недвижение — голод.))