Классика баз данных - статьи

       

Оптимизация производственного уровня


«Черт прячется в деталях.»
Х. Росс Перо

Оптимизаторы в продуктах должны иметь дело со многими аспектами оптимизации запросов, редко рассматриваемыми в исследовательских прототипах.

Прежде всего, они должны, конечно, оптимизировать весь язык SQL. Это включает поддержку предикатов со сложными комбинациями AND, OR и NOT; предикаты IN и LIKE; предикаты IS NULL и NOT NULL; разделы UNION, INTERSECT и EXCEPT; вложенные подзапросы (и даже выражения, содержащие несколько вложенных подзапросов!); корреляцию (ссылки из подзапросов на значения, обеспечиваемые в другом блоке SELECT...FROM...WHERE... того же запроса) и много других конструкций, так или иначе влияющих на оптимизатор.

Во-вторых, оптимизатор в продукте должен обладать устойчивой производительностью, грамотно обрабатывать ошибки и уметь работать с ограниченными ресурсами, надежно оптимизируя запросы за приемлемое время. Приложения могут включать сотни и даже тысячи запросов, варьирующихся от запросов к одной таблице до запросов над представлениями, определенными над представлениями [TO91]. Без тщательного управления, экономного представления данных, повторного использования фрагментов возможных планов оптимизация запросов с достаточным числом таблиц, столбцов и предикатов быстро исчерпает ресурсы памяти и времени. Наиболее трудно достигнуть того, чтобы результат, видимый пользователем, не зависел от того, какой план выбрал оптимизатор, или от того, что в частях какого-то плана возникла необычная ситуация (например, не найдена ни одна строка, встретились неопределенные значения, возникла исключительная ситуация времени выполнения и т.д.).

В третьих, оптимизаторы в продуктах должны иметь дело с такими «будничными» деталями, как поддержка наборов символов национальных языков (у которых часто имеются разные порядки сортировки), обеспечением корректных ответов на разных уровнях изоляции (в особенности, на уровне стабильности курсора), корректной обработкой неопределенных значений (где должен находиться NULL в порядке сортировки? учитываются ли неопределенные значения в агрегатных функциях? применяется ли трехзначная логика? и т.д.), а также с аспектами реализации используемого менеджера данных, которые должны специфицироваться в плане и точно моделироваться в оценочной модели.
Соответствующие примеры приводятся по ходу статьи, и в разд. 7.2 последний из затронутых вопросов обсуждается более подробно.

В четвертых, оптимизаторы в продуктах должны моделировать и производить выбор на основе широкого репертуара стратегий выполнения, каждая из которых может быть оптимальной для некоторого запроса. В этой статье мы сосредотачиваемся на этих стратегиях, выделяя некоторые необычные или не слишком известные особенности семейства реляционных СУБД IBM DB2.

Последнее и, возможно, наиболее важное требование к оптимизаторам в продуктах состоит в том, что они должны быть чувствительными к изменениям требований клиентов, не воздействуя на существующие приложения. DB2 для MVS – это зрелый продукт с тысячами лицензий на многопользовательских системах, многие из которых поддерживают тысячи пользователей. Приложения, выполняющиеся на DB2 для MVS, часто являются «хлебом и маслом» обработки информации в компаниях Fortune 500. При каждом новом выпуске продукта заказчики ожидают только улучшений (без деградации эффективности какого бы то ни было плана). В DB2 для MVS имеется тенденция к реализации стратегий оптимизации, которые в большинстве случаев принимают подходящий путь доступа, а не рискуют применить менее понятные пути доступа, которые труднее точно моделировать. Грубо говоря, применяется правило «99-1», означающее, что свойство, которое, как ожидается, положительно скажется на 99% запросов, но может привести к деградации 1% запросов, не включается в продукт.

В высоко конкурентном мире рабочих станций DB2/* пользователи требуют большей функциональности, в частности, объектно-ориентированных возможностей, таких как определяемые пользователями типы и функции, бинарные большие объекты (BLOB), ограничения, триггеры и параллельное выполнение. Кроме возможностей «индустриального уровня», заказчики ожидают от DB2/* быстрого появления новых возможностей, согласующихся с промышленными стандартами, такими как недавно опубликованный стандарт ANSI SQL92 и развивающийся стандарт ANSI SQL3.Поэтому в DB2/* активно внедряются новые функциональные возможности, и прилагаются все усилия к сохранению лидирующей производительности.


Содержание раздела