📊 SummingMergeTree vs AggregatingMergeTree — в чём реальная разница

🔥 Главная мысль

На первый взгляд кажется, что оба движка нужны для агрегации.

Но между ними есть важная разница:

• SummingMergeTree суммирует числовые поля • AggregatingMergeTree хранит агрегатные состояния и умеет больше, чем просто сумму

То есть:

если тебе нужна простая сумма — это одна история.

Если тебе нужны uniq, avg, maxIf и другие агрегаты — это уже другая история.

🟢 Плюсы:

SummingMergeTree: • проще понять • удобен для простых числовых сумм • работает как бы “автосуммой” при merge

AggregatingMergeTree: • намного гибче • умеет хранить состояния агрегатных функций • подходит для сложных предагрегаций

Пример плюса: если тебе нужно просто суммировать продажи по id, SummingMergeTree может быть удобным решением.

Если нужно хранить uniqState, avgState, maxIfState, то уже нужен AggregatingMergeTree.

🔴 Минусы:

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

AggregatingMergeTree: • сложнее в понимании • требует работать с -State и -Merge функциями • без понимания финализации агрегатов легко запутаться

Пример минуса: новичок создаёт AggregatingMergeTree, а потом удивляется, почему в таблице лежит “не итоговое число”, а состояние агрегата.

🧪 Живые примеры

Когда брать SummingMergeTree:

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

Когда брать AggregatingMergeTree:

• сложные витрины • uniqState / avgState / maxIfState • материализованные представления с агрегатными состояниями • сценарии, где нужно доагрегировать данные позже

Простой ориентир:

если тебе нужна “просто сумма” — сначала смотри в сторону SummingMergeTree.

Если тебе нужна более сложная аналитическая логика — скорее всего понадобится AggregatingMergeTree.

🏗 Архитектурная мысль

В больших компаниях AggregatingMergeTree часто используют там, где витрина строится в несколько шагов:

• сначала считаются состояния • потом они доклеиваются • потом дочитываются в финальный результат

Это даёт большую гибкость, но требует дисциплины и понимания.

Что это даёт:

• меньше пересчётов • удобнее строить тяжёлые витрины • можно переносить часть нагрузки ближе к данным

⚠️ Риски:

• брать AggregatingMergeTree там, где хватит SummingMergeTree • не понимать разницу между состоянием и финальным значением • усложнять витрину без необходимости

Самая частая ошибка — сделать сложную схему агрегации там, где бизнесу нужна была обычная сумма по метрике.

✅ Вывод

SummingMergeTree — про простое суммирование 📉

AggregatingMergeTree — про сложную предагрегацию и состояния агрегатов 📈

Если задача простая — не усложняй. Если нужна гибкость — тогда уже смотри в сторону AggregatingMergeTree 🎯