Всем привет! Создал таблицу с агрегациями по идентификатору девайса, дням

ивента и геохашами. Таблица партиционирована по дате ивента. Тесты показывают, что запросы к ней работаю медленнее, чем к основной таблице. В чем может быть причина? create table db_name.agg_table_name_local on cluster '{cluster}'
(
event_date date,
device_id String,
geo_hash_5 String,
geo_hash_6 String,
geo_hash_7 String,
geo_hash_8 String,
cnt AggregateFunction(sum, UInt32)
)
engine = ReplicatedAggregatingMergeTree()
PARTITION BY toYYYYMMDD(event_date)
order by (device_id, geo_hash_8, geo_hash_7, geo_hash_6, geo_hash_5, event_date)

CREATE TABLE db_name.agg_table_name on cluster '{cluster}' AS db_name.agg_table_name_local
ENGINE = Distributed('{cluster}', db_name, agg_table_name_local, sipHash64(device_id));


select
geo_hash_8,
sumMerge(cnt)
from db_name.agg_table_name
WHERE device_id GLOBAL IN (select device_if from tmp_merged_device_list)
AND geo_hash_8 IN (...)
AND geo_hash_7 IN (...)
AND geo_hash_6 IN (...)
AND geo_hash_5 IN (...)
AND event_date BETWEEN '2023-02-01' AND '2023-06-30'
GROUP BY 1;

- сколько записей в день в основной и Agg таблице? - зачем GLOBAL IN используете если шардируете по девайсам, это самая медленная часть

1. В основной таблице 17.5B записей, в AGG 1.4B 2. Перед финальной выборкой идет сбор списка устройств из DISTRIBUTED таблицы, без GLOBAL запрос не отрабатывает

- имхо, из опыта, нет смысла в таких AGG таблицах, которые только х10 меньше сырой. я обычно стараюсь на 2-3 порядка хотя бы уменьшать - а как шардирована эта distributed таблица? шардируйте по sipHash64(device_id) это должно решить ваши вопросы

А в чем идея хранить все разрешения хешей? Почему нельзя просто самый мелкий?

Хороший вопрос... но с бэкенда могут приходить разные запросы, от очень большого количества geo_hash_9 (тогда проще заменить одним geo_hash_2). Тогда размер query будет несколько тысяч строк кода. Какие можете посоветовать лучшие практики на этот счет?

Кмк в кх есть функции которые могут сделать из одного геохеша другой

Можете пример привести?

https://clickhouse.com/docs/en/sql-reference/functions/geo/geohash Но именно такой нету. Но у геохеша надо просто отрезать конец, т.е. функция substr

Если данные в таблице отсортированы по geo_hash_9, то фильтрация по части подстроки не приведет к полному сканированию и будет работать так же эффективно? Например: WHERE left(geo_hash_9, 2) = ‘th’

Как я помню

https://pastila.nl/?1163089b/d2fa81b322e4cc77217d1b6e49d10108