Развертывание кластера
Этот учебник предполагает, что вы уже настроили локальный сервер 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, содержащий идентификаторы шардов и реплик.
Репликация работает в режиме мульти-мастера. Данные могут загружаться в любую реплику, а система затем автоматически синхронизирует их с другими экземплярами. Репликация асинхронна, поэтому в данный момент не все реплики могут содержать недавно вставленные данные. По крайней мере, одна реплика должна быть активна, чтобы разрешить прием данных. Другие будут синхронизировать данные и исправлять согласованность, как только они снова станут активными. Обратите внимание, что этот подход позволяет снизить вероятность потери недавно вставленных данных.