Comments 3
Спасибо за статью! Вы упомянули, что ClickHouse не гарантирует корректное шардирование автоматически и это зона ответственности пользователей. Какие инструменты или практики вы рекомендуете для мониторинга корректности шардирования в кластере?
Привет, спасибо!
Ключ шардирования есть только в Distributed-таблице - локальные таблицы не знают про то, какие в них могут и не могут храниться данные. Кроме того, вывод ключа не обязан быть детерминированным - можно шардировать, например, по тому, какой сегодня день недели (от 1 до 7) - а такое шардирование и при желании не проверишь! Поэтому, видимо, и нет никакой специальной команды для проверки.
Для ручной проверки могу сообразить скрипт вроде такого
WITH key as sharding_key, /* вписать ключ шардирования */
cnt as shards_ttl_num /* вписать количество шардов */
SELECT hostName() as host,
count() as rows_cnt,
countIf(sharding_key % shards_ttl_num + 1 != shardNum()) as wrong_sharding_cnt
FROM table.distributed /* вписать имя distributed таблицы */
SETTINGS distributed_group_by_no_merge=1
/* если wrong_sharding_cnt больше нуля, значит, есть строки, которые лежат не там, где должны */
Можно попробовать добавить локальным таблицам constraint-ы. Например:
ALTER TABLE test.table ADD CONSTRAINT sharding_is_correct CHECK ((gi_id % 5) + 1) = toUInt8(getMacro('shard'))
/* сработает, если есть макрос shard. цифру 5 надо заменить на кол-во шардов */
Но лучше просто наладить процесс так, чтобы строки не могли попасть туда, куда не должны. И не давать прав на вставку тем, кто может что-то испортить. Тогда можно обходиться без проверок.
очень легко читается, все наглядно и понятно, спасибо!
Шардированный кластер ClickHouse