11016
Обсуждаем ClickHouse
Добрый вечер. Подскажите, пжл, нужна копия таблицы на всех шардах. Возможно как-то настроить репликацию между шардами чтобы не писать в каждый шард по отдельности?
Читать полностью…
1) TTL WHERE is unusable garbage #45608 use TTL instead (you can express anything in TTL expression, without using WHERE #73781 (comment)).
https://github.com/ClickHouse/ClickHouse/issues/77099#issuecomment-2783205492
2) используйте округление toStartOfDate в ttl
Ну так то да))) если не указать, то наверное другого места и нет. Но могу по Незнайке ошибаться!
Читать полностью…
ну то есть таки не знает ))
вы ему явно указываете куда сходить либо через ON CLUSTER либо параметрами в remote
В этом случае запрос улетает в Keeper, который раскидывает запрос по всем нодам. А в логах видно, что запрос до окончания выполнения лежит в distributed_queue
Читать полностью…
Если я правильно понимаю, то таки в курсе что есть ноды. Ну по крайней мере знает куда обратиться при необходимости. Необходимость образуется при появлении опции on cluster при определении таблицы
Читать полностью…
кипер - это просто база данных, у него нет функции гонять чужие данные
Читать полностью…
нода ничего не смотрит
экземпляры КХ не знают друг о друге
парты туда-сюда гоняет кипер
У вас все метаданные записаны в зукипере.
Каждая вставка создает отдельную не изменяемую частицу данных. И вы вставили в ноду 1, появилась запись в зукипере ( тут я точно не знаю как работает), вторая нода смотрит, что у нее нету этих частей данных, и запрашивает с ноды 1.
Так же и наоборот.
Точный механизм репликации я не знаю, но в моем представление примерно так.
Коллеги, добрый день!
Есть ли какие-то примеры реализаций кластера clickhouse между несколькими ЦОД? Статьи может какие-нибудь? Было бы интересно почитать
Всё равно кое чего не понимаю. Хотя наверное это уже другой вопрос. Если некая пачка заехала на Ноду2 и нода1 упала прежде, чем туда успели реплицироваться данные с Ноды2!!. То всё?? Или таки нет?
Читать полностью…
Я сделал конфигурационный файл и положил его в папку config.d
Читать полностью…
Вот здесь есть ответ, у меня такое было на proxmox
https://github.com/ClickHouse/ClickHouse/issues/66045
если расстояние большое (пинг больше 15мс), то все зукиперы в одном датацентре, пишем тоже в том же датацентре где зукиперы, остальные датацентры типа только реплицируют и не используются для инсертов, таким образом у меня работал КХ через океан, зукиперы и инсерты в DE, реплики в US
если расстояние небольшое то все проще
в зукипере очередь, нода поднимется и реплицирует, если очередь уже провернулась и партов нет (смержились), то в любом случае нода когда поднимается проверяет свой набор партов с тем набором что у других реплик (через список в зукипере) и начинает синхронизировать свой список, удаляет лишние парты, качает недостающие
Читать полностью…
Кликхаус машина - ничего не знает о других машинах в кластере.
Это не ГП.
Ну это чисто вот такой хелп функционал.
Который запускает SQL так же как бы его запускали руками.
Основываясь на записи в system.clusters
ну он не особо в курсе, у него просто задача скопировать данные.
Кликхаус мержит данные сихронно между репликами.
Вот что пишут :
есть опция ON CLUSTER. В этом случае, Clickhouse обращается к конфигурационному файлу, где указаны все ноды кластера и выполняет запрос на каждом из них
я упростил свой текст
конечно же данные переносит магия
Всмысле, клик знает о других репликах. Он же с одной реплике на другую реплику скачивает данные.
Понятное дело, он не вкурсе конфигов и т.д.
Релики таблицы.
Ну вот именно это и надо было понять. Механизм. А более подробно уже ненадо!!. Спасибо!
Читать полностью…
Я наверное понимаю. Спасибо большое всем!!
Читать полностью…
Клиент подключен к конкретному серверу, на нем все данные и заходят в таблицу, потом реплицируются на другие ноды.
Читать полностью…
Мастер - Мастер репликация, говорит, что везде будет один и тот же набор данных.
Читать полностью…
а не подскажете, как совет применили? allow_simdjson это же сессионная опция, а если преобразования во view? По всякому пробовал, в SETTINGS проставлять, в глоабльном конфиге - так не работает. Пока что помогает только visitParamExtractRaw использовать вместо JSONExtractRaw
Читать полностью…
Привет! Кто-нибудь сталкивался с таким? На версии 24.8.14.39 при простейших операциях с JSON'ом всегда запросы падают с аллокацией памяти
SELECT
length(json_str),
JSONExtractString(json_str, 'key') AS extracted
FROM (
SELECT '{"key":"' || randomString(1) || '"}' AS json_str
)
Received exception from server (version 24.8.14):
Code: 173. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Couldn't allocate 11 bytes when parsing JSON: while executing 'FUNCTION JSONExtractString(json_str :: 2, 'key' :: 4) -> JSONExtractString(json_str, 'key') String : 5'. (CANNOT_ALLOCATE_MEMORY)