и да вы угадали в файлах используются страны, примерный формат файлов такой

2019-12-03      1575390441              adport    USA             129969  204     noWinner        0                                       0       new-chart-5594c6898b-8dnk4
2019-12-03      1575390441              epom      BGR             3413397 204     noWinner        0                                       0       new-chart-5594c6898b-8dnk4
2019-12-03      1575390441              porate    LBN             13598922        204     noWinner        0                               0       dnew-chart-5594c6898b-8dnk4

Привет! Во-первых, спасибо разработчикам ClickHouse, действительно клевая база данных. Есть несколько вопросов.

Дано:

* Одна нода - сервер на DO 16 CPU, 32 GB RAM, attached volume на 3 ТБ
* Таблица 5 млрд записей

CREATE TABLE impression.impression (
`date` Date, 
`timestamp` DateTime, 
`unique_id` UUID,
`client` String, 
`campaign` String, 
`publisher` String, 
`application` String,
`click_id` String, 
`os_name` String, 
`os_version` String, 
`pclick` String, 
`idfa` String, 
`gaid` String, 
`ip_address` String, 
`country_code` FixedString(2), 
`city` String, 
`isp` String, 
`latitude` Float64, 
`longitude` Float64, 
`referrer` String, 
`user_agent` String
) ENGINE = MergeTree(date, unique_id, 8192)

* Запись в таблицу производится с нескольких серверов батчами по 10к записей


1. Первоначально требовалось быстро искать по полю unique_id. Поэтому именно это поле я и выбрал как первичный ключ. Позже появилось требование искать еще по полю click_id. Пытался разметить таблицу следующим образом: ENGINE MergeTree() PARTITION BY date ORDER BY (date, unique_id, click_id) SETTINGS index_granularity=8192. Но это не помогло. Подскажите, какой первичный ключ (ключ сортировки) надо было выбрать? Или CH для этого класса задач не подходит? Вообще стоило ли добавлять date в начало ключа сортировки?

2. Второй класс задач - группировки (GROUP BY) по различным полям (дата, client, campaign, publisher, ...) с фильтрацией (WHERE по выбранным client, campaign, publisher) за определенный период времени. Что наилучшим образом повлияет на ускорение запросов? MatView, репликация, шардирование, иной Primary Key?

3. Планирую переход с одной ноды на кластер. Сейчас в таблицу записывается 200 млн/сутки, в перспективе будет 1 млрд/сутки. Порекомендуйте, пожалуйста, конфигурацию кластера и характеристики серверов.

CREATE TABLE impression.impression (
`date` Date, 
`timestamp` DateTime, 
`unique_id` UUID,
`client` String, 
`campaign` String, 
`publisher` String, 
`application` String,
`click_id` String, 
`os_name` String, 
`os_version` String, 
`pclick` String, 
`idfa` String, 
`gaid` String, 
`ip_address` String, 
`country_code` FixedString(2), 
`city` String, 
`isp` String, 
`latitude` Float64, 
`longitude` Float64, 
`referrer` String, 
`user_agent` String
) ENGINE = MergeTree(date, unique_id, 8192)

PARTITION BY date ORDER BY (date,

date в ORDER BY смысла не имеет, там всегда одно значение, из-за PARTITION BY date

1. Если действительно хочется быстро искать (это вообще неправильный вопрос для OLAP), делайте две таблицы одна ORDER BY unique_id вторая ORDER BY click_id и все храните два раза. Но проблема в вашем неправильном желании. Скоро появится zorder индекс который несколько облегчит.


2. фильтровать через таблицу отсортированную по creative_id, который вычисляется из client, campaign, publisher

3. 700 серверов, в каждом по 600ГБ озу

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

Привет всем, если необходимо чтобы КХ повторно "потрогал" парты, для применения изменений к старым данным, это же вроде можно имитировать через мутацию?

речь про запись добавленных алтером column default на диск?

скорее skip index хочу накатить

ALTER TABLE [db.]table MATERIALIZE INDEX name IN PARTITION partition_name

похоже где-то в доке рядом с этим, читаю )

