Шарды и реплики таблиц

Примечание

Эта тема не применима к ClickHouse Cloud, где Parallel Replicas работают как несколько шардов в традиционных кластерах ClickHouse с архитектурой shared-nothing, а объектное хранилище заменяет реплики и обеспечивает высокую доступность и отказоустойчивость.

Что такое шарды таблиц в ClickHouse?

В традиционных кластерах ClickHouse с архитектурой shared-nothing шардинг используется, когда ① объём данных слишком велик для одного сервера или ② один сервер слишком медленно обрабатывает данные. На следующем рисунке показан случай ①, когда таблица uk_price_paid_simple превышает ёмкость одной машины:

В таком случае данные можно разделить между несколькими серверами ClickHouse в виде шардов таблиц:

Каждый шард содержит подмножество данных и функционирует как обычная таблица ClickHouse, к которой можно выполнять запросы независимо. Однако такие запросы будут обрабатывать только это подмножество, что может быть приемлемым вариантом в зависимости от распределения данных. Как правило, distributed table (часто одна на сервер) предоставляет единое представление всего набора данных. Она сама данные не хранит, а пересылает запросы SELECT на все шарды, собирает результаты и маршрутизирует операторы INSERT для равномерного распределения данных.

Создание распределённой таблицы

Для иллюстрации пересылки запросов SELECT и маршрутизации INSERT рассмотрим пример таблицы What are table parts, разбитой на два шарда на двух серверах ClickHouse. Сначала покажем оператор DDL для создания соответствующей таблицы типа Distributed для этой конфигурации:

CREATE TABLE uk.uk_price_paid_simple_dist ON CLUSTER test_cluster
(
    date Date,
    town LowCardinality(String),
    street LowCardinality(String),
    price UInt32
)
ENGINE = Distributed('test_cluster', 'uk', 'uk_price_paid_simple', rand())

Оператор ON CLUSTER делает запрос DDL распределённым DDL-запросом, инструктируя ClickHouse создать таблицу на всех серверах, перечисленных в определении кластера test_cluster. Для распределённой DDL требуется дополнительный компонент Keeper в архитектуре кластера.

Для параметров движка Distributed мы указываем имя кластера (test_cluster), имя базы данных (uk) для шардинговой целевой таблицы, имя шардинговой целевой таблицы (uk_price_paid_simple) и ключ шардинга для маршрутизации INSERT. В этом примере мы используем функцию rand, чтобы случайным образом распределять строки по шардам. Однако в качестве ключа шардинга может быть использовано любое выражение — даже сложное — в зависимости от сценария использования. В следующем разделе показано, как работает маршрутизация INSERT.

Маршрутизация INSERT

Диаграмма ниже показывает, как обрабатываются INSERT-запросы в distributed таблицу в ClickHouse:

① INSERT-запрос (с одной строкой), нацеленный на distributed таблицу, отправляется на сервер ClickHouse, на котором размещена эта таблица, либо напрямую, либо через балансировщик нагрузки.

② Для каждой строки из INSERT-запроса (в нашем примере только одна) ClickHouse вычисляет ключ шардинга (здесь rand()), берёт результат по модулю количества серверов-сегментов и использует это значение в качестве идентификатора целевого сервера (ID начинаются с 0 и увеличиваются на 1). Затем строка перенаправляется и ③ вставляется в таблицу соответствующего сервера-сегмента.

В следующем разделе объясняется, как работает перенаправление SELECT.

Перенаправление SELECT

Эта диаграмма показывает, как обрабатываются запросы SELECT с использованием distributed таблицы в ClickHouse:

① Агрегационный запрос SELECT, нацеленный на distributed таблицу, отправляется на соответствующий сервер ClickHouse — напрямую или через балансировщик нагрузки.

② Distributed таблица перенаправляет запрос на все серверы, содержащие сегменты целевой таблицы, где каждый сервер ClickHouse вычисляет свой локальный результат агрегации параллельно.

Затем сервер ClickHouse, на котором размещена изначально выбранная distributed таблица, ③ собирает все локальные результаты, ④ объединяет их в итоговый глобальный результат и ⑤ возвращает его отправителю запроса.

Что такое реплики таблиц в ClickHouse?

Репликация в ClickHouse обеспечивает целостность данных и отказоустойчивость за счет хранения копий данных сегментов на нескольких серверах. Поскольку сбои оборудования неизбежны, репликация предотвращает потерю данных, гарантируя, что у каждого сегмента есть несколько реплик. Записи можно направлять в любую реплику — напрямую или через distributed таблица, которая выбирает реплику для выполнения операции. Изменения автоматически распространяются на другие реплики. В случае сбоя или технического обслуживания данные остаются доступными на других репликах, а после восстановления отказавшийся хост автоматически синхронизируется, чтобы оставаться в актуальном состоянии.

Обратите внимание, что для репликации требуется компонент Keeper в архитектуре кластера.

На следующей диаграмме показан кластер ClickHouse из шести серверов, где у двух сегментов таблицы Shard-1 и Shard-2, представленных ранее, по три реплики каждый. В этот кластер отправляется запрос:

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

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

① Запрос к distributed таблица отправляется на соответствующий сервер ClickHouse — напрямую или через балансировщик нагрузки.

② Distributed таблица перенаправляет запрос на одну реплику из каждого сегмента, где каждый сервер ClickHouse, на котором размещена выбранная реплика, параллельно вычисляет свой локальный результат запроса.

Далее все работает так же, как и в конфигурациях без реплик, поэтому на диаграмме выше это не показано. Сервер ClickHouse, на котором размещена исходная distributed таблица, собирает все локальные результаты, объединяет их в итоговый глобальный результат и возвращает его отправителю запроса.

Обратите внимание, что в ClickHouse можно настраивать стратегию перенаправления запросов для ②. По умолчанию — в отличие от диаграммы выше — distributed таблица предпочитает локальную реплику, если она доступна, но можно использовать и другие стратегии балансировки нагрузки.

Где найти дополнительную информацию

Чтобы узнать больше, помимо данного обзорного введения в сегменты и реплики таблиц, ознакомьтесь с нашим руководством по развертыванию и масштабированию.

Мы также настоятельно рекомендуем это обучающее видео для более детального изучения сегментов и реплик в ClickHouse: