Comments 7
Насколько критерий количества прочитанных страниц хорош для этой задачи?
Ну я бы сказал, что этот критерий, на первый взгляд, показывает, насколько эффективно мы читаем данные. Т.е. много ли лишних данных нужно прочитать, чтобы построить один и тот же результат запроса. Но я бы обратил внимание на то, что некоторые виды SQL движков могут построить более быстрый план, даже прочитав больше данных с дисков (и кстати, для SSD дисков объем читаемых данных вообще влияет на результат меньше), и загрузив больше ядер их параллельной обработкой. При условии что эти ядра у них конечно есть.
И я бы еще не забывал, что есть минимум два критерия производительности вообще - время выполнения запроса и пропускная способность, упрощенно говоря, и они частично противоречат друг другу. Потому что можно уменьшить время выполнения, затратив больше ресурсов.
Спасибо за фидбэк. Само-собой, что HashJoin бывает чуть быстрее NestLoop'a при большем количестве прочитанных страниц. Да и увеличивая количество воркеров мы снижаем время выполнения, оставляя количество страниц неизменным.
И это для меня как раз и плюс: NestLoop можно сделать оптимальнее (например, за счет материализации, кэширования результатов сканирования поддерева и пр), а параллелизм вообще штука относительная.
Зато мы можем повторить чужой эксперимент и как-то сравнивать методы - и в этом основной плюс, как мне кажется, данного критерия.
Не, я совершенно не хочу сказать, что ваш критерий плох. Я просто намекаю, что он иногда ограничен.
Да и увеличивая количество воркеров мы снижаем время выполнения, оставляя количество страниц неизменным.
Мы можем даже увеличить число страниц, если воркеры на разных машинах, при этом условно, хадуп, с его репликацией, позволяет нам эти страницы прочитать несколько раз с разных дисков, т.е. каждый воркер прочитает для себя по разу. Ну т.е. по вашему критерию, мы увеличили число страниц втрое - ровно три реплики у нас есть у блока, при этом общее время выполнения запроса сократилось. Если мы ровно этого и хотели - то для нас увеличение числа прочитанных блоков само по себе ничего не значит. Ну т.е. я клоню к тому, что нужно скорее всего считать как ресурсы все что мы потратили (число ядер * время, память * время, и т.п.), и делить на это дело показатель качества, т.е. скажем время выполнения запроса. Т.е. мы время сократили вдвое, а ресурсов выжрали вчетверо... Я понимаю что это модель будет сильно сложнее вероятно.
У Тома Кайта в книге по Ораклу была целая глава посвящённая тому, что такое перформанс. Помнится, что для разных сценариев были разные критерии. К примеру, в одном случае важно время выдачи первых строк, в другом выдача всего набора.
Видимо эта:
Expert Oracle Database Architecture. 9i and 10g Programming Techniques and Solutions
Почитал, спасибо. Действительно, о том и речь, что просто взять и привести ускорение на бенчмарке мало что дает. Нужны платформо-независимые характерстики, физичные и удобные в использовании.
Нужны платформо-независимые характерстики, физичные и удобные в использовании.
Попробуйте посмотреть здесь https://dzen.ru/kznalp
И здесь были статьи на тему расчета метрики производительности
Чья фича лучше или как сравнить эффективность планов SQL-запроса