а сразу нельзя было это сказать? дедушка партизан?

сорян )

Спасибо за ответы! Вы могли бы детальнее раскрыть пункт 2?

client, campaign, publisher это ведь атрибуты баннера не правда ли?

Да

ну вот показали баннер желтые труселя, даже если он персонализирован, и там написано special for you Denny, все равно у этого баннера есть id, где он у вас в таблице?

не конкретный баннер, а сам криэтив

В таблице логгируются не показы баннеров, а клики по ним. ID клика - поле click_id. creative тоже есть, но колонка разряженная. Пример

click-house 🙂 select unique_id, creative from impression where date = today() limit 10

SELECT
    unique_id,
    creative
FROM impression
WHERE date = today()
LIMIT 10

┌────────────────────────────unique_id─┬─creative─────┐
│ 81f2e18c-2a9e-400a-8000-0081eea700b8 │              │
│ 8a517785-ce97-44a7-8000-00b993a65257 │              │
│ 31cf4466-0d5e-43dc-8000-00f6e8cc7371 │              │
│ fbc5ac3a-1416-42c9-8000-0127fd6b4dff │              │
│ 8a73b52d-542d-4462-8000-0235cd57a4ff │              │
│ bc890a0a-5714-4a26-8000-028069868516 │              │
│ a4a118e3-aec7-4ad8-8000-02b55370430d │              │
│ 9c3b902a-5c60-4889-8000-035738884b05 │              │
│ a25d62d3-c40c-4044-8000-03bd12a6862f │              │
│ aac63a8c-21b2-4b4b-8000-03be453a9538 │ listen - ios │
└──────────────────────────────────────┴──────────────┘

10 rows in set. Elapsed: 0.166 sec. Processed 90.11 thousand rows, 1.54 MB (543.72 thousand rows/s., 9.29 MB/s.)

click-house 🙂 select unique_id, creative from impression where date = today() limit 10

SELECT
    unique_id,
    creative
FROM impression
WHERE date = today()
LIMIT 10

┌────────────────────────────unique_id─┬─creative─────┐
│ 81f2e18c-2a9e-400a-8000-0081eea700b8 │              │
│ 8a517785-ce97-44a7-8000-00b993a65257 │              │
│ 31cf4466-0d5e-43dc-8000-00f6e8cc7371 │              │
│ fbc5ac3a-1416-42c9-8000-0127fd6b4dff │              │
│ 8a73b52d-542d-4462-8000-0235cd57a4ff │              │
│ bc890a0a-5714-4a26-8000-028069868516 │              │
│ a4a118e3-aec7-4ad8-8000-02b55370430d │              │
│ 9c3b902a-5c60-4889-8000-035738884b05 │              │
│ a25d62d3-c40c-4044-8000-03bd12a6862f │              │
│ aac63a8c-21b2-4b4b-8000-03be453a9538 │ listen - ios │
└──────────────────────────────────────┴──────────────┘

10 rows in set. Elapsed: 0.166 sec. Processed 90.11 thousand rows, 1.54 MB (543.72 thousand rows/s., 9.29 MB/s.)

* поле unique_id

все это не то, видимо разговор слепого с глухим

Ну, ладно. Все равно спасибо!

CREATE TABLE impression.impression (
`date` Date, 
`timestamp` DateTime, 
`unique_id` UUID,
`client` String, 
`campaign` String, 
`publisher` String, 
`application` String,
`click_id` String, 
`os_name` String, 
`os_version` String, 
`pclick` String, 
`idfa` String, 
`gaid` String, 
`ip_address` String, 
`country_code` FixedString(2), 
`city` String, 
`isp` String, 
`latitude` Float64, 
`longitude` Float64, 
`referrer` String, 
`user_agent` String
) ENGINE = MergeTree(date, unique_id, 8192)

Подскажите, delta encoding  можно применить к полю timestamp? LowCardinality был бы эффективен для поля  user_agent, как я понял из вебинара Secrets of ClickHouse Query Performance by Altinity Ltd...