Итоги модуля: Распределённая архитектура

Модуль 09 охватил полный стек распределённого ClickHouse — от фундаментальных механизмов репликации до облачной архитектуры SharedMergeTree. Десять уроков провели нас от одного узла с Keeper до продакшен-кластеров с несколькими шардами, кворумными записями и параллельным чтением.

Ключевые решения проектирования

1. ReplicatedMergeTree + Keeper = фундамент репликации (DIST-01). Таблица получает имя пути в Keeper (/clickhouse/tables/{shard}/{db}/{table}), который координирует синхронизацию между репликами. Keeper хранит метаданные частей, лог репликации и DDL-блокировки.

2. Лог репликации и SYSTEM RESTORE REPLICA = механизм восстановления (DIST-02). GET_PART, MERGE_PARTS, MUTATE_PART — операции в system.replication_queue. При застрявших записях: SYSTEM RESTORE REPLICA пересоздаёт метаданные из Keeper. SYSTEM SYNC REPLICA ждёт завершения очереди.

3. Ключ шардирования: xxHash64 vs rand() (DIST-03). xxHash64(user_id) концентрирует все события пользователя на одном шарде (колокация), что ускоряет GROUP BY по user_id. rand() даёт равномерное распределение, но ломает колокацию. Выбор определяется паттерном запросов.

4. Выбор топологии: 1S_3R vs 2S_2R vs 3S_2R (DIST-04). 1 шард / 3 реплики = максимальная HA без горизонтального масштабирования записи. 2+ шарда = линейный рост пропускной способности записи. Каждая конфигурация — компромисс между HA, масштабированием и сложностью операционной поддержки.

5. Стратегия INSERT: локально vs через Distributed (DIST-05). Запись через Distributed-таблицу с internal_replication=true делегирует копирование репликам. Прямая запись в локальный ReplicatedMergeTree даёт меньше накладных расходов. Async-буферизация снижает latency за счёт риска потери данных при сбое.

6. Кворум: eventual vs strong consistency (DIST-06). insert_quorum требует подтверждения от N реплик до возврата клиенту. select_sequential_consistency гарантирует чтение после кворумной записи. Цена — дополнительная задержка. SharedMergeTree (Cloud) делает все записи кворумными по умолчанию.

7. Параллельные реплики: горизонтальный read scale-out (DIST-07). enable_parallel_replicas=1 + max_parallel_replicas распределяет сканирование гранул между репликами. Эффективно для больших полносканирующих запросов. Для точечных запросов с хорошей первичной фильтрацией выигрыш минимален.

8. Replicated Database Engine: DDL без ON CLUSTER (DIST-08). CREATE DATABASE ... ENGINE = Replicated(...) автоматически распространяет DDL через Keeper. CREATE TABLE на одном узле появляется на всех узлах кластера. Упрощает управление схемой в продакшене.

9. SharedMergeTree: Cloud-native будущее (DIST-09). Разделяет слой вычислений (ClickHouse nodes) и слой хранения (S3/GCS/Azure). Нет репликации данных между узлами — все читают из общего объектного хранилища. Горизонтальное масштабирование compute без миграции данных.

10. Keeper: мониторинг, восстановление, миграция (DIST-10). echo mntr | nc host 9181 показывает latency, leader/follower, количество znodes. can_become_leader=false для learner-реплик. clickhouse-keeper-converter для миграции с ZooKeeper. SYSTEM RESTORE REPLICA для восстановления реплики после потери данных.

Что дальше

Модуль 10: TTL, Tiered Storage и Data Lifecycle — управление жизненным циклом данных: автоматическое удаление, перенос на холодное хранилище, политики хранения на уровне таблицы и партиции. Знание распределённой архитектуры (этот модуль) необходимо для проектирования многоуровневого хранилища в кластерной среде.