Сразу рекомендую посмотреть на синтаксис create MV to target select ... from source + 2 таблицы: исходная и целевая

Читайте ограничения POPULATE в доке внимательно, можно пропустить часть данных, если идёт постоянная вставка в исходную таблицу. Ещё можно просто insert select вставить старые данные в MV(или таблицу под ней) руками

А если сравнить два решения: создать materializedview на summingmergetree и просто отдельную таблицу на summingmergetree и туда скриптами заливать новые данные. Есть ли предположение какой вариант будет более производительный?

Я не сказал что у решения нет ограничений.

Смотря как работают ваши скрипты.  У вас либо вставка в исходную таблицу сразу наполняет  МВ, либо ваши скрипты должны делать две вставки (в таблицу с сырыми данные и с summingMT).  Всё зависит от ваших кейсов.

Сорри, я имел ввиду что нужно доку будет прочитать человеку, а не вслепую добавить ключевое слово.

Я предлагал нечто такое

CREATE DATABASE IF NOT EXISTS test;
CREATE TABLE test.source(dt Date, key UInt8, cnt UInt64) ENGINE MergeTree PARTITION BY dt ORDER BY key;
CREATE TABLE test.target(dt Date, total_cnt UInt64) ENGINE SummingMergeTree(total_cnt) PARTITION BY dt ORDER BY dt;
CREATE MATERIALIZED VIEW test.mv TO test.target AS SELECT dt, sum(cnt) total_cnt FROM test.source GROUP BY dt;
INSERT INTO test.source VALUES (today(), 1, 10), (today(), 2, 10), (today() - 1, 1, 10);

CREATE DATABASE IF NOT EXISTS test;
CREATE TABLE test.source(dt Date, key UInt8, cnt UInt64) ENGINE MergeTree PARTITION BY dt ORDER BY key;
CREATE TABLE test.target(dt Date, total_cnt UInt64) ENGINE SummingMergeTree(total_cnt) PARTITION BY dt ORDER BY dt;
CREATE MATERIALIZED VIEW test.mv TO test.target AS SELECT dt, sum(cnt) total_cnt FROM test.source GROUP BY dt;
INSERT INTO test.source VALUES (today(), 1, 10), (today(), 2, 10), (today() - 1, 1, 10);

То есть мы будем хранить реальные данные в test.target получается. А чем это лучше чем просто materializedview?

Можно изменять мат вью без дропа таблицы

Ну и мат вью в любом случае таблицу создаёт, если не указать уже созданную

MV по сути тоже самое делает просто скрывает от ваших глаз таблицу target и люди начинаеют думать о ней иначе, а так очевидно что где и когда хранится

Ну в целом попробовать поднять производительность за счет materializedview, который хранит агрегированные данные - это норм решение я так понял, верно?

Да, собственно для этого оно и есть

Норм. Но может у вас есть ещё варианты без этого ? Не окажется ли так ,что вот вам нужно подтюнить запросы . Или индексы вторичные создать

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

Идея в том, что забирать данные из исходной таблицы и округлять timestamp у данных до часа и тем самым хранить посчитанные данные по часам и быстро их отдавать

Всем спасибо за ответы🙏, внесли очень много ясности :)

Подскажите по памяти кликхауса, есть следующая проблема:

Свободной памяти почти всегда очень мало, менее гб, большую часть занимает cached, можно ли как-то ограничинить настройками память так, чтобы для free memory оставалось больше места? Из-за этого судя по всему часто есть ошибки Memory limit (total)

cached не мешает выполнению запросов