Распределенное управление
На рис. 4 изображена архитектура, моделирующая систему баз данных как распределенную систему. На первый взгляд, эта архитектура кажется похожей на архитектуры с разделением и репликацией, показанные на рис. 2 и 3. Отличия едва уловимы, но они оказывают колоссальное влияние на реализацию, производительность и стоимость системы. Архитектуру с распределенным управлением можно также охарактеризовать, как архитектуру с общими дисками (shared-disk architecture) [24] с поддержкой слабых связей между узлами для достижения масштабируемости.
В этой архитектуре система хранения данных отделяется от серверов баз данных, и серверы баз данных параллельно и автономно обращаются к совместно используемым данным, содержащимся в системе хранения. Чтобы синхронизовать доступ по чтению и записи к общим данным, могут применяться распределенные протоколы, обеспечивающие разные уровни согласованности. Как и случаях, рассмотренных в предыдущих подразделах, здесь потенциально применимы самые разнообразные протоколы. Обзор таких протоколов и уровней согласованности приведен в классическом учебнике [27]. Для сокращения накладных расходов уровень управления базами данных сливается с уровнем серверов Web и приложений; другими словами, доступ к базе данных обеспечивается некоторой библиотекой в составе сервера приложений, а не отдельными процессами сервера баз данных.
Потенциально эта архитектура лучше всего подходит для cloud computing. Она обеспечивает полную масштабируемость и эластичность на всех уровнях. Каждый HTTP-запрос может направляться любому серверу (связке "Web-сервер/сервер приложений/сервер баз данных"), так что на этом уровне можно достичь полной масштабируемости. Кроме того, на уровне хранения данные могут любым образом реплицироваться и разделяться, так что масштабируемости можно достичь и на этом уровне. Еще одной особенностью этой архитектуры является то, что на всех уровнях можно использовать дешевую аппаратуру. Однако за эту масштабируемость приходится платить. В соответствии с теоремой CAP [4], невозможно одновременно обеспечить согласованность, доступность и устойчивость к разделению сети. В исследованном нами варианте этой архитектуры (Amazon S3, разд. 4) согласованность принесена в жертву, и обеспечивается только уровень согласованности, называемый согласованностью в конечном счете (eventual consistency) [29]. В терминах баз данных поддержка согласованности в конечном счете обеспечивает долговечность (durability) и, при небольших изменениях, атомарность (atomicy) распределенных транзакций баз данных, но не согласуется с требованием их изоляции (isolation) (т.е. требованием сериализуемости).
Рис. 5. Кэширование
