Оценка кардинальности «Cardinality estimation» (CE) — это процесс, используемый оптимизатором запросов для оценки количества строк, возвращаемых запросом или частью запроса. Эти оценки основаны на двух базовых вещах: статистике данных и наборе допущений (assumptions), известных как модель. Модель определяет, как мы интерпретируем статистику и данные, поступающие из разных частей выражения, поэтому для любого заданного набора статистических данных разные модели приведут к разным оценкам кардинальности.
До SQL Server 2022 у CE могла быть только одна модель. Набор используемых допущений был встроен в код сервера, поэтому какая бы модель ни была выбрана, она использовалась для всех таких запросов. Однако, мы знаем что не все запросы и рабочие нагрузки работают одинаково хорошо в рамках одной единственной модели. Для некоторых запросов модель будет работать хорошо, а для других лучше подходит другая модель. В SQL Server 2022 появилась возможность адаптировать модель с помощью CE Feedback (оценка кардинальности с обратной связью), приспосабливая план запроса к конкретному запросу.
CE всегда исходила из трех основных допущений, составляющих модель: независимость (или частичная независимость), однородность и контейнирование. Эти три предположения определяют как мы интерпретируем гистограммы, как мы объединяем данные, реализуя соединения, и как поступаем при наличии нескольких предикатов. В этой статье будут рассмотрены подробно возможные варианты моделей и их влияние на запросы.
Однородность
Начнем с рассмотрения предположения об единообразии данных или иначе, об однородности. Это предположение используется при интерпретации данных гистограмм на диске — абстрагированных данных о запрашиваемых столбцах. Мы предполагаем, что все данные в шагах или сегментах гистограммы распределены равномерно со средней частотой для этого сегмента. Таким образом, когда мы запрашиваем данные, это позволяет нам определить количество строк, удовлетворяющих предикату.
Теперь CE Feedback изменяет предположение об однородности только в одном особом случае — в запросах Row Goal. Эти запросы выглядят как TOP n, Fast n или IN, и оптимизируются особым образом, основываясь на предположении о независимости. Всякий раз когда мы считаем, что конкретное значение встречается с достаточно высокой частотой (на основе нашей интерпретации гистограммы с использованием предположения о независимости), мы выбираем быстрое сканирование нескольких страниц, предполагая, что мы очень быстро получим достаточно подходящих строк. Однако, если данные не такие однородные, может быть напрасно извлечено больше подходящих значений чем на самом деле нужно. Это означает что для выборки необходимого количества строк мы сканируем гораздо больше страниц чем можно было бы ожидать.
CE Feedback теперь может находить такие сценарии и отключать эту особую оптимизацию для порции строк. Если окажется, что запрос действительно быстрее без этой оптимизации, это изменение сохраняется, и будет помещено в хранилище запросов (QS) в виде подсказки в запросe, и эта новая оптимизация будет использоваться для последующих исполнений запроса.
Независимсть
Рассмотрим предложение where с двумя предикатами в сочетании с AND. Что-то вроде City=’Seattle’ AND State=’WA’. В независимой модели, где это допускается, мы бы взяли селективность отдельных предикатов (City=’Seattle’, State=’WA’) и перемножили бы их ожидаемые значения друг на друга по известной формуле. В модели с корреляцией мы бы взяли наиболее избирательный предикат (City='Seattle') и для определения общей избирательности предложения where использовали избирательность только этого предиката. Существует третья модель с частичной корреляцией, в которой мы умножаем избирательность самого избирательного предиката на менее избирательную (возведя это в степень меньше 1, чтобы сделать избирательность ближе к 1)[НИ1] следующих в таком порядке друг за другом предикатов.
CE всегда начинает с модели частичной независимости (упоминаемой в других местах как экспоненциальная отсрочка - exponential backoff). Но в CE Feedback мы можем увидеть, вляются ли наши оценки завышенными, что означает большую степень независимости предикатов; или слишком заниженными, что означает большую корреляцию, чем ожидалось. Это даёт возможность соответствующим образом скорректировать выбор модели, используемой для запроса, и кардинальности предикатов для будущих его исполнений. Если эти манипуляции позволят получить лучший план запроса или его более высокую производительность, мы сохраняем эту корректировку с помощью подсказки для QS (хранилища запросов) и в таком виде всё это будет использоваться в последующих выполнениях запроса.
Контейнирование
Выбор модели с контейнированием означает, что были запрошены данные, которые действительно находятся в таблице. Тогда, если для таблицы есть предикат «столбец = константа», мы предполагаем, что значение с этой константой действительно есть в таблице и встречается там с той частотой, которая соответствует гистограмме. Однако мы также предполагаем, что существует «контейнерная» связь для этого соединения. По сути, мы предполагаем, что две таблицы не соединяли бы вместе, если бы не было совпадений. Однако есть два подхода к контейнерным связям у соединений: базовое или простое контейнирование.
Базовое контейнирование предполагает что между таблицами соединения существует связь, но не делает предположений о влиянии фильтров, применяемых для этих таблиц до соединения. Хорошим примером может быть таблицы продаж и возврата в магазине. Можно предположить, что все возвращенные вещи ранее были проданы, но мы не предполагаем, что любые фильтры для таблиц продаж или возврата делают контейнирование более или менее вероятным. Тут мы можем только предполагать контейнирование для базовой таблицы и фильтрами можем увеличивать или уменьшать размер предполагаемой выборки.
\Простое контейнирование устроено немного иначе. Вместо того, чтобы предполагать существование естественной связи между базовыми таблицами, предполагается, что фильтрами создаётся контейнерная связь. Например, выборка по выпускникам некой школы и объединение её с выборкой спортсменов с неким почтовым индексом. Несмотря на то, что между двумя этими таблицами априори существует некоторая естественная связь, применение фильтров может внести такие ограничения, что получится контейнерная связь.
CE для всех запросов вначале пробует базовую модель контейнирования. Однако, если оценки для соединения каким-либо образом «отклоняются» (на входе оценки хорошие, а на выходе плохие) будет опробована альтернативную модель контейнирования. В таком случае, когда запрос будет выполняется снова, будет использована простая модель, и, если она окажется лучше, её использование будет предписано запросу в виде сохранённой подсказки в хранилище запросов QS и следующие запросы получат более удачную модель контейнирования.
Заключение
Таким образом, CE оперирует базовым набором предположений, которые используются для интерпретации и объединения статистических данных, гистограммах запроса или его частях. Эти предположения хорошо работают для одних запросов и хуже для других. В SQL Server 2022 мы представили метод обратной связи CE, который корректирует эти предположения для каждого запроса на основе фактической его производительности и её изменений с течением времени.
Комментариев нет:
Отправить комментарий