Главная » Microsoft SQL Server, Базы данных » Работа с индексированными представлениями

0

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

Компания Microsoft предложила альтернативу денормализации фактических данных. Индексированные представления SQL Server на самом деле являются кластеризованными индексами, хранящими денормализованное множество данных (рис. 53.7).

Рис. 53.7. Индексированные представления перекидывают мост между двумя таблицами, которые на самом деле должны содержать десяток объединений

Вместо создания таблиц для денормализации объединений может быть создано представление, отбирающее два первичных ключа из объединяемых таблиц. Кластеризованный индекс, созданный на представлении, хранит допустимые данные из пар первичного и внешнего ключей.

В то время как обычное представление хранит инструкцию SQL SELECT и данные не материализуются до тех пор, пока представление не будет вызвано, индексированное представление хранит копию данных в кластеризованном индексе. Кластеризованные индексы объединяют страницы данных и листья индекса двоичного дерева для хранения фактических данных в физическом порядке индекса. Кластеризованный индекс использует представление как среду определения хранимых столбцов.

В индексированных представлениях существует множество ограничений, в частности, описанные ниже.

?               При создании представлений и когда какие-либо подключения пытаются модифицировать данные в базовых таблицах, должны быть включены пустые значения ANSI и заключенные в кавычки идентификаторы.

?               Индекс должен быть уникальным и кластеризованным. Таким образом, представление должно создать уникальный набор строк без использования ключевого слова DISTINCT. Это может стать проблемой, поскольку среди ситуаций, в которых необходима денормализация, многие содержат отношения “многие ко многим”, имеющие тенденцию генерировать дублирующиеся строки в результирующем наборе данных. По этой причине большинство индексированных представлений покрывают только отношения “один ко многим”.

?               Таблицы в представлении должны быть именно таблицами (а не вложенными представлениями) локальной базы данных, и ссылки на них должны выполняться с помощью двухкомпонентного имени (владелец. таблица).

?               Представление должно создаваться с параметром WITH SCHEMA BINDING.

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

Приведем пример индексированного представления, используемого для денормализации больших запросов. Следующее представление отбирает данные из таблиц Contact и Product базы данных OBXKites:

USE OBXKites;

SET ANSI_Nulls ON;

SET ANSI_Padding ON;

SET ANSI_Warnings ON;

SET ArithAbort ON;

SET Concat_Null_Yields_Null ON;

SET Quoted_Identifier ON;

SET Numeric_RoundAbort OFF;

GO

CREATE VIEW vContactOrder WITH SCHEMABINDING AS

SELECT c.ContactID, o.OrderlD FROM dbo.Contact as с JOIN dbo.[Order] as о

ON c.ContactID = o.ContactID;

GO

CREATE UNIQUE CLUSTERED INDEX ivContactOrder ON vContactOrder (ContactID, OrderlD);

Индексированные представления и запросы

Когда оптимизатор запросов SQL Server создает план выполнения запроса, он включает кластеризованный индекс индексированного представления в качестве одного из индексов, используемого запросом, даже если запрос явно не ссылается на это представление.

Это означает, что кластеризованный индекс индексированного представления может выступать в роли покрывающего индекса, ускоряющего запросы. Когда оптимизатор запросов отбирает кластеризованный индекс индексированного представления, план выполнения запроса отбирает его для сканирования (рис. 53.8). Следующий запрос отбирает те же данные, что и индексированное представление:

SELECT Contact.ContactID, OrderlD FROM dbo.Contact JOIN dbo.[Order]

ON Contact.ContactID = [Order].ContactID

Puc. 53.8. План выполнения запроса осуществляет сканирование кластеризованного индекса для непосредственного извлечения данных вместо доступа к таблицам базы

В то время как индексированные представления в сущности остались такими же, как в SQL Server 2000, оптимизатор запросов теперь может использовать индексированные представления в большем числе типов запросов.

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

Обновление индексированных представлений

Как и в любой денормализованной копии данных, основная сложность заключается в поддержании данных в постоянно обновленном состоянии. То же относится и к индексированным представлениям. Когда данные базовых таблиц обновляются, индексированное представление должно находиться с ними в синхронизации. Этот процесс полностью прозрачен для пользователя и больше относится к области производительности, чем программирования.

Резюме

Не каждая база данных должна масштабироваться до огромных размеров, однако для проектов, объем которых стремится к терабайтам, SQL Server 2005 предлагает ряд эффективных технологий, позволяющих справиться с подобным ростом. Тем не менее даже эти расширенные технологии не могут заменить теорию оптимизации.

Разработка высокопроизводительных поставщиков доступа к данным

Сегодня почти вся информация хранится в базах данных и в основном накапливается ежедневно. Эти массивы информации не имеют практически никакого значения, если их невозможно просмотреть с определенной точки зрения. Именно в этом аспекте информация приобретает реальную ценность. Если вы предоставляете пользователю некоторый образ данных, то можете придать ему смысловое значение и даже предсказать будущие модели, направления и тенденции. Когда информация представляется в некотором смысловом аспекте, пользователи и приложения имеют возможность принимать решения, влияющие на реальные события.

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

В этой главе мы рассмотрим некоторые концепции доступа к данным. В частности, рассмотрим модели, использующие объекты доступа к данным VB.NET (DAO), фабрики и поставщиков. В среде разработки Microsoft модель DAO представляет собой множество классов, реализующих промежуточный слой между базой данных и клиентским приложением. Эта технология не полагается целиком на методы самой базы данных.

Когда возможно, старайтесь использовать программные шаблоны. Под шаблоном подразумевается технология, обычно применяемая для решения определенной задачи. Такое решение обычно включает в себя классы и программный код, необходимый для их взаимодействия.

В примерах программного кода этой главы обработка исключений проиллюстрирована с использованием общего класса Exception, содержащегося в блоке Catch. На практике эти исключения будут привязаны к типам ошибок, которые вы хотите обработать.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии