идеи
основная концепция:
- Фрагментация
- копировать
- кластер
Метод реализации распределенной таблицы:
- Реплицированная таблица: префикс движка Replicated, и базовая функция репликации может быть автоматически реализована движком.
- Распределенная таблица: при использовании распределенного движка принцип аналогичен природе представления. Сначала вам нужно создать физическую таблицу в каждом экземпляре, а затем сопоставить ее с фактической физической таблицей.
Метод конфигурации
- Настройте свойства zk clickhouse
- Настроить кликхаус-кластер
- Настройте такие параметры, как сегментирование {shard}
концепция
Фрагментация: Разделите данные на несколько частей без дублирования между частями. Примечание: искажение данных
копировать: Реплика является избыточной, с несколькими резервными копиями, а содержимое одного и того же сегмента реплики точно такое же.
Эквивалент механизма разделения (Partition) и копирования (Replication) в Kafka. В основном это решение максимизации использования распределенных ресурсов и принципа доступности в принципе CEP.
Логические концепции шардинга и реплик показаны на следующем рисунке:
кластер: Логическая концепция, несколько экземпляров кликхауса могут абстрагировать несколько разных кластеров кликхауса.
В Clickhouse нет концепции централизованных узлов, и распределение ролей всех узлов одинаковое.
И его можно разделить на несколько кластеров.Имя кластера основано на имени тега, настроенном в файле config.xml.
Механизм поиска осколков
Как найти осколок, в котором находятся данные
механизм синхронизации реплик
Механизм синхронизации реплик:
TODO:? ? ? основной принципТочка знаний.
Через zk отслеживать изменения действий разных экземпляров ck,
Узел-реплика извлекает журнал поведения главного узла и снова полностью его выполняет (??? Или напрямую извлекает файл данных результата?)
Метод построения распределенной таблицы
копировать таблицу
используется толькоReplicated***TreeМеханизм семейства таблиц реплик требуется для применения возможностей реплик.
Таблица реплик использует стратегию синхронизации реплик, которая поставляется вместе с движком.
Zookeeper является важным компонентом резервного копирования кластера ck, он только отслеживает состояние между различными экземплярами и не задействует передачу данных.
ReplicatedMergeTree имеет некоторые существенные особенности в дизайне реплик:
- Зависит от ZooKeeper
- Копия на уровне таблицы
- Архитектура с несколькими мастерами: запросы INSERT и ALTER могут выполняться на любой реплике, и их эффекты одинаковы. Эти операции распространяются на каждую реплику для локального выполнения с помощью возможностей совместной работы ZooKeeper.
- Блок данных блока
Если ReplicatedMergeTree необходимо использовать несколько конфигураций реплик, необходимо использовать две конфигурации.
- zk_path
- replica_name: определяет имя реплики, созданной в ZooKeeper, которое является уникальным идентификатором для различения разных экземпляров реплики. Общепринятым соглашением об именовании является использование доменного имени сервера, на котором он размещен.
Оператор создания таблицы для таблицы-реплики:
CREATE TABLE dc_eth.events_local ON CLUSTER new_cluster
(ts_date Date,
user_id Int64,
event_type String,
site_id Int64,
groupon_id Int64 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/my_db/my_table','{replica}')
PARTITION BY toYYYYMM(ts_date)
ORDER BY (site_id);;
Определение параметра:
- ReplicatedMergeTree: имя движка, префиксы с Replicated — это все реплицированные движки таблиц, соответствующие обычным локализованным движкам таблиц;
- Параметр 1: Путь прослушивания zk, где {shard} — параметр, настраиваемый в конфиге, чтобы гарантировать, что путь, отслеживаемый каждым экземпляром, отличается; такие пути, как /clickhouse/** в пути, прописываются условно;
- Параметр 2: {replica} представляет имя реплики, обычно это имя узла.
Распределенная таблица
Распределенные таблицы по своей природе являются представлениями.Они сопоставляются с локальными таблицами каждого экземпляра через отношения.Хранение и запросы зависят от созданной локальной таблицы (локальной), и при удалении распределенной таблицы локальная таблица не будет удалена, а ее необходимо удалить вручную.
Метод создания таблицы:
- Локальные таблицы теперь создаются в каждом экземпляре кластера.
- в настоящее время использует
DistributedДвижок, который связывает локальные таблицы в кластере
ENGINE = Distributed(ck_cluster, my_db, my_table, rand());
Определение параметра:
- ck_cluster: имя кластера;
- my_db: имя библиотеки;
- my_table: имя таблицы, имя библиотеки и имя таблицы в каждом экземпляре должны совпадать;
- rand(): выбирает способ маршрутизации осколков.
Метод конфигурации
настроить зк
Настройте zookeeper, zk является базовым компонентом, перезапустите службу clickhouse, добавьте конфигурацию zk
В пути /etc/clickhouse-server/config.d/ создайте новый zks.xml
<?xml version="1.0"?>
<yandex>
<zookeeper>
<node index="1">
<host>cy3.dc</host>
<port>2181</port>
</node>
<node index="2">
<host>cy4.dc</host>
<port>2181</port>
</node>
<node index="3">
<host>cy5.dc</host>
<port>2181</port>
</node>
</zookeeper>
</yandex>
В config.xml введите только что созданный файл конфигурации.
<yandex>
<!-- config原有配置信息 -->
<include_from>/etc/clickhouse-server/config.d/zks.xml</include_from>
</yandex>
Способ проверки успешной конфигурации zk:
select * from system.zookeeper where path = '/clickhouse';
-- 能出结果，说明成功
Примечание: метод перезапуска clickhouse
systemctl start clickhouse-server.service:启动clickhouse服务
systemctl stop clickhouse-server.service:关停clickhouse服务
systemctl status clickhouse-server.service:查看clickhouse服务状态
Настройка свойств сегмента
Шардинг для построения конфигурации кластера, расположение конфигурации: /etc/clickhouse-server/config.xml. Настроен как элемент конфигурации 1 сегмент, 1 реплика (один исходный узел, один резервный узел).
<!-- ReplicatedMergeTree 副本表配置 -->
<!-- CK1节点中的配置 -->
<macros>
<shard>01</shard>
<replica>ck1</replica>
</macros>
<!-- CK2节点中的配置 -->
<macros>
<shard>01</shard>
<replica>ck2</replica>
</macros>
-
replica: настройка информации об узле резервной синхронизации текущего узла. -
shard: указывает конфигурацию в информации о шардинге кластера, в кластере, который я настраиваюshard_1 -
replica: узел реплики -
layer: указываем флаг нашего кластера или используемclusterключевые слова
Конфигурация здесь представляет собой элемент пользовательского параметра, который используется для получения переменных полей, таких как {shard}, при создании таблицы.
Настроить кластер
Логические концепции, определенные в config.xml, или отдельный файл конфигурации, на который есть ссылка в config.xml.
<!-- 配置文件：Config.xml -->
<!-- clickhouse集群节点配置 -->
<chuying_ck_cluster>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>cy11.dc</host>
<port>9000</port>
</replica>
<replica>
<host>cy7.dc</host>
<port>9000</port>
</replica>
</shard>
</chuying_ck_cluster>
Определение ярлыка:
элемент метки сегмента: экземпляр раздела
реплика: экземпляр реплики
internal_replication: Этот элемент тега управляет записью данных в распределенную таблицу, распределенная таблица будет контролировать, будет ли запись записываться во все реплики.
возникшие проблемы
- После удаления таблицы копирования и создания новой таблицы с таким же именем zk сообщит об ошибке, что путь уже существует.
Причина: zk использует метод мониторинга, пассивно не получает информацию и удаляет просроченную информацию через несколько минут.
Решение: измените путь создания таблицы zk для реплицированной таблицы или добавьте {UUID} к пути создания таблицы, чтобы случайным образом сгенерировать идентификатор.
ReplicatedMergeTree('/clickhouse/tables/{shard}/my_db/my_table/{UUID}','{replica}')