несколько вопросов.
Дано:
* Одна нода - сервер на 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 млрд/сутки. Порекомендуйте, пожалуйста, конфигурацию кластера и характеристики серверов.
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ГБ озу
Обсуждают сегодня