Добрый день, я тут спрашивала, как сделать, чтобы при группировке

по полю с высокой кардинальностью, эта группировка не тратила много оперативки.

Расход RAM у меня был >~10Гб. Собственно и заметила это, т.к. он не вписался в лимит. Расширила лимит, все выполнилась, но тут спросила, как уменьшить использование RAM.

Получила несколько ответов, почитала, все попробовала.

Что-то ничего не получилось :((

В <profiles> прописала

<optimize_aggregation_in_order>1</optimize_aggregation_in_order>.

Для сессии тоже явно указала настройку set optimize_aggregation_in_order=1. На всякий🙈

Старая таблица была создана с index_granularity ~300. Primary key был по полю с наибольшей кардинальностью, а в order by он, и ещё два поля с меньшей кардинальностью, в порядке возрастания кардинальности.

Новую таблицу создала с теми же данными, в order by и primary key указали одни и те же три поля в порядке возрастания кардинальности. index_granularity стандартная.

Выполнила запрос к новой таблице.
Группировку делала только по тем полям, которые указаны и в order by, и в primary key, одни и те же, в порядке возрастания кардинальности.

Ожидаемый результат было, что расход оперативки уменьшится. Реально, он стал 18Гб.

Выполняла из-под кликхаус клиента, чтоб посмотреть, как расходуется память.

Запустила аналогичный запрос к старой таблице. Опять 18Гб.

Сделала группировку только по полю с наибольшей кардинальностью, опять 18Гб.

Может, какие-то ещё настройки влияют?
Влияет ли кол-во строк в таблице?

Сколько весит у вас таблица ?

150 гб

Вы видимо не понимаете что optimize помогает только запросам у которых groupby примерно матчится с order by таблицы. Покажите запрос и ddl таблицы partition by orderby

первая 3Гб, вторая 5,8Гб. Кол-во строк: 115132713

Добрый день, это создание таблиц, первоначально и для использования optimize_aggregation_in_order: CREATE TABLE DWH.kv ( region String, b String, account_id String, dt DateTime, f String, g String, h String, i String, j String, k Nullable(Int16), l Nullable(Float32), m Nullable(Float32), n Nullable(Float32), o Nullable(Float32), p Nullable(Float32), q Nullable(Float32), r Nullable(Float32), t Nullable(DateTime), v Nullable(DateTime), u Nullable(Float32), x Nullable(Float32), y String ) ENGINE = MergeTree ORDER BY account_id SETTINGS index_granularity = 370; CREATE TABLE DWH.kv2 ( region String, b String, account_id String, dt DateTime, f String, g String, h String, i String, j String, k Nullable(Int16), l Nullable(Float32), m Nullable(Float32), n Nullable(Float32), o Nullable(Float32), p Nullable(Float32), q Nullable(Float32), r Nullable(Float32), t Nullable(DateTime), v Nullable(DateTime), u Nullable(Float32), x Nullable(Float32), y String ) ENGINE = MergeTree PRIMARY KEY (region, dt, account_id) ORDER BY (region, dt, account_id) SETTINGS index_granularity = 8192; Кол-во строк: 115132713 Кол-во account_id: 6144260 И запросы: select t.region, t.dt, t.account_id "Идентификатор" , max(t.h) "Тип" , sum(t.m) "Начальное сальдо Дебет" , sum(t.n) "Сумма оплачено ИТОГО, руб." , sum(t.o) "Начальное сальдо Кредит" , sum(t.p) "Конечное сальдо Дебет" , sum(t.q) "Конечное сальдо Кредит" , min(t.v) "Дата оплаты по сальдо" from DWH.kv(2) t group by t.region, t.dt, t.account_id ; select t.account_id "Идентификатор" , max(t.h) "Тип" , sum(t.m) "Начальное сальдо Дебет" , sum(t.n) "Сумма оплачено ИТОГО, руб." , sum(t.o) "Начальное сальдо Кредит" , sum(t.p) "Конечное сальдо Дебет" , sum(t.q) "Конечное сальдо Кредит" , min(t.v) "Дата оплаты по сальдо" from DWH.kv(2) t group by t.account_id ; В обоих запросах, не зависимо от полей группировки: system.query_log: Settings: {load_balancing=random, max_memory_usage=107374182400, optimize_aggregation_in_order=1}