Развертывание кластера
Этот урок предполагает, что вы уже настроили локальный сервер ClickHouse.
Пройдя этот урок, вы научитесь настраивать простой кластер ClickHouse. Он будет небольшим, но отказоустойчивым и масштабируемым. Затем мы будем использовать один из примерных наборов данных, чтобы заполнить его данными и выполнить некоторые демонстрационные запросы.
Развертывание кластера
Этот кластер ClickHouse будет однородным. Вот шаги:
- Установите сервер ClickHouse на всех машинах кластера.
- Настройте конфигурации кластера в файлах конфигурации.
- Создайте локальные таблицы на каждом экземпляре.
- Создайте распределённую таблицу.
Распределённая таблица — это своего рода "представление" локальных таблиц в кластере ClickHouse. Запрос SELECT из распределённой таблицы выполняется с использованием ресурсов всех шардов кластера. Вы можете указать конфигурации для нескольких кластеров и создать несколько распределённых таблиц для предоставления представлений для разных кластеров.
Вот пример конфигурации для кластера с тремя шардами, с одной репликой каждый:
Для дальнейшей демонстрации давайте создадим новую локальную таблицу с тем же запросом CREATE TABLE, который мы использовали для hits_v1 в учебнике по развертыванию на одном узле, но с другим именем таблицы:
Создание распределённой таблицы предоставляет представление в локальные таблицы кластера:
Общей практикой является создание аналогичных распределённых таблиц на всех машинах кластера. Это позволяет выполнять распределённые запросы на любой машине кластера. Также есть альтернативный вариант создания временной распределённой таблицы для данного запроса SELECT с использованием remote табличной функции.
Давайте выполните INSERT SELECT в распределённую таблицу, чтобы распространить таблицу по нескольким серверам.
Как вы могли ожидать, ресурсоёмкие запросы выполняются в N раз быстрее, если они используют 3 сервера вместо одного.
В этом случае мы используем кластер с 3 шардом, и каждый шарда содержит одну реплику.
Для обеспечения надёжности в производственной среде мы рекомендуем, чтобы каждая шард содержала 2-3 реплики, распределённые между несколькими зонами доступности или дата-центрами (или, по крайней мере, стойками). Обратите внимание, что ClickHouse поддерживает неограниченное количество реплик.
Вот пример конфигурации для кластера с одной шардой, содержащей три реплики:
Чтобы включить нативную репликацию, требуется ZooKeeper. ClickHouse заботится о целостности данных на всех репликах и автоматически запускает процедуру восстановления после сбоя. Рекомендуется развернуть кластер ZooKeeper на отдельных серверах (где не работают другие процессы, включая ClickHouse).
ZooKeeper не является строгим требованием: в некоторых простых случаях вы можете дублировать данные, записывая их во все реплики из вашего прикладного кода. Такой подход не рекомендуется, так как в этом случае ClickHouse не сможет гарантировать целостность данных на всех репликах. Таким образом, это становится ответственностью вашего приложения.
Местоположения ZooKeeper указаны в файле конфигурации:
Кроме того, нам нужно установить макросы для идентификации каждой шарды и реплики, используемые при создании таблиц:
Если в момент создания реплицированной таблицы нет реплик, создаётся новая первая реплика. Если уже есть активные реплики, новая реплика клонирует данные из существующих. У вас есть возможность создать все реплицированные таблицы сначала, а затем вставить данные в них. Другой вариант - создать некоторые реплики и добавить другие после или во время вставки данных.
Здесь мы используем движок таблиц ReplicatedMergeTree. В параметрах мы указываем путь ZooKeeper, содержащий идентификаторы шарды и реплики.
Репликация работает в режиме многоуровневого управления. Данные могут загружаться в любую реплику, и система затем синхронизирует их с другими экземплярами автоматически. Репликация является асинхронной, поэтому в данный момент времени не все реплики могут содержать недавно вставленные данные. По крайней мере одна реплика должна быть активной, чтобы обеспечить приём данных. Другие синхронизируют данные и восстанавливают целостность, как только они вновь станут активными. Обратите внимание, что такой подход позволяет снизить вероятность потери недавно вставленных данных.