Сегменты и реплики таблиц

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

Что такое сегменты таблицы в ClickHouse?

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

Создание distributed таблицы

Чтобы проиллюстрировать перенаправление запроса SELECT и маршрутизацию INSERT, рассмотрим таблицу из примера Что такое части таблицы, разделённую между двумя сегментами на двух серверах 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

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

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

Эта диаграмма показывает, как в ClickHouse обрабатываются запросы SELECT с distributed таблицей:
① Запрос 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:

​Что такое сегменты таблицы в ClickHouse?

​Создание distributed таблицы

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

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

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

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

Что такое сегменты таблицы в ClickHouse?

Создание distributed таблицы

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

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

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

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