Int64)
и Order by по 13 полям.
Есть MV для этой таблицы.
Все как рекомендуется.
И тут есть 2 вопроса/непонятки:
1. В таблице всего 16 млн строк, при этом она занимает 20 гигов. сжатия почти нет. Причем в таблице нет каких-то больших текстов, 10 полей вообще числа до 10.
2. При выборке из таблицы размером в 20 гигов, падает в MEMORY_LIMIT 56 ГБ..
Делается агрегация по полям и uniqMerge()
Вся эта конструкция как раз и задумывалась чтобы избежать падения запроса по памяти, т.к. таблица источник более 10 млрд строк и 700 Гб...
Куда копать?
ну во первых смотрите размер по колонкам, чтобы понимать что конкретно занимает место, пример запроса https://pastila.nl/?0317470c/852ea9995e9355d0fe24ce1bde7090fd#yLJ4Wzvfyjdfnn6lclL+Fg== во вторых как хранить state от uniq? это просто какие хешированные значения от исходных, чтобы потом можно былол смержить состояния, поэтому сжатия там не ожидайте Пробуйте менее точные функции, например uniqHLL, он должен места меньше занимать
Собственно, вот и то самое поле
Тогда очень сомнительная вообще выгода от использования такого подхода AggregatingMergeTree -State -Merge Уменьшило ли количетсво строчек? - да, а толку... запрос все равно не выполняется )))
ну, я бы не называл AggregatingMergeTree сомнительным "вообще" только из-за того, что вы туда положили non-additive метрику, как uniq, и движку приходится все уникальные значения хранить )
ну магии не существует) или терять в точности или больше памяти) в других базах в основном используется HLL, попробуйте его
а можете полностью показать как создана вьюха?
create materialized view table_mv to table_agg as select . . . . . . uniqState(cm.client_mapping_key) as cnt_client_mapping_key FROM source_table cm group by . . . . . . ;
Обсуждают сегодня