из них с опцией 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 раза больше строк данных, но запрос отработал быстрее чем во втором случае.
Соответсвенно вопрос.
Почему так? Ведь по логике, при уменьшении гранулярности увеличивается размер индекса в памяти и клику нужно меньше данных считывать с диска для обработки запроса. По факту, хоть и меньше данных считали, но сам запрос работает дольше.
например надо больше раз читать, вы читаете в ~2 раза меньше строк, но делаете это в 8192 / 512 = 16 раз менее эффективно. Имеет смысл ставить маленькую гранулярность только если вам надо вычитавыть единичные строки.
Спасибо! Какие опции клика можно еще глянуть, для ускорения выборки? Сейчас в обоих вариантах пиковый расход памяти около 1GB, можно ли выделить больше памяти для ускорения запроса?
неплохо было бы показать как создана таблица и что за запрос, возможно вам поможет optimize_aggregation_in_order = 1 если ещё не включен
Спасибо! 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'; дальше запрос и получаете трассу
optimize final делался. Спасибо, буду трейс изучать
Обсуждают сегодня