Materialized View Pattern

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

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

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

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

Решение

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

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

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

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

Проблемы и соображения

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

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

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

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

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

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

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

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

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

Этот шаблон полезен, если:

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

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

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

Пример

На следующем рисунке показан пример использования шаблона Materialized View для генерации сводки продаж. Данные в таблицах Order, OrderItem и Customer в отдельных разделах на учетной записи хранилища Azure объединяются для создания представления, содержащего общую стоимость продаж для каждого продукта в категории «Электроника», а также количество клиентов, совершивших покупки каждый пункт.

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

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

Связанные шаблоны и руководство

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

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

Original(english): https://docs.microsoft.com/en-us/azure/architecture/patterns/materialized-view

Translation: Basic, need improvment

Status: Draft

Action: Vote to improve