Технология Клиент-Сервер 2002'1

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Материализованные представления
в SQL Server 2000 и Oracle9i

В online-форумах и компьютерной прессе часто повторяются слова-заклинания, например, «масштабируемость», «производительность» или «переносимость». При этом часто упускают из вида, что ни одно из них не имеет смысла само по себе, любая производительность может оказаться недостаточной, переносимость зачастую просто бесполезна, а у масштабируемости есть несколько серьезных «но». Чаще всего программное обеспечение действует на пределе производительности имеющейся аппаратной базы. Когда говорят, что проще нарастить аппаратные мощности, чем улучшить использование существующих, часто имеется в виду замена одного примитивного сервера другим. Однако не все так просто. Посмотрите на результаты тестов TPC (www.tpc.org) и на цены компьютеров-рекордсменов. Такие цены по карману монстрам из Fortune500, но не обычным российским предприятиям. Кроме того, даже самая совершенная железка даст прирост производительности в несколько раз, чего часто совершенно недостаточно.

Может, конечно, случиться так, что замена железа даст вполне достаточный эффект и продлит жизнь программного обеспечения, а заодно сэкономит время и деньги на модификацию или замену ПО. Но это чаще всего отсрочка, а не решение проблемы.

Решение же упирается в высокую сложность, а следовательно, и стоимость разработки/модификации ПО, и слабую предсказуемость результата. Из-за сложности процесса разработки очень трудно (причем практически до самого конца) предсказать, каким будет эффект и сколько времени потребуется. Модификация существующей системы осложняется еще и риском вывода системы из строя при изменениях ее компонентов. Эти трудности (для более четкого представления проблемы) нужно умножить на дефицит квалифицированных кадров.

Но программирование не стоят на месте, и сейчас существуют несколько технологий, позволяющих значительно и гарантированно повысить производительность системы. На предприятиях часто складывается ситуация, когда имеющегося ПО достаточно для ввода и модификации данных, то есть OLTP-составляющей системы, но большой объем уже имеющейся информации значительно затрудняет оперативность работы с ней (то есть, хромает OLAP-составляющая). Некоторые отчеты, конечно, выполняются редко, и при всей их трудоемкости могут выполняться в отложенном режиме. Но есть некоторый набор отчетов, нужных постоянно и чуть ли не в режиме реального времени. Некоторые же из них и вовсе должны выполняться мгновенно, так как их выполнение может затормозить работу всего предприятия – например, бухгалтерский баланс или остатки по складу.

В последних версиях SQL-серверов Oracle и Microsoft SQL Server появилась замечательная возможность создания так называемых материализованных представлений (МП). В SQL Server они называются "индексированными представлениями", но сути дела это не меняет. Поэтому в целях единообразия мы будем именовать их одинаково.

МП похожи на обычные представления (view), с той разницей, что результаты их выполнения кэшируются в специальных промежуточных таблицах. При запросе данных из МП эти данные получаются сканирования скрытых таблиц. При этом накладные расходы состоят в сканировании скрытых таблиц, и не включают дорогостоящих операций соединения (joins) и агрегации (group by). Естественно, МП повышают скорость далеко не всех операций. Более того, так как количество операций при модификации и внесения данных в БД растет, производительность этого процесса соответственно падает. Но это падение несущественно по сравнению с ростом скорости выполнения часто выполняемых запросов.

Рассмотрим более подробнее МП, особенности их реализации и применения в упомянутых серверах БД.

История

Прародителями МП являются так называемые снимки данных (snapshots), появившиеся еще в Oracle 7. Они были далеки от современных МП по возможностям, но, тем не менее, позволяли сохранить для многократного использования результат того или иного запроса.

МП впервые появились в Oracle8i и позиционируются разработчиком как часть компонента Summary Management. В отличие от своего прародителя, МП стали маскироваться под обыкновенные представления (виртуальные таблицы) и приобрели возможность динамического обновления своего наполнения вплоть до синхронного (обновления содержимого МП в процессе обновления данных базовых таблиц). Кроме этого, сервер научился использовать МП в запросах, позволяя получать выборки по МП в соединении с другими представлениями, таблицами и МП. Более того, оптимизатор Oracle8i научился использовать МП для ускорения запросов, напрямую не использующих МП.

