И ещё раз спрошу про деление работы на репликах. Все

что предлагали с опциями не сработало, время наоборот увеличилось вдвое. Можно ли в итоге как то подключить реплики не как раунд Робин, куда уходит запрос полностью и вычисляется на одной, а делить работу между ними, если существует партицирование. И если это возможно, то где можно почитать в коде то, как реплики будут выбирать себе куски для обработки?

мечты, мечты. у вас таблицы replicated? результат вообще правильный получился? сколько партов процессилось?

Не сверял правильность, таблицы реплекейтед, да, одна реплика, просканило в два раза больше строк с опцией allow_allow_experimental_parallel_reading_from_replicas

ну т.е. вообще непонятно КХ понял что это реплики или нет. ОК версия-то какая у КХ ?

22.2

сейчас попробовал на 1м шарде с двумя репликами. короче в такой конфигурации всегда читает с локальной реплики, потому что все данные есть локально. работает если prefer_localhost_replica=0; set allow_experimental_parallel_reading_from_replicas=1, max_parallel_replicas=2, prefer_localhost_replica=0;

А у вас как таблица партицирована? По 500к с каждой реплики прочитало?

в общем все там кривое и результаты кажется кривые

Жалко, ну видимо не зря экспериментал

в общем разработчики были в курсе, просто не доделано

одна реплика select count() from rep_test1 prewhere S='a'; 0 rows in set. Elapsed: 19.412 sec. Processed 68.16 million rows, 70.17 GB (3.51 million rows/s., 3.61 GB/s.) 8 реплик set allow_experimental_parallel_reading_from_replicas=1, max_parallel_replicas=8, prefer_localhost_replica=0, use_hedged_requests=0; select count() from rep_test1 prewhere S='a'; 0 rows in set. Elapsed: 3.988 sec. Processed 68.16 million rows, 70.17 GB (17.09 million rows/s., 17.60 GB/s.)

ну в 6 раз меньше время. но тут prewhere. интересно какой там алгоритм разбиения работы по рекликам и откуда оно знает что результат независим от кусков

https://github.com/ClickHouse/ClickHouse/issues/26748

похоже что реплика проверяет выполняет кто-то работу с этим куском или нет, т.е. скорее всего одна реплика может всю работу забрать себе и 7 будут делать ничего. вот без prewhere select uniqHLL12(S) from rep_test1_d; 1 rows in set. Elapsed: 24.430 sec. Processed 68.16 million rows, 70.17 GB (2.79 million rows/s., 2.87 GB/s.) set allow_experimental_parallel_reading_from_replicas=1, max_parallel_replicas=8, prefer_localhost_replica=0, use_hedged_requests=0; select uniqHLL12(S) from rep_test1_d; 1 rows in set. Elapsed: 4.720 sec. Processed 68.16 million rows, 70.17 GB (14.44 million rows/s., 14.86 GB/s.) это искусственно созданная идеальная таблица для allow_experimental_parallel_reading_from_replicas, в реальной жизни конечно это работать будет раз в году, при солнечной погоде.

хотя казалось бы group by по партицированной таблице идеально ложится в кейс. Даже не надо заморачиваться с тем что считать кол-во работы, просто тупо считать что в партициях равное кол-во работы и уже норм будет на большинстве кейсов

в реальной жизни финализация результата с шардов на инициаторе занимает примерно половину времени.

странно, если на входе сотни миллионов строк , а на выходе десятки тысяч

у вас другая реальность, у меня по жизни инициатор самое проблемное место.

видимо такое распределение данных, что дистрибьютед таблица дает ускорение в n раз, где n -кол-во шардов. Но я не замерял конечно сильно детально , на глаз)

в общем оно работает только если prefer_localhost_replica=0, use_hedged_requests=0;