Шаблон материализованного представления

Хранилище Azure

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

Контекст и проблема

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

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

Решение

Для эффективного выполнения запросов обычно заранее создается представление, которое материализует данные в формате, подходящем для необходимого набора результатов. Шаблон материализованного представления описывает создание заполненных представлений данных в тех случаях, когда формат исходных данных не подходит для запросов, когда сложно создать подходящий запрос или в случае низкой производительности запроса из-за типа данных или хранилища данных.

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

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

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

На рисунке 1 показан пример использования шаблона материализованного представления.

Проблемы и рекомендации

При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.

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

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

Следует учитывать влияние на согласованность данных при создании и обновлении представления, если обновление происходит по расписанию. Если в момент создания представления происходит изменение исходных данных, копия данных в представлении не будет полностью соответствовать исходным данным.

Необходимо учитывать место для хранения представления. Представление не обязательно должно находиться в том же хранилище или разделе, что и исходные данные. Оно может представлять собой подмножество, объединенное из нескольких различных разделов.

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

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

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

Когда следует использовать этот шаблон

Этот шаблон полезен в следующих сценариях.

  • Создание материализованных представлений данных, для которых сложно создать прямой запрос. Также можно использовать этот шаблон, когда запросы должны быть очень сложными, чтобы извлечь данные, хранящиеся в нормализованном, частично структурированном или неструктурированном виде.
  • Создание временных представлений, способных значительно повысить производительность запроса либо способных выступать непосредственно в качестве исходных представлений или объектов передачи данных для пользовательского интерфейса, создания отчетов или отображения.
  • Поддержка сценариев временного подключения или временного отключения, когда подключение к хранилищу данных не всегда доступно. В этом случае представление можно кэшировать локально.
  • Упрощение запросов и предоставление данных для экспериментов таким образом, чтобы информация о формате исходных данных не требовалась. Например, это делается путем объединения разных таблиц в одну или несколько баз данных либо одного или нескольких доменов в хранилищах NoSQL и последующего форматирования данных в соответствии со способом использования.
  • Предоставление доступа к определенным подмножествам исходных данных, которые из соображений безопасности или конфиденциальности не должны быть общедоступными, доступными для изменений или полностью открытыми для пользователей.
  • Использования моста для различных хранилищ данных для воспользоваться конкретными возможностями каждого из них. Например, использование облачного хранилища, эффективного для записи в качестве ссылочного хранилища данных, и реляционной базы данных, предлагающей хорошую производительность запросов и операций чтения для хранения материализованных представлений.
  • При использовании микрослужб рекомендуется свободно сочетать их, включая хранилище данных. Поэтому материализованные представления помогают консолидировать данные из служб. Если материализованные представления не подходят для архитектуры микрослужб или конкретного сценария, рассмотрите возможность наличия четко определенных границ, которые соответствуют дизайну на основе домена (DDD) и агрегируют свои данные при запросе.

Этот шаблон не будет полезен в следующих сценариях.

  • Используются простые исходные данные, для которых легко создавать запросы.
  • Исходные данные меняются очень быстро или доступ к ним можно осуществлять без использования представления. В таких случаях следует избегать дополнительной нагрузки в виде создания представлений.
  • Согласованность имеет высокий приоритет. Представления могут быть не всегда полностью согласованными с исходными данными.

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон материализованного представления можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

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

- Производительность данных PE:08

Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.

Пример

На рисунке ниже показан пример использования шаблона материализованного представления для создания сводки о продажах. Данные в таблицах Order (Заказ), OrderItem (Товар заказа) и Customer (Клиент) в разных разделах учетной записи хранения Azure объединены в представление, которое содержит значение общих продаж для каждого товара в категории "Электроника", а также количество клиентов, купивших каждый товар.

Рисунок 2. Использование шаблона материализованного представления для создания сводки о продажах

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

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

Следующие шаги

  • Data Consistency Primer (Руководство по обеспечению согласованности данных). Необходимо поддерживать актуальность сводных данных в материализованном представлении, чтобы оно точно отражало значения базовых данных. По мере изменения значений данных обновление сводных данных в режиме реального времени может оказаться нецелесообразным. Вместо этого необходимо будет использовать другой подход, обеспечивающий согласованность. Здесь кратко описаны проблемы, связанные с поддержанием согласованности распределенных данных, и описываются преимущества и недостатки различных моделей согласованности.

При реализации этого шаблона могут быть также важны следующие шаблоны:

  • Шаблон выделения ответственности команды и запроса (CQRS). Используйте для обновления сведений в материализованном представлении в ответ на события, возникающие при изменении значений данных.
  • Шаблон источников событий. Используйте этот шаблон вместе с шаблоном выделения ответственности команды и запроса для поддержания актуальности информации в материализованном представлении. При изменении значений данных, на которых основывается материализованное представление, система может выдать события, описывающие эти изменения, и сохранить их в хранилище событий.
  • Шаблон таблицы индексов. Данные в материализованном представлении обычно организованы по первичному ключу, но для выполнения запросов может понадобиться получение сведений из этого представления путем проверки данных в других полях. Используйте этот шаблон для создания вторичных индексов на основе наборов данных для хранилищ данных, которые не поддерживают собственные вторичные индексы.