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