ClickHouse: использование ha sh и internal_replication в распределенных и реплицированных таблицах - PullRequest
Новая
       110

ClickHouse: использование ha sh и internal_replication в распределенных и реплицированных таблицах

0 голосов
/ 26 мая 2020

Я прочитал это в документации Distributed Engine о настройке internal_replication.

Если для этого параметра установлено значение «true», операция записи выбирает первую работоспособную реплику и записывает в него данные. Используйте эту альтернативу, если распределенная таблица «просматривает» реплицированные таблицы. Другими словами, если таблица, в которую будут записываться данные, сама будет их реплицировать.

Если установлено значение «false» (по умолчанию), данные записываются во все реплики. По сути, это означает, что распределенная таблица реплицирует сами данные. Это хуже, чем использование реплицированных таблиц, потому что согласованность реплик не проверяется, и со временем они будут содержать немного другие данные.

Я использую типичный KafkaEngine с настройкой Materialized View (MV) плюс использование таблиц Distributed. У меня есть кластер экземпляров, где есть таблицы ReplicatedReplacingMergeTree и Distributed, как вы можете видеть ниже: 


CREATE TABLE IF NOT EXISTS pageviews_kafka (
// .. fields
) ENGINE = Kafka
SETTINGS
  kafka_broker_list = '%%BROKER_LIST%%',
  kafka_topic_list = 'pageviews',
  kafka_group_name = 'clickhouse-%%DATABASE%%-pageviews',
  kafka_format = 'JSONEachRow',
  kafka_row_delimiter = '\n';

CREATE TABLE IF NOT EXISTS pageviews (
   // fields
) ENGINE ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/%%DATABASE%%/pageviews', '{replica}', processingTimestampNs)
PARTITION BY toYYYYMM(dateTime)
ORDER BY (clientId, toDate(dateTime), userId, pageviewId);

CREATE TABLE IF NOT EXISTS pageviews_d AS pageviews ENGINE = Distributed('my-cluster', %%DATABASE%%, pageviews, sipHash64(toString(pageviewId)));

CREATE MATERIALIZED VIEW IF NOT EXISTS pageviews_mv TO pageviews_d AS
SELECT
 // fields 
FROM pageviews_kafka;

Вопросы:

  1. I Я использую значение по умолчанию internal_replication в распределенной таблице, что неверно. Означает ли это, что распределенная таблица записывает все данные в все реплики? Итак, если я установлю для internal_replication значение true, тогда каждый экземпляр ReplicatedReplacingMergeTree будет иметь только свою долю всей таблицы, а не всего набора данных, что оптимизирует хранение данных? Если это так, репликация тоже будет скомпрометирована - как вы можете определить определенное количество реплик?

  2. Я использую идентификатор объекта в качестве дистрибутива ha sh. Я прочитал в FAQ по ClickHouse Kafka Engine от Altinity, вопрос «В. Как я могу использовать таблицу движка Kafka в кластере?», Следующий:

Другая возможность - передать sh данные из таблицы движка Kafka в распределенную таблицу. Однако это требует более тщательной настройки. В частности, распределенная таблица должна иметь некоторый ключ сегментирования (а не случайный ha sh). Это необходимо для правильной работы дедупликации ReplicatedMergeTree. Распределенные таблицы будут повторять попытки вставки одного и того же блока, и ClickHouse может их вывести.

Однако я использую здесь полуслучайный ha sh (это идентификатор объекта, идея поскольку разные копии одного и того же экземпляра объекта - pageview в данном примере - сгруппированы вместе). В чем проблема? Почему не рекомендуется?

1 Ответ

0 голосов
/ 26 мая 2020

Я использую значение по умолчанию internal_replication в распределенной таблице, которое является ложным.

НЕ ДОЛЖЕН. Это ДОЛЖНО БЫТЬ ИСТИНА. Вам повезло и данные еще не дублировались из-за дедупликации вставки. Но в конечном итоге он будет продублирован, потому что ваша распределенная таблица выполняет две идентичные вставки в две реплики, а реплицированная таблица реплицирует вставленные данные в другую реплику (в вашем случае вторая реплика пропускает вставку из распределенной, потому что вам повезло).

тогда каждый экземпляр ReplicatedReplacingMergeTree будет иметь только свою долю всей таблицы

вы ошибаетесь.

Распределенные (internal_replication = true) вставляются во ВСЕ ЧЕРТЫ.

Распределенные (internal_replication = false) вставляются во ВСЕ ОБОЗНАЧЕНИЯ + во ВСЕ РЕПЛИКИ.

Требуется более тщательная настройка. Я использую полуслучайную ha sh здесь

Требуется более тщательная настройка, и вы это сделали !!!, используя - sipHash64(toString(pageviewId))

Вы стабилизировали порядок, и если вставка повторяется, те же строки переходят в один и тот же осколок, потому что номер осколка для строки вычисляется с использованием pageviewId, а не rand().

...