184 похожих чатов

Добрый вечер! Создаю две таблички ReplicatedReplacingMergeTree с одинаковой структурой, но одну

из них с опцией index_granularity=512
Делаю одинаковые запросы с группировкой по полям из ключа сортировки.
В результате имею следующую производительность.
1. Табличка с index_granularity по умолчанию
Elapsed: 0.303 sec. Processed 33.22 million rows, 1.56 GB (109.68 million rows/s., 5.16 GB/s.)

2. Табличка с index_granularity=512
Elapsed: 0.449 sec. Processed 15.93 million rows, 674.70 MB (35.50 million rows/s., 1.50 GB/s.)

Как можно заметить, в первом случае с диска прочитано почти в 2 раза больше строк данных, но запрос отработал быстрее чем во втором случае.
Соответсвенно вопрос.
Почему так? Ведь по логике, при уменьшении гранулярности увеличивается размер индекса в памяти и клику нужно меньше данных считывать с диска для обработки запроса. По факту, хоть и меньше данных считали, но сам запрос работает дольше.

8 ответов

27 просмотров

например надо больше раз читать, вы читаете в ~2 раза меньше строк, но делаете это в 8192 / 512 = 16 раз менее эффективно. Имеет смысл ставить маленькую гранулярность только если вам надо вычитавыть единичные строки.

Sergey-Ageev Автор вопроса
Konstantin Ilchenko
например надо больше раз читать, вы читаете в ~2 р...

Спасибо! Какие опции клика можно еще глянуть, для ускорения выборки? Сейчас в обоих вариантах пиковый расход памяти около 1GB, можно ли выделить больше памяти для ускорения запроса?

Sergey Ageev
Спасибо! Какие опции клика можно еще глянуть, для ...

неплохо было бы показать как создана таблица и что за запрос, возможно вам поможет optimize_aggregation_in_order = 1 если ещё не включен

Sergey-Ageev Автор вопроса
Konstantin Ilchenko
неплохо было бы показать как создана таблица и что...

Спасибо! optimize_aggregation_in_order = 1 не дает эффекта (

в слепую (ни запроса, ни трейсов) очень сложно... max_bytes_before_external_group_by=0,group_by_two_level_threshold=0,group_by_two_level_threshold_bytes=0,optimize_move_to_prewhere=0

optimize final делался? возможно тупо партов было больше случайно. возможно меньше было потоков, хотя на миллионах строк гранул бы должно хватить. потоки делят работу с помощью гранул SET send_logs_level = 'trace'; дальше запрос и получаете трассу

Sergey-Ageev Автор вопроса
Denny [Altinity]
optimize final делался? возможно тупо партов было ...

optimize final делался. Спасибо, буду трейс изучать

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта