Архитектуры ООСУБД. Анализ реализаций


Модель параллельности


Как описывается ниже, у этих трех базовых архитектур имеются разные модели управления параллельным доступом. Модели управления параллельным доступом решают проблему изоляции транзакций и тесно связаны с поведенческими характеристиками сети. В любой архитектуре имеются способы ослабления блокировок для некоторых типов приложений, для которых не требуется полный набор свойств ACID (Atomicy – атомарность, Consistency – согласованность, Isolation – изоляция, Durability – долговечность). Дальнейшая часть этого раздела фокусируется на поведении, требуемом для поддержания корректными транзакциями строгих ACID-свойств согласованности и изоляции. Во всех реализациях блокировки могут локально кэшироваться на клиенте за пределами границ транзакций во избежание избыточных запросов блокировки. Однако обновления всегда приводят к выполнению операций координации блокировок и согласования кэшей. При использовании архитектур, основанных на контейнерах и страницах, размещение объектов и блокировки тесно связаны, а архитектура, основанная на объектах, позволяет ортогонализировать эти аспекты. Взглянем более пристально на эти аспекты каждой из архитектур.


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

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

Грин также не упоминает о том, что в системах с архитектурой, основанной на страницах, при наличии реальной потребности в блокировке на уровне объекта можно просто поместить объект на отдельную страницу. Если требуется одновременный и независимый доступ к объектам O1 и O2 от разных программ, при использовании ObjectStore программист может позаботиться об их размещении в разных страницах, чтобы они блокировались независимо.

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

Содержание раздела