Сравнительные характеристики различных стратегий.

Стратегия размещения	Локальность ссылок	Надежность и доступность	Производи- тельность	Стоимость устройств хранения	затраты на передачу данных
Централи- зованное	Самая низкая	Самая низкая	Неудовле-творите-льная	Самая низкая	Самые высокие
Фрагменти- рованное	Высокая^1	Низкая для отдельных элементов; высокая для системы в целом	Удовлетво- рительная^1	Самая низкая	Низкие^1
Полная репликация	Самая высокая	Самая высокая	Хорошая для операций чтения	Самая высокая	Высокие для операций обновления. Низкие для операций чтения
Выборочная репликация	Высокая	Низкая для отдельных элементов; высокая для системы	Удовлетво- рительная	Средняя	Низкие^1

¹ При условии качественного проектирования.

Фрагментация

Назначение фрагментации

Необходимость фрагментации вызывают следующие причины.

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

Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не используются локальными приложениями.

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

Защищенность. Данные, не используемые приложениями, не хранятся на соответствующих (т.е. тех же) сайтах, а значит неавторизованные (несанкционируемые) пользователи не смогут получить к ним доступ.

Механизму фрагментации свойственны два основных недостатка (ранее обсуждались).

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

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

1...1 Корректность фрагментации

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

1. Полнота. Если экземпляр отношения R разбивается на горизонтальные фрагменты R₁, R₂, …, R_n, то каждый элемент данных, присутствующий в отношении R, должен присутствовать, по крайней мере, в одном из созданных фрагментов. Выполнение этого правила гарантирует, что какие-либо данные не будут утрачены в результате выполнения фрагментации.

2. Восстанавливаемость. Должна существовать операция реляционной алгебры (например, «объединение»), позволяющая восстановить отношение R из его фрагментов. Это правило гарантирует сохранение функциональных зависимостей.

3. Непересекаемость. Если элемент данных d_i (домена d₁, d₂, …, d_i,…, d_m) присутствует во фрагменте R, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила является операция вертикальная фрагментация, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты значения первичного ключа, необходимые для восстановления исходного отношения. Данное правило гарантирует минимальную избыточность данных во фрагментах.

Типы фрагментации

Существует два основных типа фрагментации: горизонтальная и вертикальная. Горизонтальные фрагменты представляют собой подмножествакортежей отношения, т.е. выделенный по горизонтали фрагмент отношения (рис.1.5.2.1). Они выделяются с помощью операции выборки РА.

Рис. 1.5.2.1. Горизонтальная фрагментация

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

Рис.1.5.2.2. Вертикальная фрагментация

Кроме того, существует еще два типа более сложной фрагментации: смешанная и производная.

Смешанный фрагмент образуется либо посредством дополнительной вертикальной фрагментации созданных ранее горизонтальных фрагментов, либо за счет вторичной горизонтальной фрагментации предварительно определенных вертикальных фрагментов. Смешанная фрагментация определяется с помощью операций выборки и проекции РА (рис. 1.5.2.3).

Рис.1.5.2.3. Смешанная фрагментация

а) горизонтально разделенные вертикальные фрагменты;

б) вертикально разделенные горизонтальные фрагменты.

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

Производный фрагмент – это горизонтальный фрагмент отношения, созданный на основе дочернего отношения – горизонтального фрагмента родительского отношения.

Термин «дочернее» используется для ссылок на отношение, содержащее внешний ключ, а термин «родительское» - для ссылок на отношение с соответствующим первичным ключом. Определение производных фрагментов осуществляется с помощью операции полусоединения РА. Если заданы дочернее отношение R и родительское отношение S, то производный фрагмент отношения R может быть определен так:

Здесь значение w – это количество горизонтальных фрагментов, определенных для отношения S, а параметр F задает атрибут, по которому выполняется их соединение.

Отказ от фрагментации.

Последний вариант возможной стратегии состоит в отказе от фрагментации отношения.

Репликации.

Репликацию можно определить как процессгенерации и воспроизведения нескольких копий данных, размещенных на одном или нескольких сайтах.

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

1) повышение производительности (в тех случаях, когда централизованный ресурс оказывается перегруженным),

2) повышение надежности хранения,

3) наличие горячей резервной копии на случай восстановления.

Виды репликации

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

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

Многие распределенные СУБД представляют другой механизм репликации, получивший название асинхронного. Он предусматривает обновление целевых баз данных (на сайтах 2÷N) после выполнения обновления исходной базы данных (на сайте, к примеру, 1). При этом имеет место задержка в восстановлении согласованности данных. Она может варьироваться от нескольких секунд до нескольких часов или даже дней. Однако рано или поздно данные во всех копиях будут приведены в исходное состояние. Такой подход нарушает принцип независимости от места размещения распределенных данных, но, тем не менее, он вполне может пониматься как приемлемый компромисс между целостностью данных и их доступностью. Последнее свойство может быть важнее для организаций, чья деятельность допускает работу с копией данных, необязательноточносинхронизированной на текущий момент.

Функции службы репликации

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

Масштабируемость. СР должна эффективно обрабатывать как малые, так и большие объемы данных.

Отображение и трансформация. Служба репликации (СР) должна поддерживать репликацию данных в гетерогенных системах, использующих несколько платформ. Это может быть связано с необходимостью отображения и преобразования данных из одной модели данных в другую или же преобразования некоторого типа данных в другой тип данных, но для среды другой СУБД.

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

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

Механизм инициализации. СР должна включать средства, обеспечивающие инициализацию вновь создаваемой реплики.

Схемы владения данными

Владение данными определяет, какому из сайтов будет представлена привилегия обновления данных. Основными типами схем владения являются варианты:

«ведущий - ведомый»,

«рабочий поток»,

«повсеместное обновление».

1. При организации владения данными по схеме «ведущий - ведомый» асинхронно реплицируемые данные принадлежат одному из сайтов, называемому ведущим или первичным, и могут обновляться только на нем. Здесь можно привести аналогию между издателем и подписчиками. Издатель (ведущийсайт) публикует свои (обновленные) данные. Все остальные сайты (подписчики) только лишь подписываются на эти данные, принадлежащие ведущему сайту, т.е. имеют собственные локальные копии, доступные им только длячтения.

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

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

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

Типичным примером использования схемы «рабочий поток» является система обработки запросов, в которой работа с каждым заказом выполняется в несколькоэтапов, например, оформление заказа, подготовка счета (в отделении компании), выписка счета (в центральном офисе компании) и т.д. (рис. 1.5.3.1).

Рис. 1.5.3.1. Схема владения «рабочий поток»

3. Схема владения «повсеместное обновление» создает равноправную среду, в которой множество сайтов имеют одинаковые права на обновление реплицируемых данных. В результате локальные сайты получают возможность работать автономно даже в тех случаях, когда другие сайты недоступны.

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