SELECT count()
FROM numbers_mt(10000000000)

┌─────count()─┐
│ 10000000000 │
└─────────────┘

1 rows in set. Elapsed: 0.232 sec. Processed 10.00 billion rows, 80.00 GB (43.09 billion rows/s., 344.72 GB/s.)

create table X( A Int8 ) Engine = MergeTree order by tuple();
insert into X select 1 from numbers_mt(10000000000)

select count() from X where A = 25;
0 rows in set. Elapsed: 0.326 sec. Processed 10.00 billion rows, 10.00 GB (30.70 billion rows/s., 30.70 GB/s.)

set max_threads=1
select count() from X where A = 25;
0 rows in set. Elapsed: 2.294 sec. Processed 10.00 billion rows, 10.00 GB (4.36 billion rows/s., 4.36 GB/s.)

Всем привет!
Есть таблица с динамикой и два запроса от фронта:
1) показать динамику + значение за 12 месяцев по месяцам [ currentMonth - 12, currentMonth - 1 ]
2) показать динамику + значение за прошлый месяц по дням

* значение = sum(prev.delta) + sum(current.delta)

Исходя из того что значение на конкретный день получается суммой всех прошлых + текущее использую runningAccumulate.

Исходной таблица MergeTree:

CREATE TABLE dynamic (
  `_id` String,
  `date` DateTime,
  `delta` UInt64
) ENGINE = MergeTree() 
PARTITION BY toYYYYMM(date)
ORDER BY
  (_id, date) SETTINGS index_granularity = 8192

На исходной таблице dynamic, если верить табиксу, получаются такие затраты:

0.01 sec.| 407,073 rows.| 14 MB

При том что размер самой таблицы 16793961 rows
И для конкретного _id +- 152 rows

Не смотря на то, что время выполнения огонь и 14мб не ощущаются на сервере с 252 рам, решил все же улучшить.

Для решения решил оставить dynamic как таблицу с исходными данными и аггрегировать их в таблице с движком SummingMergeTree.

CREATE TABLE test_dynamic_sum (
  `_id` String,
  `date` Date,
  `delta` Int64
) ENGINE = SummingMergeTree()
PARTITION BY toStartOfYear(date)
PRIMARY KEY _id
ORDER BY
  (_id, multiIf(date < toStartOfMonth(addMonths(today(), -12)), toStartOfYear(date),date < toStartOfMonth(addMonths(today(), -1)), toStartOfMonth(date), toDate(date)))
SETTINGS index_granularity = 128;

Залил в нее тестовых данных:
 - уникальных _id 1000000
 - на каждый день в промежутке [2018-01-01,2020-12-31] для каждого _id создал запись
Получилось общее количество записей: 1096000000
Каждый _id имеет: 1096 rows

Опять же, если верить табиксу, то затраты стали такими:

0.00 sec.| 1,537 rows.| 25 KB


Вопросы:

1) Как правильно расчитать index_granularity ?
 В test_dynamic_sum расчитывал его как сумма дней за два месяца (31+31) + немного с запасом
2) ORDER BY в test_dynamic_sum схлопывает данные так как я и хотел, но не #банет ли? 
Слишком уж идеальный результат получился

WITH
    toDate('2020-05-30') AS currentDate,
    toStartOfMonth(addMonths(currentDate, -1)) AS endOfYear,
    toStartOfMonth(addMonths(currentDate, -12)) AS startOfYear
SELECT
    _date AS date,
    value
FROM (
    SELECT
        date AS _date,
        runningAccumulate(sumState(delta)) AS value
    FROM (
        WITH
            toDate('2020-05-30') AS currentDate,
            toStartOfMonth(currentDate) AS currentMonth
        SELECT
            arrayJoin(arrayMap(x -> addMonths(currentMonth, -1 * x), range(12))) AS date,
            0 AS delta
        UNION ALL
        SELECT
            toStartOfMonth(date) AS date,
            delta
        FROM test_dynamic_sum final
        WHERE _id = '1045'
    )
    GROUP BY date
)
WHERE date >= startOfYear AND date <= endOfYear
ORDER BY date