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

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

Описание​

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

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

Терминология​

Реплика​

Копия данных. ClickHouse всегда имеет хотя бы одну копию ваших данных, и минимальное количество реплик составляет одну. Это важный момент, вы можете не привыкнуть считать оригинальную копию ваших данных как реплику, но именно такой термин используется в коде и документации ClickHouse. Добавление второй реплики ваших данных обеспечивает отказоустойчивость.

Шард​

Подмножество данных. ClickHouse всегда имеет хотя бы один шард для ваших данных, поэтому если вы не разделяете данные на несколько серверов, ваши данные будут храниться в одном шарде. Шардирование данных на несколько серверов можно использовать для распределения нагрузки, если вы превышаете мощность одного сервера. Целевой сервер определяется по шифрующему ключу, который задаётся при создании распределенной таблицы. Шифрующий ключ может быть случайным или являться результатом хеш-функции. Примеры развертывания, связанные с шардированием, будут использовать rand() в качестве шифрующего ключа и предоставят дополнительную информацию о том, когда и как выбрать другой шифрующий ключ.

Распределённая координация​

ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределённых DDL запросов. ClickHouse Keeper совместим с Apache ZooKeeper.

Среда​

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

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

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

Установка​

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

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

best practices

При настройке ClickHouse Server путем добавления или редактирования конфигурационных файлов, вы должны:

  • Добавлять файлы в директорию /etc/clickhouse-server/config.d/
  • Добавлять файлы в директорию /etc/clickhouse-server/users.d/
  • Оставить файл /etc/clickhouse-server/config.xml без изменений
  • Оставить файл /etc/clickhouse-server/users.xml без изменений

Конфигурация 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 — равный 3. Раздел конфигурации raft одинаков на всех трех серверах, и он выделен ниже, чтобы показать вам взаимосвязь между server_id и экземпляром server в конфигурации raft.

примечание

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

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

Макросы shard и replica упрощают работу с распределенным 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 и выполните запрос к распределенной таблице, чтобы увидеть обе строки.

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