на Log engine ещё бы репликацию/sharding натянуть типа ReplicatedMT, цены бы не было (наверно можно через distributed)

коллеги, подскажите пожалуйста еще раз, при создании реплицированной таблицы

ReplicatedMergeTree('/clickhouse/tables/{shard}/hits', '{replica}',

если в кластере два шарда, в каждом шарде два сервера (реплика), макрос {shard} в конфиге скажем для 3го сервера, который относится ко 2у шарду должен быть 2 (по номеру шарда) или 3 (просто по номеру сервера) ?

По номеру шарда

Привет! Делаю запрос с left join. В левой части делается limit 10. Колонки которые участвуют в USING находzтся в ORDER BY правой части. По логам вижу, что для правой части индекс не применяется. Может как-то кликхаус брать результаты левой части и фильтровать правую по индексу?

👍

да, поменяйте местами или используйте фильтрацию с IN для большой таблицы

А как поможет поменять местами? Сначала выполняется правая часть?

там уже столько версий и параметров, что я запутан... лучше в трейс смотреть

там видно кто первый, кто второй, итд

КХ не умеет индексы для джойна, пишите подзапрос для правой таблицы

IN такой же как левая часть? Если запрос тот же, то он 1 раз исполнится?

нет, и даже будет разный результат иметь. Поэтому левую limit 10 во временную таблицу отдельным запросом.
лучше конечно избегать джойнов, особенно таких

Спасибо!

есть вопрос по кликхаус копиру:
есть кластер N шардов, данные которого надо перенести на новый кластер с M шардов
1) правильно ли я понимаю, что если я запущу один копиер на любом из кластеров, то он будет через одну точку тягать данные с N шардов на M шардов?
2) для лучшей параллельности процесса лучше ли будет запустить на каждой ноде шарда по копиеру и в source_cluster прописать 127.0.0.1 (тяни с меня, но не с соседней машины)?
3) если пункт 2 соблюдается, то улучшится ли параллельность процесса, если реплики тоже будут так данные передавать (или они законфликтуют по набору данных?)
4) --task-path надо для каждой ноды с копиером делать выделенный, или учитывая что сорс у меня 127.0.0.1 можно через один? не законфликтуют ли воркеры за task_active_workers ноду в зукипере?

коллеги, еще один дилетантский вопрос, про репликацию, шарды и кафку

есть кластер
шард1
сервер1 (реплика)
сервер2 (реплика)
шард2
сервер3 (реплика)
сервер4 (реплика)

есть кафка, хочу из нее читать на каждом сервере, сделал следующее, но похоже это не правильно:

есть таблица kafka_replica с

ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/bi/0/kafka_replica', '{replica}')

читаю стрим кафки kafka_stream в materizlied view и далее его отображаю в kafka_replica:

CREATE MATERIALIZED VIEW bi.kafka_materialized TO bi.kafka_replica AS
SELECT
...
FROM
  (SELECT
  ...
  FROM bi.kafka_stream)

далее, над bi.kafka_replica построена таблица kafka_all c
ENGINE = Distributed(bi_replicated, bi

и я хочу чтоб данные вычитанные из кафки на каждом сервере при записи в kafka_replica писались в заданный шард и соответственно внутри него реплицировались

вам надо из N в M , читать надо через одну distributed писать в другую distributed -- через одну точку, иначе как? надо же решардить каждую строку.
но так как партиций много и если воркеров много, будут задействованы все ноды

>писались в заданный шард
заданный как? шардирование по полю какому-то?

CREATE MATERIALIZED VIEW bi.kafka_materialized TO kafka_all AS

но вообще это все хреново

уже разобрался, включил internal replication и админы докрутили права, чтоб работала репликация