с масштабированием, было год назад 6М запросов в секунду, а сейчас 9-10М
мы недавно увеличили количество нод в кластере 36 -> 75 и началось много приключений связанных с записью данных в ClickHouse
Например, количество ошибок ClickHouse связанных с Zookeeper выросло на порядок "Zookeeper session expired"
В Яндекс.Метрике сколько нод Zookeeper используется и SSD ли? Читал какая сама конфигурация Zookeeper https://clickhouse.yandex/docs/en/operations/tips/ но не нашел деталей про setup
В Метрике тоже используется очередь - для получения данных, для промежуточных данных. Кластер ZooKeeper состоит из трёх серверов с SSD. В основной кластер ClickHouse идёт вставка с порядка нескольких десятков серверов, при этом каждый сервер вставляет не на все шарды, а на подмножество, и с каждого сервера идёт около десятка-сотни вставок в минуту. А всего на один кластер где-то несколько тысяч вставок в минуту, а на другой - около десятка тысяч вставок в минуту. Один ZooKeeper кластер обслуживает много кластеров ClickHouse.
А у вас все 75 серверов "слушают" очередь Кафки из одного consumer group и каждый пишет в ReplicatedMergeTree своим матвью? А зукипер для Кафки и для КХ - один и тот же?
Если кластер вырастает до более 20 нод, то лучше шардировать его на подкластеры с < 20 нод в каждом, чтобы не упереться в сетевые ограничения / таймауты / ошибки. Например, если вероятность сетевой ошибки за определенный интервал времени для подключения к одной ноде составляет 1%, то вероятность сетевой ошибки для 75 одновременных подключений составит 1-(1-0.01)^75=53% . Вместо вероятности сетевой ошибки аналогично "масштабируется" вероятность ошибки одной ноды кластера на весь кластер. Поэтому лучше делать, как в яндексе - шардировать данные по айди клиента на небольшие подкластеры - в каждом подкластере будет своя distributed таблица поверх данных подкластера. Для one-off аналитических запросов создать в сторонке дополнительную distributed таблицу поверх всех нод всех подкластеров.
Обсуждают сегодня