А подскажите, чем нужно руководствоваться при выборе sharding key для

Question

А подскажите, чем нужно руководствоваться при выборе sharding key для

distributed таблиц? Допустим, что есть таблица со следующими колонками:

date Date
entity_id UUID
bucket_timestamp DateTime('UTC')
measure_a UInt64
measure_b Decimal(18, 2)
Используется PARTITION BY toYYYYMM(date). Мне кажется логичным сделать шардирование по entity_id. Есть какие-то ситуации, в которых имело бы смысл, допустим, ещё и date учитывать для разнесения данных одной сущности по нескольким серверам?

#backend #clickhouse #database #devops #programming #russian

0

13.07.2021

9 ответов

10 просмотров

Viacheslav Chernyshev Автор вопроса

Sergey
Исходить нужно из селектов которые будут выполнять...

Запросы в основном для одной entity_id, но затрагивают очень много дней. Сейчас уже к серверу подключиться не могу для тестов, поэтому накалякаю пример на коленке. Что-то вроде такого: select bucket, sum(measure_a) / count(distinct date) as result from table where toYear(date) = 2020 and entity_id = <...> group by toStartOfInterval(toTime(bucket_timestamp, 'America/New_York'), interval 15 seconds) as bucket order by bucket То есть внутри одного дня бакеты схлопываются до заданной пользователем точности и потом вычисляется среднее значение за год.

0

13.07.2021

Viacheslav Chernyshev Автор вопроса

Добрый вечер. По вот этому вопросу может кто-нибудь подсказать? Мне всё ещё интересно, есть ли какие-то ситуации, когда имеет смысл разносить данные одной сущности по нескольким серверам :) Ниже там есть примерное описание того, какого рода запросы по этим данным планируется делать.

0

14.07.2021

Denny [Altinity]

Viacheslav Chernyshev
Добрый вечер. По вот этому вопросу может кто-нибуд...

никто вам не ответит. Например у вас таблица ReplacingMergeTree и надо коллапсить записи по entity_id, в этом случае конечно нельзя шардить по дате. Я вчера на митинге с клиентом обсудил 4 возможных схемы шардирования для одной и той же таблицы. У каждой свои плюсы и минусы, которые исходят из запросов которые будут делаться к таблице, сама структура таблицы мало вообще кого волнует в этом случае.

0

14.07.2021

Viacheslav Chernyshev Автор вопроса

Denny [Altinity]
никто вам не ответит. Например у вас таблица Repla...

Коллапсить в этом конкретном случае ничего не нужно. Данные записываются один раз и никогда не меняются. Меня плюсы и минусы различных подходов как раз и интересуют. О них где-нибудь почитать/послушать можно?

0

14.07.2021

critskiy

Viacheslav Chernyshev
Коллапсить в этом конкретном случае ничего не нужн...

Только ручками исследовать для ваших данных, не припоминаю докладов

0

14.07.2021

Denny [Altinity]

Viacheslav Chernyshev
Коллапсить в этом конкретном случае ничего не нужн...

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

0

14.07.2021

Viacheslav Chernyshev Автор вопроса

critskiy
Только ручками исследовать для ваших данных, не пр...

Окей, буду тогда тестировать методом тыка и в trace логи смотреть.

0

14.07.2021

Viacheslav Chernyshev Автор вопроса

Denny [Altinity]
если надо делать очень быстрые мелкие риалтайм зап...

Спасибо!

0

14.07.2021