С появлением МП связан один довольно громкий скандал. Как известно, организация TPC проводит ряд тестов, по большому счету делящихся на два больших раздела – OLTP и OLAP. OLTP соответствует тест TPC-C, где эмулируется работа стандартного приложения, занятого вводом данных, то есть простыми запросами, модифицирующими данные. А OLAP в то время соответствовал тест TPC-D.1 Этот тест подразумевал выполнение сложных агрегирующих запросов к большим объемам данных. До Oracle 8i никаких средств, аналогичных МП, не существовало, и тест подразумевал перелопачивание огромных объемов данных. В 1998 году при подготовке к тестированию сервера Oracle 8i специалисты Oracle применили МП, что, не нарушая формально условий теста TPC-D, полностью противоречило его сути. Тест TPC-D выполнялся Oracle менее, чем за секунду - что было невероятным улучшением стандартных результатов в 1000 секунд, достигнутых в апреле 1998 года. Разумеется, никаких вычислений реально не производилось, использовались готовые результаты из МП. Это позволило Ларри Эллисону предложить миллион долларов тому, кто докажет, что Microsoft SQL Server менее, чем в 100 раз медленнее, чем Oracle 8i. Через некоторое время ситуация прояснилась – Microsoft добился примерно того же результата, используя OLAP Services из состава SQL Server 7 Enterprise Edition, а совет TPC предложил заменить TPC-D двумя новыми системами тестов – TPC-R и TPC-H, первый из которых допускает тестирование системы, использующей материализованные представления. Интересно, что сравнимые результаты были продемонстрированы Microsoft на системе, стоящей в 16 раз дешевле. Однако для этого пришлось использовать дополнительное программное обеспечение.

Тем не менее, Oracle был пионером реализации МП. Главный конкурент Oracle, Microsoft, не мог не ответить на это, и в составе SQL Server 2000 появились так называемые индексированные представления (indexed view), причем в бета-версиях они назывались именно материализованными представлениями. Ввиду технологических отличий реализации, а также в целях маскировки, к выходу продукта МП переименовали.

Отличия

Основное отличие реализаций МП от Oracle и Microsoft состоит в том, что Oracle разрешает вообще не создавать индексов для МП, а Microsoft заставляет создать хотя бы один уникальный кластерный индекс для МП. При этом МП Oracle могут обновляться автоматически или вручную, а МП в SQL Server всегда обновляются автоматически.

В Oracle 9i имеются следующие методы обновления:

Эти операции могут выполняться:

Обновление ON DEMAND производится вызовом одной из вышеперечисленных процедур, давая администратору полный контроль над обновлением МП. При выборе метода ON COMMIT, каждое обновление исходных данных приведет к автоматическому обновлению МП. Нужно, однако, помнить, что обновление МП становится частью процесса фиксации транзакции. Поэтому второй метод несколько дольше, так как изменения производятся и в исходных таблицах, и в МП, чье определение ссылается на эти таблицы.

Microsoft SQL Server декларирует сохранение правильности содержимого МП, однако при сомнениях или в случае каких-либо проблем можно пересоздать МП, удалив уникальный кластерный индекс (при этом удалятся все дополнительные индексы, и, в сущности, представление перестанет быть материализованным) и создав кластерный, а также другие индексы, заново. В момент создания кластерного индекса как раз и происходит материализация представления. Нижняя часть кластерного индекса, содержащая ключи, в SQL Server размещается непосредственно в страницах данных, а значит, требует относительно небольших затрат на хранение и обработку. При наличии кластерного индекса все остальные индексы в качестве ключа используют значение кластерного индекса, а не идентификатор строки. Поэтому можно сказать, что материализация представления есть не что иное, как создание кластерного индекса. Более подробно об этом можно прочитать в статье "Архитектура современного SQL-сервера" во 2 номере нашего журнала за 1999 год, или на нашем сайте...
**полностью статью можно прочитать в печатной версии журнала

Copyright © 1994-2016 ООО "К-Пресс"