ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 410
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
5.5.1. Распределение данных
Существуют четыре альтернативные стратегии размещения данных в системе [7]:
1) централизованное;
2) раздельное (фрагментированное);
3) размещение с полной репликацией;
4) размещение с выборочной репликацией.
Централизованное размещение
Данная стратегия предусматривает создание на одном из сайтов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети («распределенная обработка»). В этом случае локальность ссылок минимальна для всех сайтов, за исключением центрального, поскольку для получения любого доступа к данным требуется установка сетевого соединения. Соответственно уровень затрат на передачу данных будет высок. Уровень надежности и доступности в системе низок, поскольку отказ на центральном сайте вызовет паралич работы всей системы.
Раздельное (фрагментированное) размещение
В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из сайтов системы. Если элемент данных будет размещен на том сайте, на котором он чаще всего используется, полученный уровень локальности ссылок будет высок. При отсутствии репликации стоимость хранения данных будет минимальна, но при этом будет невысок также уровень надежности и доступности данных в системе. Однако он будет выше, чем в предыдущем варианте, поскольку отказ на любом из сайтов вызовет утрату доступа только к той части данных, которая на нем хранилась. При правильно выбранном способе распределения данных уровень производительности в системе будет относительно высоким, а уровень затрат на передачу данных – низким.
Размещение с полной репликацией
Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из сайтов системы. Следовательно, локальность ссылок, надежность и доступность данных, а также уровень производительности системы будут максимальны. Однако стоимость устройств хранения данных и уровень затрат на передачу данных в этом случае также будут самыми высокими. Для преодоления части этих проблем в некоторых случаях используется технология моментальных снимков.
Моментальный снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени – например, один раз в час или в неделю, – а потому они не всегда будут актуальными в текущий момент. Иногда в распределенных системах моментальные снимки используются для реализации представлений, что позволяет улучшить время выполнения в базе данных операций с представлениями.
Размещение с выборочной репликацией
Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локальности ссылок, тогда как другие, используемые на многих сайтах, но не подверженные частым обновлениям, подвергаются репликации. Все остальные данные хранятся централизованно.
Целью применения данной стратегии является объединение всех преимуществ, существующих в остальных, моделях, с одновременным исключением свойственных им недостатков. Благодаря своей гибкости именно эта стратегия используется чаще всего.
Сводные характеристики всех рассмотренных выше стратегий приведены в табл. 5.2.
Таблица 5.2
106
Локальность
ссылок
Надежность и
доступность
Производительность
Стоимость
устройств
хранения
данных
Затраты на
передачу
Централизованное
Фрагментирова иное
Полная репликация
Выборочная репликация
Самая низкая
Высокая
Самая высокая высокая
Самая низкая
Низкая для отдельных элементов; высокая для системы в целом
Самая высокая
Низкая для отдельных элементов, высокая для системы
Неудовлетворитель- ная
Удовлетворительная
Хорошая для операций чтения
Удовлетворительная
Самая низкая
Самая низкая
Самая высокая
Средняя
Самая высокая
Низкая
Высокая для операций обновления, низкая для операций чтения
Низкая
5.5.2. Фрагментация
Необходимость фрагментации вызывают следующие причины [7].
Условия использования. Чаще всего приложения работают с некоторыми представлениями, а не с полными базовыми отношениями. Следовательно, с точки зрения распределения данных, целесообразнее организовать работу приложений с определенными фрагментами отношений, выступающими как распределяемые элементы.
Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не используются локальными приложениями.
Параллельность. Поскольку фрагменты являются распределяемыми элементами, транзакции могут быть разделены на несколько подзапросов, обращающихся к различным фрагментам. Такой подход дает возможность повысить уровень параллельности обработки в системе, т.е. позволяет транзакциям, которые допускают это, безопасно выполняться в параллельном режиме.
Защищенность. Данные, не используемые локальными приложениями, не хранятся на сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.
Механизму фрагментации свойственны два основных недостатка.
Производительность. Производительность приложений, требующих доступа к данным из нескольких фрагментов, расположенных на различных сайтах, может оказаться недостаточной.
Целостность данных. Поддержка целостности данных может существенно осложняться, поскольку функционально зависимые данные могут оказаться фрагментированными и размещаться на различных сайтах.
При проведении фрагментации следует обязательно придерживаться трех следующих правил [7].
1. Полнота. Если экземпляр отношения R разбивается на фрагменты, например R
1
, R
2
, ..., R
n
, то каждый элемент данных, присутствующий в отношении R, должен присутствовать, по крайней мере, в одном из созданных фрагментов. Выполнение этого правила гарантирует, что какие-либо данные не будут утрачены в результате выполнения фрагментации.
2. Восстановитостъ. Должна существовать операция реляционной алгебры, позволяющая восстановить отношение R из его фрагментов. Это правило гарантирует сохранение функциональных зависимостей.
3. Непересекаемость. Если элемент данных d
i
присутствует во фрагменте R
i
, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты первичного ключа, необходимые для восстановления исходного отношения.
Данное правило гарантирует минимальную избыточность данных во фрагментах.
В случае горизонтальной фрагментации элементом данных является кортеж, а в случае вертикальной фрагментации – атрибут.
Существуют два основных типа фрагментации (рис. 5.5, а, б):
горизонтальная,
вертикальная.
Горизонтальные фрагменты представляют собой подмножества кортежей отношения, а вертикальные
107
Эта матрица является треугольной, поскольку диагональ ее не заполняется, а нижняя часть является зеркальным отражением верхней части. Единицы в матрице означают наличие доступа с обращением к соответствующей паре атрибутов и, в конечном счете, должны быть заменены числами, отражающими частоту выполнения транзакции. Подобная матрица составляется для каждой транзакции, после чего строится общая матрица, содержащая суммы всех показателей доступа к каждой из пар атрибутов.
Пары атрибутов с высоким показателем родственности должны присутствовать в одном и том же вертикальном фрагменте. Пары с невысоким показателем родственности могут быть разнесены в разные вертикальные фрагменты. Очевидно, что обработка сведений об отдельных атрибутах для всех важнейших транзакций может потребовать немало времени и вычислений. Следовательно, если заранее известно о родственности определенных атрибутов, может оказаться целесообразным обработать сведения сразу о группах атрибутов.
Подобный подход носит название расщепления (splitting) и впервые был предложен группой разработчиков в 1984 году [7]. Он позволяет выделить набор неперекрывающихся фрагментов, которые гарантированно будут отвечать определенному выше правилу непересекаемости. Фактически требование непересекаемости касается только атрибутов, не входящих в первичный ключ отношения.
Атрибуты первичного ключа должны присутствовать в каждом из выделенных вертикальных фрагментов, а потому могут быть исключены из анализа.
В некоторых случаях применения только лишь горизонтальной и вертикальной фрагментации элементов схемы базы данных оказывается недостаточно для адекватного распределения данных между приложениями. В этом случае приходится прибегать к смешанной (или гибридной) фрагментации.
Смешанный фрагмент образуется либо посредством дополнительной вертикальной фрагментации созданных ранее горизонтальных фрагментов, либо за счет вторичной горизонтальной фрагментации предварительно определенных вертикальных фрагментов.
Смешанная фрагментация определяется с помощью операций выборки и проекции реляционной алгебры.
Некоторые приложения включают операции соединения двух или больше отношений. Если отношения сохраняются в различных местах, то выполнение их соединения создаст очень большую дополнительную нагрузку на систему. В подобных случаях более приемлемым решением будет размещение соединяемых отношений или их фрагментов в одном и том же месте. Данная цель может быть достигнута за счет применения производной горизонтальной фрагментации.
Производный фрагмент – горизонтальный фрагмент отношения, созданный на основе горизонтального фрагмента родительского отношения.
Термин «дочернее» используется для ссылок на отношение, содержащее внешний ключ, а термин
«родительское» – для ссылок на отношение с соответствующим первичным ключом. Определение производных фрагментов осуществляется с помощью операции полусоединения реляционной алгебры
(см. гл. 4).
Если отношение включает больше одного внешнего ключа, то может потребоваться выбрать в качестве родительского только одно из связанных отношений. Выбор может быть сделан в соответствии с чаще всего используемым типом фрагментации или с целью достижения оптимальных характеристик соединения – например, соединения, которое включает более мелкие фрагменты или соединения, выполняемого с большей степенью распараллеливания.
Последний вариант возможной стратегии при разработке распределенных БД состоит в отказе от фрагментации отношения [7].
5.5.3. Репликация
Репликацию можно определить как процесс генерации и воспроизведения нескольких копий данных, размещаемых на одном или нескольких сайтах.
109
Механизм репликации очень важен, поскольку позволяет организации обеспечивать доступ пользователям к актуальным данным там и тогда, когда они в этом нуждаются. Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (в тех случаях, когда централизованный ресурс оказывается перегруженным), надежности хранения и доступности данных, наличие «горячей» резервной копии на случай восстановления, а также возможность поддержки мобильных пользователей и хранилищ данных.
5.5.3.1. Виды репликации
Протоколы обновления реплицируемых данных, построены на допущении, что обновления всех копий данных выполняются как часть самой транзакции обновления. Другими словами, все копии реплицируемых данных обновляются одновременно с изменением исходной копии и, как правило, с помощью протокола двухфазной фиксации транзакций [7]. Такой вариант репликации называется
синхронной репликацией.
Хотя этот механизм может быть просто необходим для некоторого класса систем, в которых все копии данных требуется поддерживать в абсолютно синхронном состоянии (например, в случае финансовых операций), ему свойственны определенные недостатки. В частности, транзакция не сможет быть завершена, если один из сайтов с копией реплицируемых данных окажется недоступным. Кроме того, множество сообщений, необходимых для координации процесса синхронизации данных, создают существенную дополнительную нагрузку на корпоративную сеть.
Многие коммерческие распределенные СУБД предоставляют другой механизм репликации, получивший название асинхронного. Он предусматривает обновление целевых баз данных после
выполнения обновления исходной базы данных. Задержка в восстановлении согласованности данных может варьироваться от нескольких секунд до нескольких часов или даже дней. Однако рано или поздно данные во всех копиях будут приведены в синхронное состояние. Хотя такой подход нарушает принцип независимости распределенных данных, он вполне может пониматься как приемлемый компромисс между целостностью данных и их доступностью, причем последнее может быть важнее для организаций, чья деятельность допускает работу с копией данных, необязательно точно синхронизованной на текущий момент.
5.5.3.2. Функции службы репликации
В качестве базового уровня служба репликации распределенных данных должна быть способна копировать данные из одной базы данных в другую синхронно или асинхронно. Кроме того, существует множество других функций, которые должны поддерживаться, включая следующие [7].
Масштабируемость. Служба репликации должна эффективно обрабатывать как малые, так и большие объемы данных.
Отображение и трансформация. Служба репликации должна поддерживать репликацию данных в гетерогенных системах, использующих несколько платформ. Это может быть связано с необходимостью отображения и преобразования данных из одной модели данных в другую или же для преобразования некоторого типа данных в соответствующий тип данных, но для среды другой СУБД.
Репликация объектов. Должна существовать возможность реплицировать объекты, отличные от обычных данных. Например, в некоторых системах допускается репликация индексов и хранимых процедур (или триггеров).
Средства определения схемы репликации. Система должна предоставлять механизм, позволяющий привилегированным пользователям задавать данные и объекты, подлежащие репликации.
Механизм подписки. Система должна включать механизм, позволяющий привилегированным пользователям оформлять подписку на данные и другие подлежащие репликации объекты.
Механизм инициализации. Система должна включать средства, обеспечивающие инициализацию вновь создаваемой реплики.
5.5.3.3. Схемы владения данными
110
Существуют четыре альтернативные стратегии размещения данных в системе [7]:
1) централизованное;
2) раздельное (фрагментированное);
3) размещение с полной репликацией;
4) размещение с выборочной репликацией.
Централизованное размещение
Данная стратегия предусматривает создание на одном из сайтов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети («распределенная обработка»). В этом случае локальность ссылок минимальна для всех сайтов, за исключением центрального, поскольку для получения любого доступа к данным требуется установка сетевого соединения. Соответственно уровень затрат на передачу данных будет высок. Уровень надежности и доступности в системе низок, поскольку отказ на центральном сайте вызовет паралич работы всей системы.
Раздельное (фрагментированное) размещение
В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из сайтов системы. Если элемент данных будет размещен на том сайте, на котором он чаще всего используется, полученный уровень локальности ссылок будет высок. При отсутствии репликации стоимость хранения данных будет минимальна, но при этом будет невысок также уровень надежности и доступности данных в системе. Однако он будет выше, чем в предыдущем варианте, поскольку отказ на любом из сайтов вызовет утрату доступа только к той части данных, которая на нем хранилась. При правильно выбранном способе распределения данных уровень производительности в системе будет относительно высоким, а уровень затрат на передачу данных – низким.
Размещение с полной репликацией
Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из сайтов системы. Следовательно, локальность ссылок, надежность и доступность данных, а также уровень производительности системы будут максимальны. Однако стоимость устройств хранения данных и уровень затрат на передачу данных в этом случае также будут самыми высокими. Для преодоления части этих проблем в некоторых случаях используется технология моментальных снимков.
Моментальный снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени – например, один раз в час или в неделю, – а потому они не всегда будут актуальными в текущий момент. Иногда в распределенных системах моментальные снимки используются для реализации представлений, что позволяет улучшить время выполнения в базе данных операций с представлениями.
Размещение с выборочной репликацией
Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локальности ссылок, тогда как другие, используемые на многих сайтах, но не подверженные частым обновлениям, подвергаются репликации. Все остальные данные хранятся централизованно.
Целью применения данной стратегии является объединение всех преимуществ, существующих в остальных, моделях, с одновременным исключением свойственных им недостатков. Благодаря своей гибкости именно эта стратегия используется чаще всего.
Сводные характеристики всех рассмотренных выше стратегий приведены в табл. 5.2.
Таблица 5.2
106
Локальность
ссылок
Надежность и
доступность
Производительность
Стоимость
устройств
хранения
данных
Затраты на
передачу
Централизованное
Фрагментирова иное
Полная репликация
Выборочная репликация
Самая низкая
Высокая
Самая высокая высокая
Самая низкая
Низкая для отдельных элементов; высокая для системы в целом
Самая высокая
Низкая для отдельных элементов, высокая для системы
Неудовлетворитель- ная
Удовлетворительная
Хорошая для операций чтения
Удовлетворительная
Самая низкая
Самая низкая
Самая высокая
Средняя
Самая высокая
Низкая
Высокая для операций обновления, низкая для операций чтения
Низкая
5.5.2. Фрагментация
Необходимость фрагментации вызывают следующие причины [7].
Условия использования. Чаще всего приложения работают с некоторыми представлениями, а не с полными базовыми отношениями. Следовательно, с точки зрения распределения данных, целесообразнее организовать работу приложений с определенными фрагментами отношений, выступающими как распределяемые элементы.
Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не используются локальными приложениями.
Параллельность. Поскольку фрагменты являются распределяемыми элементами, транзакции могут быть разделены на несколько подзапросов, обращающихся к различным фрагментам. Такой подход дает возможность повысить уровень параллельности обработки в системе, т.е. позволяет транзакциям, которые допускают это, безопасно выполняться в параллельном режиме.
Защищенность. Данные, не используемые локальными приложениями, не хранятся на сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.
Механизму фрагментации свойственны два основных недостатка.
Производительность. Производительность приложений, требующих доступа к данным из нескольких фрагментов, расположенных на различных сайтах, может оказаться недостаточной.
Целостность данных. Поддержка целостности данных может существенно осложняться, поскольку функционально зависимые данные могут оказаться фрагментированными и размещаться на различных сайтах.
При проведении фрагментации следует обязательно придерживаться трех следующих правил [7].
1. Полнота. Если экземпляр отношения R разбивается на фрагменты, например R
1
, R
2
, ..., R
n
, то каждый элемент данных, присутствующий в отношении R, должен присутствовать, по крайней мере, в одном из созданных фрагментов. Выполнение этого правила гарантирует, что какие-либо данные не будут утрачены в результате выполнения фрагментации.
2. Восстановитостъ. Должна существовать операция реляционной алгебры, позволяющая восстановить отношение R из его фрагментов. Это правило гарантирует сохранение функциональных зависимостей.
3. Непересекаемость. Если элемент данных d
i
присутствует во фрагменте R
i
, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты первичного ключа, необходимые для восстановления исходного отношения.
Данное правило гарантирует минимальную избыточность данных во фрагментах.
В случае горизонтальной фрагментации элементом данных является кортеж, а в случае вертикальной фрагментации – атрибут.
Существуют два основных типа фрагментации (рис. 5.5, а, б):
горизонтальная,
вертикальная.
Горизонтальные фрагменты представляют собой подмножества кортежей отношения, а вертикальные
107
подмножества атрибутов отношения.
Кроме того, различают смешанную (рис. 5.5, в, г) и производную (вариант горизонтальной) фрагментации.
Горизонтальный фрагмент – выделенный по горизонтали фрагмент отношения, состоящий из некоторого подмножества кортежей этого отношения.
Горизонтальный фрагмент создается посредством определения предиката, с помощью которого выполняется отбор кортежей из исходного отношения. Данный тип фрагмента определяется с помощью операции выборки (селекции) реляционной алгебры (см. гл. 4). Операция выборки позволяет выделить группу кортежей, обладающих некоторым общим для них свойством, – например, все кортежи, используемые одним из приложений, или все кортежи, применяемые на одном из сайтов.
Рис. 5.5. Типы фрагментации:
а) горизонтальная; 6) вертикальная; в) горизонтально разделенные вертикальные фрагменты; г) вертикально разделенные горизонтальные фрагменты
В одних случаях целесообразность использования горизонтальной фрагментации вполне очевидна.
Однако в других случаях потребуется выполнение детального анализа приложений. Этот анализ должен включать проверку предикатов (или условий) поиска, используемых в транзакциях или запросах, выполняемых в приложении. Предикаты могут быть простыми, включающими только по одному атрибуту, или сложными, включающими несколько атрибутов. Для каждого из используемых атрибутов предикат может содержать единственное значение или несколько значений. В последнем случае значения могут быть дискретными или задавать диапазон значений.
Стратегия определения типа фрагментации предполагает поиск набора минимальных (т.е. полных и релевантных) предикатов, которые можно будет использовать как основу для построения схемы фрагментации [7].
Набор предикатов является полным тогда и только тогда, когда вероятность обращения к любым двум кортежам одного и того же фрагмента со стороны любого приложения будет одинакова.
Предикат является релевантным, если существует, по крайней мере, одно приложение, которое по- разному обращается к выделенным с помощью этого предиката фрагментам.
Вертикальный фрагмент – выделенный по вертикали фрагмент отношения, состоящий из подмножества атрибутов этого отношения.
При вертикальной фрагментации в различные фрагменты объединяются атрибуты, используемые отдельными приложениями. Определение фрагментов в этом случае выполняется с помощью операции
проекции реляционной алгебры (см. гл.4).
Вертикальные фрагменты определяются путем установки родственности одного атрибута по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы, содержащей количество обращений с выборкой каждой из пар атрибутов. Например, транзакция, которая осуществляет доступ к атрибутам A
1
, A
2
и А
4
отношения R, состоящего из набора атрибутов (А
1
, А
2
, А
3
, А
4
), может быть представлена следующей матрицей.
108
Кроме того, различают смешанную (рис. 5.5, в, г) и производную (вариант горизонтальной) фрагментации.
Горизонтальный фрагмент – выделенный по горизонтали фрагмент отношения, состоящий из некоторого подмножества кортежей этого отношения.
Горизонтальный фрагмент создается посредством определения предиката, с помощью которого выполняется отбор кортежей из исходного отношения. Данный тип фрагмента определяется с помощью операции выборки (селекции) реляционной алгебры (см. гл. 4). Операция выборки позволяет выделить группу кортежей, обладающих некоторым общим для них свойством, – например, все кортежи, используемые одним из приложений, или все кортежи, применяемые на одном из сайтов.
Рис. 5.5. Типы фрагментации:
а) горизонтальная; 6) вертикальная; в) горизонтально разделенные вертикальные фрагменты; г) вертикально разделенные горизонтальные фрагменты
В одних случаях целесообразность использования горизонтальной фрагментации вполне очевидна.
Однако в других случаях потребуется выполнение детального анализа приложений. Этот анализ должен включать проверку предикатов (или условий) поиска, используемых в транзакциях или запросах, выполняемых в приложении. Предикаты могут быть простыми, включающими только по одному атрибуту, или сложными, включающими несколько атрибутов. Для каждого из используемых атрибутов предикат может содержать единственное значение или несколько значений. В последнем случае значения могут быть дискретными или задавать диапазон значений.
Стратегия определения типа фрагментации предполагает поиск набора минимальных (т.е. полных и релевантных) предикатов, которые можно будет использовать как основу для построения схемы фрагментации [7].
Набор предикатов является полным тогда и только тогда, когда вероятность обращения к любым двум кортежам одного и того же фрагмента со стороны любого приложения будет одинакова.
Предикат является релевантным, если существует, по крайней мере, одно приложение, которое по- разному обращается к выделенным с помощью этого предиката фрагментам.
Вертикальный фрагмент – выделенный по вертикали фрагмент отношения, состоящий из подмножества атрибутов этого отношения.
При вертикальной фрагментации в различные фрагменты объединяются атрибуты, используемые отдельными приложениями. Определение фрагментов в этом случае выполняется с помощью операции
проекции реляционной алгебры (см. гл.4).
Вертикальные фрагменты определяются путем установки родственности одного атрибута по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы, содержащей количество обращений с выборкой каждой из пар атрибутов. Например, транзакция, которая осуществляет доступ к атрибутам A
1
, A
2
и А
4
отношения R, состоящего из набора атрибутов (А
1
, А
2
, А
3
, А
4
), может быть представлена следующей матрицей.
108
Эта матрица является треугольной, поскольку диагональ ее не заполняется, а нижняя часть является зеркальным отражением верхней части. Единицы в матрице означают наличие доступа с обращением к соответствующей паре атрибутов и, в конечном счете, должны быть заменены числами, отражающими частоту выполнения транзакции. Подобная матрица составляется для каждой транзакции, после чего строится общая матрица, содержащая суммы всех показателей доступа к каждой из пар атрибутов.
Пары атрибутов с высоким показателем родственности должны присутствовать в одном и том же вертикальном фрагменте. Пары с невысоким показателем родственности могут быть разнесены в разные вертикальные фрагменты. Очевидно, что обработка сведений об отдельных атрибутах для всех важнейших транзакций может потребовать немало времени и вычислений. Следовательно, если заранее известно о родственности определенных атрибутов, может оказаться целесообразным обработать сведения сразу о группах атрибутов.
Подобный подход носит название расщепления (splitting) и впервые был предложен группой разработчиков в 1984 году [7]. Он позволяет выделить набор неперекрывающихся фрагментов, которые гарантированно будут отвечать определенному выше правилу непересекаемости. Фактически требование непересекаемости касается только атрибутов, не входящих в первичный ключ отношения.
Атрибуты первичного ключа должны присутствовать в каждом из выделенных вертикальных фрагментов, а потому могут быть исключены из анализа.
В некоторых случаях применения только лишь горизонтальной и вертикальной фрагментации элементов схемы базы данных оказывается недостаточно для адекватного распределения данных между приложениями. В этом случае приходится прибегать к смешанной (или гибридной) фрагментации.
Смешанный фрагмент образуется либо посредством дополнительной вертикальной фрагментации созданных ранее горизонтальных фрагментов, либо за счет вторичной горизонтальной фрагментации предварительно определенных вертикальных фрагментов.
Смешанная фрагментация определяется с помощью операций выборки и проекции реляционной алгебры.
Некоторые приложения включают операции соединения двух или больше отношений. Если отношения сохраняются в различных местах, то выполнение их соединения создаст очень большую дополнительную нагрузку на систему. В подобных случаях более приемлемым решением будет размещение соединяемых отношений или их фрагментов в одном и том же месте. Данная цель может быть достигнута за счет применения производной горизонтальной фрагментации.
Производный фрагмент – горизонтальный фрагмент отношения, созданный на основе горизонтального фрагмента родительского отношения.
Термин «дочернее» используется для ссылок на отношение, содержащее внешний ключ, а термин
«родительское» – для ссылок на отношение с соответствующим первичным ключом. Определение производных фрагментов осуществляется с помощью операции полусоединения реляционной алгебры
(см. гл. 4).
Если отношение включает больше одного внешнего ключа, то может потребоваться выбрать в качестве родительского только одно из связанных отношений. Выбор может быть сделан в соответствии с чаще всего используемым типом фрагментации или с целью достижения оптимальных характеристик соединения – например, соединения, которое включает более мелкие фрагменты или соединения, выполняемого с большей степенью распараллеливания.
Последний вариант возможной стратегии при разработке распределенных БД состоит в отказе от фрагментации отношения [7].
5.5.3. Репликация
Репликацию можно определить как процесс генерации и воспроизведения нескольких копий данных, размещаемых на одном или нескольких сайтах.
109
Механизм репликации очень важен, поскольку позволяет организации обеспечивать доступ пользователям к актуальным данным там и тогда, когда они в этом нуждаются. Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (в тех случаях, когда централизованный ресурс оказывается перегруженным), надежности хранения и доступности данных, наличие «горячей» резервной копии на случай восстановления, а также возможность поддержки мобильных пользователей и хранилищ данных.
5.5.3.1. Виды репликации
Протоколы обновления реплицируемых данных, построены на допущении, что обновления всех копий данных выполняются как часть самой транзакции обновления. Другими словами, все копии реплицируемых данных обновляются одновременно с изменением исходной копии и, как правило, с помощью протокола двухфазной фиксации транзакций [7]. Такой вариант репликации называется
синхронной репликацией.
Хотя этот механизм может быть просто необходим для некоторого класса систем, в которых все копии данных требуется поддерживать в абсолютно синхронном состоянии (например, в случае финансовых операций), ему свойственны определенные недостатки. В частности, транзакция не сможет быть завершена, если один из сайтов с копией реплицируемых данных окажется недоступным. Кроме того, множество сообщений, необходимых для координации процесса синхронизации данных, создают существенную дополнительную нагрузку на корпоративную сеть.
Многие коммерческие распределенные СУБД предоставляют другой механизм репликации, получивший название асинхронного. Он предусматривает обновление целевых баз данных после
выполнения обновления исходной базы данных. Задержка в восстановлении согласованности данных может варьироваться от нескольких секунд до нескольких часов или даже дней. Однако рано или поздно данные во всех копиях будут приведены в синхронное состояние. Хотя такой подход нарушает принцип независимости распределенных данных, он вполне может пониматься как приемлемый компромисс между целостностью данных и их доступностью, причем последнее может быть важнее для организаций, чья деятельность допускает работу с копией данных, необязательно точно синхронизованной на текущий момент.
5.5.3.2. Функции службы репликации
В качестве базового уровня служба репликации распределенных данных должна быть способна копировать данные из одной базы данных в другую синхронно или асинхронно. Кроме того, существует множество других функций, которые должны поддерживаться, включая следующие [7].
Масштабируемость. Служба репликации должна эффективно обрабатывать как малые, так и большие объемы данных.
Отображение и трансформация. Служба репликации должна поддерживать репликацию данных в гетерогенных системах, использующих несколько платформ. Это может быть связано с необходимостью отображения и преобразования данных из одной модели данных в другую или же для преобразования некоторого типа данных в соответствующий тип данных, но для среды другой СУБД.
Репликация объектов. Должна существовать возможность реплицировать объекты, отличные от обычных данных. Например, в некоторых системах допускается репликация индексов и хранимых процедур (или триггеров).
Средства определения схемы репликации. Система должна предоставлять механизм, позволяющий привилегированным пользователям задавать данные и объекты, подлежащие репликации.
Механизм подписки. Система должна включать механизм, позволяющий привилегированным пользователям оформлять подписку на данные и другие подлежащие репликации объекты.
Механизм инициализации. Система должна включать средства, обеспечивающие инициализацию вновь создаваемой реплики.
5.5.3.3. Схемы владения данными
110