удалось получить прирост производительности по сравнению с вариантом без параллелизма.
При этом ключ сэмплирования - случайное UInt16 и сэмплированные запросы идут быстрее обратно пропорционально доле сэмпла (для сэмпла 0.1 запрос в 10 раз быстрее, чем по всем данным).
Есть ли рекомендованная конфигурация, чтобы и репликацию включить, и запрос полноценно параллелился между репликами?
P.S. Если я верно понял, при выполнении запросов вида SELECT sum(metric), dimensions... FROM fact group by dimensions... по Distributed таблице, он сначала агрегируется на шардах, входящих в таблицу, а затем результаты агрегируются на ноде, на которой находится Distributed таблица.
Создалось впечатление, что распараллеливание по репликам работает иначе (все данные для агрегации поднимаются параллельно с реплик и пересылаются по сети на одну ноду). Есть ли возможность сделать, чтобы работало так же, как и при шардировании?
При распараллеливании по репликам, реплики работают как отдельные шарды, с которых читается соответствующая часть сэмпла данных. То есть, ускорение должно быть таким же как при сэмплировании (за исключением деталей - передача большего количества данных по сети, суммирование случайных задержек при использовании большого количества серверов). Было бы интересно узнать, почему в вашем случае это не так. Надо больше подробностей. Вопрос - а сколько сейчас шардов и реплик?
Возможно с каждой реплики/шарда получается очень большой промежуточный результат. Если все данные по вашему group by доступны на одной ноде, то попробуйте переписать запрос с distributed_group_by_no_merge
Обсуждают сегодня