Особенности распределенных СУБД В предыдущей главе была приведена технология проектирования централизованных реляционных баз данных. Рассмотрим дополнительные факторы, которые должны приниматься во внимание при разработке распределенных реляционных баз данных:
– Фрагментация. Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным сайгам. Существуют два основных типа фрагментов: горизонтальные и вертикальные. Горизонтальные фрагменты представляют собой подмножества кортежей, а вертикальные – подмножества атрибутов.
– Распределение. Каждый фрагмент сохраняется на сайте, выбранном с учетом «оптимальной» схемы их размещения (будет подробно рассмотрено в следующем пункте).
– Репликация. СУРБД может поддерживать актуальную копию некоторого фрагмента на нескольких различных сайтах.
Репликацию можно определить как процесс генерации и воспроизведения нескольких копий данных, размещаемых на одном или нескольких сайтах. Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (в тех случаях, когда централизованный ресурс оказывается перегруженным), надежности хранения и доступности данных, наличие «горячей» резервной копии на случай восстановления, а также возможность поддержки мобильных пользователей и хранилищ данных.
Когда несколько сайтов могут независимо вносить изменения в реплицируемые данные, необходимо использовать некоторый механизм, позволяющий выявлять конфликтующие обновления данных и восстанавливать согласованность информации в базе. Известно несколько различных механизмов разрешения конфликтов, однако чаще всего применяются следующие.
– Самая ранняя или самая поздняя временная отметка. Изменяются соответственно данные с самой ранней или самой поздней временной отметкой.
– Приоритеты сайтов. Применяется обновление, поступившее с сайта с наибольшим приоритетом.
– Дополняющие и усредненные обновления. Введенные изменения обобщаются. Этот вариант разрешения конфликтов может использоваться в тех случаях, когда обновление атрибута выполняется операциями, записанными в форме отклонений.
– Минимальное или максимальное значение. Применяются обновления, соответствующие столбцу с минимальным или максимальным значением.
– По решению пользователя. АБД создает собственную процедуру разрешения конфликта. Для устранения различных типов конфликтов могут быть подготовлены различные процедуры.
– Сохранение информации для принятия решения вручную. Сведения о конфликте записываются в журнал ошибок для последующего анализа и устранения администратором базы данных вручную.
Определение и размещение фрагментов по сайтам выполняется для достижения ряда стратегических целей (табл. 1).
Таблица 1. Стратегические цели фрагментации
| №
| Цель
| Сущность
| | 1.
| Локальность ссылок
| Везде, где только это возможно, данные должны храниться как можно ближе к местам их использования. Если фрагмент используется на нескольких сайтах, может оказаться целесообразным разместить на этих сайтах его копии.
| | 2.
| Повышение надежности и доступности
| Надежность и доступность данных повышаются за счет использования механизма репликации. В случае отказа одного из сайтов всегда будет существовать копия фрагмента, сохраняемая на другом сайте.
| | 3.
| Приемлемый уровень производительности
| Неверное распределение данных будет иметь следствием возникновение в системе узких мест. В этом случае некоторый сайт оказывается просто завален запросами со стороны других сайтов, что может вызвать существенное снижение производительности всей системы. В то же время неправильное распределение может иметь следствием неэффективное использование ресурсов системы.
| | 4.
| Баланс между емкостью и стоимостью внешней памяти
| Обязательно следует учитывать доступность и стоимость устройств хранения данных, имеющихся на каждом из сайтов системы. Везде, где только это, возможно, рекомендуется использовать более дешевые устройства массовой памяти. Это требование должно быть сбалансировано с требованием поддержки локальности ссылок.
| | 5.
| Минимизация расходов на передачу данных
| Следует тщательно учитывать стоимость выполнения в системе удаленных запросов. Затраты на выборку будут минимальны при обеспечении максимальной локальности ссылок, т.е. когда каждый сайт будет иметь собственную копию данных. Однако при обновлении реплицируемых данных внесенные изменения потребуется распространить на все сайты, имеющие копию обновленного отношения, что вызовет увеличение затрат на передачу данных.
|
Типичная СУРБД должна обеспечивать как минимум тот же набор функциональных возможностей, что и централизованная СУБД. Кроме того, СУРБД должна предоставлять следующий набор функциональных возможностей:
• Расширенные службы установки соединений должны обеспечивать доступ к удаленным сайтам и позволять передавать запросы и данные между сайтами, входящими в сеть.
• Расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети.
• Средства обработки распределенных запросов, включая механизмы оптимизации запросов и организации удаленного доступа.
• Расширенные функции управления параллельностью, позволяющие поддерживать целостность реплицируемых данных.
• Расширенные функции восстановления, учитывающие возможность отказов в работе отдельных сайтов и отказов линий связи.
Любая СУРБД должна включать четыре следующих важнейших компонента: локальную СУБД; компонент передачи данных; глобальный системный каталог; распределенную СУБД (табл. 1).
Таблица 1. Компоненты СУРБД
| №
| Компонент
| Описание
| | 1.
| Локальная СУБД
| Представляет собой стандартную СУБД, предназначенную для управления локальными данными на каждом из сайтов, входящих в состав распределенной БД. Имеет свой собственный системный каталог, в котором содержится информация о данных, сохраняемых на этом сайте.
| | 2.
| Компонент передачи данных
| Представляет собой программное обеспечение, позволяющее всем сайтам взаимодействовать между собой. Он содержит сведения о существующих сайтах и линиях связи между ними.
| | 3.
| Глобальный системный каталог
| Содержит информацию, специфическую для распределенной природы системы, например, схемы фрагментации и распределения.
| | 4.
| Распределенная СУБД
| Является управляющим компонентом по отношению ко всей системе элементом.
|
СУРБД обязательно должна обеспечивать прозрачность (не случайно это считается первым и основным правилом построения РБД). В широком смысле под прозрачностью понимают сокрытие от пользователей деталей реализации распределенной системы. Распределенные СУБД могут обеспечивать различные типы прозрачности (табл. 1).
Таблица 1. Типы прозрачности
| №
| Тип
| Сущность
| | 1.
| Прозрачность распределенности
| Позволяет конечным пользователям воспринимать базу данных как единое логическое целое. Если СУРБД обеспечивает прозрачность распределенности, то пользователю не требуется каких-либо знаний о фрагментации данных (прозрачность фрагментации) или их размещении (прозрачность расположения).
| | 2.
| Прозрачность транзакций
| При выполнении любых распределенных транзакций (выполняющихся до конца информационных процессов) гарантируется сохранение целостности и согласованности распределенной базы данных.
| | 3.
| Прозрачность выполнения
| Требует, чтобы работа в среде СУРБД выполнялась аналогично работе в централизованной СУБД (а также, чтобы СУРБД могла находить наиболее эффективные стратегии выполнения запросов).
| | 4.
| Прозрачность использования
| Позволяет скрыть от пользователя тот факт, что на разных сайтах могут функционировать различные локальные СУБД. Данный тип прозрачности применим только для гетерогенных систем.
|
Однако в любом случае преследуется одна и та же цель: сделать работу с распределенной базой данных совершенно аналогичной работе с обычной централизованной СУБД. Для конечного пользователя желательно обеспечение всех типов прозрачности.
|