помогите с distributed таблицами плиз
есть 2 шарда по которым пополам поделены даннные
есть distributed таблица на них
и на одном из шардов другая таблица, с полным набором данных

я ожидаю что distributed таблица должна работать быстрее чем таблица с полными данными, но по факту даже немного медленнее
запросы к табличкам с половинными данными работают ожидаемо ~ 2 раза быстрее

запросы тестовые вида:
select FHospital, count(), count(distinct FPatKey)
from default.PHARMACY_ConsumptionReports_test2
group by FHospital;

select FHospital, count(),count(distinct FPatKey)
from default.Distr
group by FHospital

FHospital здесь - используется в ключе шардинга, но есть подозрение что кх не понимает что можно на каждом шарде посчитать и тянет к инициатору всё
на реальныхсложных запросах тоже +- одно время или до 15% деградации на distributed таблице.

План distributed:
Expression
Expression
 MergingAggregated
  Union
   ParallelAggregating
    Expression × 6
     MergeTreeThread
   Remote

план обычный:
Expression
Expression
 ParallelAggregating
  Expression × 6
   MergeTreeThread

>я ожидаю что distributed таблица должна работать быстрее чем таблица
>с полными данными, но по факту даже немного медленнее
>запросы к табличкам с половинными данными работают ожидаемо ~ 2 раза быстрее
это ожидаемо для некоторых запросов. Финальная агрегация+передача по сети могут занимать больше времени -- чем агрегация на локальной таблице.

шардинг помогает когда надо много читать с диска, т.е. ускоряется диск

финальную агрегацию можно выключить -- если данные шардированы как группируются

>подозрение что кх не понимает что можно на каждом шарде посчитать
кх не знает как шардированы данные, поэтому есть финальная агрегация -- иногда лишняя.

старался сделать максимально подходящий запрос,  в результате по 20 записей на шард получается, сеть локальная <1мс

спасибо

настройка есть для этого?

>count(distinct FPatKey)

передаются естественно все distinct FPatKey -- как иначе?

т.е. каждый шард составляет свой длинный(distinct FPatKey)
инициатор снова делает (distinct FPatKey) из двух списков с шардов
потом считает count

--distributed_group_by_no_merge

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

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

distributed_group_by_no_merge
жаль не помогло

>жаль не помогло

есть разница в статистике между

select FHospital, count(),count(distinct FPatKey)
from default.Distr
group by FHospital

select FHospital, count(),count(distinct FPatKey)
from default.Distr
group by FHospital settings distributed_group_by_no_merge=1

хм, похоже я рукожоп или в dbeaver тупил
в вашем варианте всё как нужно(прирост в 2 раза, результаты правильные), буду ковырять дальше, еще раз спасибо!

чтобы в dbeaver работало set distributed_group_by_no_merge = 1 надо настроить session_id

session_id стоит

Тот самый случай когда самому интересно стало. Я так и не смог в бобра

Оно тупое

а может и не работает это в dbeaver, я sqlworkbench/j использую

Завели issue:
https://github.com/ClickHouse/ClickHouse/issues/8212