impression_hourly_all (
hour DateTime,
app LowCardinality(String),
campaign LowCardinality(String),
city LowCardinality(String),
client LowCardinality(String),
connection_type LowCardinality(String),
country LowCardinality(String),
is_device UInt8,
isp LowCardinality(String),
os_name LowCardinality(String),
os_version LowCardinality(String),
publisher LowCardinality(String),
sub LowCardinality(String),
clicks UInt64,
impressions UInt64
)
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(hour)
ORDER BY (is_device, connection_type, client, publisher, campaign, country, os_name, os_version, city, hour, app, isp, sub)
1. Правильно ли я понимаю, порядок полей в ключе сортировки имеет значение (в том числе и поле hour)? И чтобы добиться масимальной эффективности при сжатии надо располагать поля в порядке увеличения их мощности (количества уникальных значений)?
2. При каких количествах уникальных значений (min/max) рекомендуется использовать LowCardinality? В некоторых источниках пишут, что < 10М - нормально. В других - разница на несколько порядков меньше.
1. да. НО!!!! обычно их располагают в таком порядке чтобы работал поиск по индексу для быстроты where ... 1a) можно не запихивать все поля в индекс, чтобы не делать его супершироким и не засирать ОЗУ PRIMARY KEY (is_device, connection_type, client, publisher) ORDER BY (is_device, connection_type, client, publisher, campaign, country, os_name, os_version, city, hour, app, isp, sub) 2. проверяете на своих данных, у всех разный размер парта. Это магическое значение больше про парт, а не про всю колонку. У каждого парта свой словарь. Может случится так что у вас партиционировано по тенанту и в колонке у разных тенантов разные набор значений, и т.д.
Обсуждают сегодня