разные очереди?
два года назад был такой комментарий, но там без деталей...
https://github.com/ClickHouse/ClickHouse/issues/15181#issuecomment-898988764
здесь пока грустный TODO
https://github.com/ClickHouse/ClickHouse/blob/06b05cf2aab79c2ca8acf0f9deb717763429368a/src/Databases/DatabaseReplicatedWorker.cpp#LL26C3-L26C3
А то у нас бывает что один супертяжелый ДДЛ (modify column), блокирует кучу DROP PARTITION+ когда очередь заполняется то дальнейшие DDL просто висят...
мы решали тем что убрали использование ON CLUSTER) просто на каждом шарде выполняем отдельно в потоках
Ну да, мы тоже теперь так, но это костыль... хотелось бы понять может есть какой-либо прогресс на стороне КХ
Кажется при серьезных нагрузках это маст хэв иметь умного клиента, который умеет сам много чего делать, например балансировку или кастомное шардирование, или параллельное выполнение запросов на шардах. У нас весь процессинг почти не использует дистрибьютед таблицы
это мы уже 4 года назад поняли, например правило №1 - не грузить в дистрибьютед )
https://t.me/clickhouse_ru/266470
А как у вас это реализовано ?
На ETL уровне. Платформа спрашивает инфу о кластере и раскидывает. Но для большого кол-ва мелких таблиц дистрибьютед остался, иначе возрастают operational costs.
Обсуждают сегодня