2.4Методы и технологии построения распределенных баз данных 2.4.1Основные принципы распределенных систем
Распределённые базы данных (РБД) – это совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.
Распределённые базы данных состоят из набора узлов, связанных коммуникационной сетью, в которой [39]:
каждый узел – это полноценная СУБД сама по себе;
узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, будто они находятся на его собственном узле.
Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределённых баз данных: для пользователя распределённая система должна выглядеть так же, как нераспределённая система.
Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать [39]:
1 Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2 Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3 Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
4 Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5 Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6 Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение – или в общем случае данный фрагмент данной хранимой переменной-отношения – может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7 Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8 Управление распределёнными транзакциями. Существует два главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент – процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
9 Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
10 Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
11 Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12 Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
На данный момент существуют следующие направления в построении распределенных баз данных [41].
1 Горизонтальная децентрализация. Структура базы совершенно одинаковая во всех хранилищах. Отличаются только данные. Организация же данных неизменна. В каждое хранилище можно обращаться с одним и тем же запросом.
2 Децентрализация структуры. База данных, построенная по такому принципу, представляет собой единую структуру, рассредоточенную в разных местах. При этом всецело модель сущностей согласована. Распределение носит характер оптимизации и разгрузки хранилищ.
3 Несвязная децентрализация. Представляет собой набор баз данных, не спроектированных на совместную работу. Фактически это использование нескольких разнородных БД, управляемых различными СУБД в рамках одной задачи. Необходимость получать данные в запросах, используя несколько разнородных баз позже этапа проектирования.
2.4.2Реплицируемые БД
Достоинство реплицируемых баз данных заключаются в следующем.
Во-первых, репликация способна обеспечить более высокую производительность, поскольку приложения смогут обрабатывать локальные копии вместо того, чтобы устанавливать связь с удаленными узлами.
Во-вторых, наличие репликации может также обеспечивать более высокую степень доступности, поскольку любой реплицируемый объект остается доступным для обработки (по крайней мере, для выборки данных), пока хотя бы одна реплика в системе остается доступной.
Главным недостатком репликации, безусловно, является то, что если реплицируемый объект обновляется, то и все его копии должны быть обновлены (проблема распространения обновлений). [41]
С точки зрения модели репликация в распределенных системах представляется специфическим приложением идеи контролируемой избыточности.
Очевидно, что репликация, как и фрагментация, теоретически должна быть "прозрачной для пользователя". Другими словами, система, которая поддерживает репликацию данных, должна также поддерживать независимость от репликации (иногда говорят "прозрачность репликации"). Для пользователей должна быть создана такая среда, чтобы они, по крайней мере, с логической точки зрения могли считать, что в действительности данные не дублируются. Независимость от репликации (как и независимость от расположения и независимость от фрагментации) является весьма желательной, поскольку она упрощает создание пользовательских программ и выполнение терминальных операций.
В частности, независимость от репликации позволяет создавать и уничтожать дубликаты в любой момент в соответствии с изменяющимися требованиями, не затрагивая при этом никакие из пользовательских программ или терминальных операций.
Из требования независимости от репликации следует, что к обязанностям системного оптимизатора также относится определение, какой именно из физических дубликатов будет применен для доступа к данным при выполнении каждого введенного пользователем запроса. Здесь не приведены подробные сведения по этому вопросу.
Многие коммерческие продукты в настоящее время поддерживают такой вид репликации, который не обеспечивает полной независимости от репликации, т.е. репликация будет не полностью "прозрачна для пользователя".
В случае синхронной репликации, если данная реплика обновляется, все другие реплики того же фрагмента данных также должны быть обновлены в одной и той же транзакции. Логически это означает, что существует лишь одна версия данных. В большинстве продуктов синхронная репликация реализуется с помощью триггерных процедур (возможно, скрытых и управляемых системой). Но синхронная репликация имеет тот недостаток, что она создает дополнительную нагрузку при выполнении всех транзакций, в которых обновляются какие-либо реплики (кроме того, могут возникать проблемы, связанные с доступностью данных).
В случае асинхронной репликации обновление одной реплики распространяется на другие спустя некоторое время, а не в той же транзакции. Таким образом, при асинхронной репликации вводится задержка, или время ожидания, в течение которого отдельные реплики могут быть фактически неидентичными (т.е. определение реплика оказывается не совсем подходящим, поскольку мы не имеем дело с точными и своевременно созданными копиями). В большинстве продуктов асинхронная репликация реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению. Преимущество асинхронной репликации состоит в том, что дополнительные издержки репликации не связаны с транзакциями обновлений, которые могут иметь значение для функционирования всего предприятия и предъявлять высокие требования к производительности. [38] К недостаткам этой схемы относится то, что данные могут оказаться несовместимыми. Иными словами, избыточность может проявляться на логическом уровне, а это, строго говоря, означает, что термин контролируемая избыточность в таком случае не применим.
|
