Перейти к основному содержимому
Перейти к основному содержимому

Масштабирование

Описание​

Эта примерная архитектура предназначена для обеспечения масштабируемости. В нее входят три узла: два сервера с объединенными ClickHouse и координацией (ClickHouse Keeper) и третий сервер с только ClickHouse Keeper для завершения кворума из трех. В этом примере мы создадим базу данных, таблицу и распределенную таблицу, которая сможет запрашивать данные на обоих узлах.

Уровень: Базовый​

Terminology​

Replica​

A copy of data. ClickHouse always has at least one copy of your data, and so the minimum number of replicas is one. This is an important detail, you may not be used to counting the original copy of your data as a replica, but that is the term used in ClickHouse code and documentation. Adding a second replica of your data provides fault tolerance.

Shard​

A subset of data. ClickHouse always has at least one shard for your data, so if you do not split the data across multiple servers, your data will be stored in one shard. Sharding data across multiple servers can be used to divide the load if you exceed the capacity of a single server. The destination server is determined by the sharding key, and is defined when you create the distributed table. The sharding key can be random or as an output of a hash function. The deployment examples involving sharding will use rand() as the sharding key, and will provide further information on when and how to choose a different sharding key.

Distributed coordination​

ClickHouse Keeper provides the coordination system for data replication and distributed DDL queries execution. ClickHouse Keeper is compatible with Apache ZooKeeper.

Среда​

Диаграмма архитектуры​

УзелОписание
chnode1Данные + ClickHouse Keeper
chnode2Данные + ClickHouse Keeper
chnode3Используется для кворума ClickHouse Keeper
примечание

В продакшн средах мы настоятельно рекомендуем, чтобы ClickHouse Keeper работал на выделенных хостах. Эта базовая конфигурация запускает функциональность Keeper в процессе сервера ClickHouse. Инструкции для развертывания ClickHouse Keeper в отдельном режиме доступны в документации по установке.

Установка​

Установите ClickHouse на трех серверах, следуя инструкциям для вашего типа архива (.deb, .rpm, .tar.gz и т.д.). В этом примере вам нужно будет следовать инструкциям по установке ClickHouse Server и Client на всех трех машинах.

Редактирование файлов конфигурации​

best practices

When configuring ClickHouse Server by adding or editing configuration files you should:

  • Add files to /etc/clickhouse-server/config.d/ directory
  • Add files to /etc/clickhouse-server/users.d/ directory
  • Leave the /etc/clickhouse-server/config.xml file as it is
  • Leave the /etc/clickhouse-server/users.xml file as it is

Конфигурация chnode1​

Для chnode1 есть пять файлов конфигурации. Вы можете выбрать, чтобы объединить эти файлы в один, но для ясности в документации может быть проще рассмотреть их отдельно. При чтении файлов конфигурации вы увидите, что большинство конфигураций совпадают между chnode1 и chnode2; различия будут выделены.

Конфигурация сети и логирования​

Эти значения могут быть настроены по вашему усмотрению. Эта примерная конфигурация предоставляет вам журнал отладки, который будет обновляться при достижении 1000M трижды. ClickHouse будет слушать на IPv4 сети на портах 8123 и 9000, и будет использовать порт 9009 для межсерверного общения.

Конфигурация ClickHouse Keeper​

ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределенных DDL-запросов. ClickHouse Keeper совместим с Apache ZooKeeper. Эта конфигурация включает ClickHouse Keeper на порту 9181. Выделенная строка указывает, что этот экземпляр Keeper имеет server_id равным 1. Это единственное отличие в файле enable-keeper.xml на трех серверах. chnode2 будет иметь server_id, установленный на 2, а chnode3 будет иметь server_id, установленный на 3. Раздел конфигурации raft одинаков на всех трех серверах, и он выделен ниже, чтобы показать вам связь между server_id и экземпляром server в конфигурации raft.

примечание

Если по какой-либо причине узел Keeper заменяется или перестраивается, не используйте существующий server_id. Например, если узел Keeper с server_id равным 2 перестраивается, дайте ему server_id равный 4 или выше.

Конфигурация макросов​

