Материализованные представления (materialized views) и NoSQL

Андрей Волков

Андрей Волков

Системное, сетевое администрирование +DBA. И немного программист!))  Профиль автора.

Материализованные представления в NoSQLКогда в блогах говорили об агрегатно-ориентированных моделях, там подчеркивались их преимущества. Если вы хотите получить доступ к заказам, полезно собрать все данные для заказа в одном агрегате, который может храниться и предоставлять доступ как от­дельная единица. Однако агрегатная ориентация имеет и недостаток: что произойдет, если товаровед захочет узнать, как часто конкретный товар заказывался на протяжении последних недель? В этом случае агрегатная ориентация мешает, вынуждая вас про­читывать каждый заказ в базе данных, чтобы получить ответ на вопрос. Вы можете об­легчить задачу, построив индекс товаров, но все равно агрегатная структура останется неудобной.

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

Представления обеспечивают механизм сокрытия от клиента источника данных. Клиент не знает, были ли данные вычислены или просто взяты из базы данных. Однако вычисление некоторых представлений является затратным. Для решения этой пробле­мы были изобретены материализованные представления (materialized views), т.е. пред­ставления, вычисленные заранее и записанные в кеш-память диска. Материализован­ные представления эффективны при работе с часто считываемыми данными, но могут оказаться устаревшими

Несмотря на то что в базах данных NoSQL нет представлений, они могут иметь заранее вычисленные и кешированные запросы, к которым также применяется термин “материализованное представление”. Этот аспект имеет гораздо большее значение для агрегатно-ориентированных баз данных, чем для реляционных баз, поскольку боль­шинство приложений работают с запросами, которые плохо согласуются с агрегатной структурой. (Часто базы данных NoSQL создают материализованные представления с помощью подхода “отображение-свертка” (map-reduce).

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

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

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

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

 

Вас заинтересует / Intresting for you:

Отношения в базе данных и  тех...
Отношения в базе данных и тех... 1030 просмотров Андрей Волков Wed, 14 Nov 2018, 09:14:11
Обзор Couchbase: умная и эффек...
Обзор Couchbase: умная и эффек... 2713 просмотров Андрей Волков Tue, 01 Oct 2019, 15:34:03
Неструктурированные базы данны...
Неструктурированные базы данны... 2002 просмотров Андрей Волков Wed, 14 Nov 2018, 10:57:25
Графовые базы данных: хранение...
Графовые базы данных: хранение... 2212 просмотров Андрей Волков Wed, 14 Nov 2018, 10:04:37
Войдите чтобы комментировать