Макросы shard и replica снижают сложность распределенного DDL. Конфигурируемые значения автоматически подставляются в ваши DDL-запросы, что упрощает вашу DDL. Макросы для этой конфигурации указывают номер шардов и реплик для каждого узла. В этом примере с 2 шардом и 1 репликой, макрос реплики — replica_1 на обоих chnode1 и chnode2, так как есть только одна реплика. Макрос шардов — 1 на chnode1 и 2 на chnode2.

Конфигурация репликации и шардирования​

Начнем с верхней части:

  • Раздел remote_servers XML указывает каждый из кластеров в среде. Атрибут replace=true заменяет образец remote_servers в конфигурации по умолчанию ClickHouse на конфигурацию remote_servers, указанную в этом файле. Без этого атрибута удаленные серверы в этом файле были бы добавлены в список образцов по умолчанию.
  • В этом примере есть один кластер, названный cluster_2S_1R.
  • Создается секрет для кластера с именем cluster_2S_1R со значением mysecretphrase. Секрет разделяется между всеми удаленными серверами в среде, чтобы гарантировать, что правильные серверы объединяются вместе.
  • Кластер cluster_2S_1R имеет два шарда, и каждый из этих шардов имеет одну реплику. Ознакомьтесь с диаграммой архитектуры в начале этого документа и сравните ее с двумя определениями shard в XML ниже. В каждом определении шардов есть одна реплика. Реплика предназначена для этого конкретного шард. Хост и порт для этой реплики указаны. Реплика для первого шард в конфигурации хранится на chnode1, а реплика для второго шард в конфигурации хранится на chnode2.
  • Внутренняя репликация для шардов установлена на true. Каждый шард может иметь параметр internal_replication, определенный в файле конфигурации. Если этот параметр установлен на true, операция записи выбирает первую здоровую реплику и записывает данные в нее.

Настройка использования Keeper​

В вышеприведенных файлах уже была настроена ClickHouse Keeper. Этот файл конфигурации use-keeper.xml настраивает ClickHouse Server на использование ClickHouse Keeper для координации репликации и распределенных DDL. Этот файл указывает, что ClickHouse Server должен использовать Keeper на узлах chnode1 - chnode3 на порту 9181, и файл одинаков на chnode1 и chnode2.

Конфигурация chnode2​

Поскольку конфигурация очень похожа на chnode1 и chnode2, здесь будут указаны только отличия.

Конфигурация сети и логирования​

Конфигурация ClickHouse Keeper​

Этот файл содержит одно из двух отличий между chnode1 и chnode2. В конфигурации Keeper server_id установлен на 2.

Конфигурация макросов​

Конфигурация макросов имеет одно из отличий между chnode1 и chnode2. shard установлен на 2 на этом узле.

Конфигурация репликации и шардирования​

Настройка использования Keeper​

Конфигурация chnode3​

Поскольку chnode3 не хранит данные и используется только для ClickHouse Keeper, чтобы обеспечить третий узел в кворуме, у chnode3 есть только два файла конфигурации, один для настройки сети и логирования, а другой для настройки ClickHouse Keeper.

Конфигурация сети и логирования​

Конфигурация ClickHouse Keeper​

Тестирование​

  1. Подключитесь к chnode1 и проверьте, что кластер cluster_2S_1R, настроенный выше, существует
  1. Создайте базу данных в кластере
  1. Создайте таблицу с движком таблицы MergeTree в кластере.
примечание

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

  1. Подключитесь к chnode1 и вставьте строку
  1. Подключитесь к chnode2 и вставьте строку
  1. Подключитесь к любому узлу, chnode1 или chnode2, и вы увидите только ту строку, которая была вставлена в ту таблицу на этом узле. например, на chnode2
  1. Создайте распределенную таблицу для запроса обоих шардов на обоих узлах. (В этом примере функция rand() установлена в качестве ключа шардирования, так чтобы это случайным образом распределяло каждую вставку)
  1. Подключитесь к chnode1 или chnode2 и выполните запрос к распределенной таблице, чтобы увидеть обе строки.

Дополнительная информация о:​