5.6.Обеспечение прозрачности

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

иорганизации хранения данных.

Распределенные СУБД могут обеспечивать различные уровни прозрачности. Однако в любом случае преследуется одна и та же цель: сделать работу с распределенной базой данных совершенно аналогичной работе с обычной централизованной СУБД. Выделяют четыре основных типа прозрачности, которые могут иметь место в системе с распределенной базой данных [7].

Прозрачность распределейности.

Прозрачность транзакций.

Прозрачность выполнения.

Прозрачность использования.

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

5.6.1. Прозрачность распределенности

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

или их размещении (прозрачность расположения).

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

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

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

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

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

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

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

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

115

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

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

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

утрата определенной части локальной автономии;

появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);

снижение доступности – если центральный сайт по какой-либо причине станет недоступным, все

остальные сайты системы не смогут создавать никаких новых объектов базы данных [7]. Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в

качестве идентификатора сайта, создавшего этот объект [7]. Аналогичным образом, необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию. Однако подобный подход приводит к утрате прозрачности распределенности.

Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных [7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.

5.6.2. Прозрачность транзакций

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

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

Неделимость остается фундаментальной концепцией понятия транзакции и в случае распределенных транзакций, однако дополнительно СУРБД должна гарантировать неделимость и каждой из ее субтранзакций [7]. Следовательно, СУРБД должна гарантировать не только синхронизацию субтранзакций с другими локальными транзакциями, выполняющимися параллельно с ними на одном сайте, но и обеспечить синхронизацию субтранзакций с глобальными транзакциями, выполняющимися одновременно с ними на этом и других сайтах системы. Прозрачность транзакций в распределенных СУБД дополнительно усложняется за счет наличия фрагментации, распределения данных и использования репликации. Существуют два дополнительных аспекта прозрачности транзакций, таких как прозрачность параллельности и прозрачность отказов.

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

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

116

станет доступным.

Если существует большое количество копий данных, то вероятность успешного завершения транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной стратегией является ограничение распространения сведений об изменении только теми сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении поступят, как только они вновь станут доступными.

Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно, через некоторое время после внесения исходного обновления. Задержка в восстановлении целостности может варьироваться от нескольких секунд до нескольких часов [7].

Любая централизованная СУБД должна включать механизм восстановления, который в подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения транзакций – либо все операции транзакции будут завершены, либо ни одна из них. Если транзакция выполнена, внесенные ею изменения приобретают длительный характер. Среди отказов централизованных СУБД выделяют: сбои системы, отказ носителей, ошибки в программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В распределенных СУБД необходимо дополнительно учитывать следующее:

возможность потери сообщения;

возможность отказа линии связи;

аварийный останов одного из сайтов;

расчленение сетевых соединений.

СУРБД должна гарантировать атомарность глобальных транзакций, т.е. должна синхронизировать выполнение глобальной транзакции так, чтобы все ее субтранзакции были успешно завершены до финальной операции фиксации результатов глобальной транзакции.

5.6.3. Прозрачность выполнения

Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась аналогично работе в централизованной СУБД. В распределенной среде не должно быть видно снижение производительности из-за наличия медленных сетевых соединений и т.д. Прозрачность выполнения требует также, чтобы СУРБД могла находить наиболее эффективные стратегии выполнения запросов.

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

Обработчик распределенных запросов должен знать:

к какому фрагменту следует обратиться;

какую копию фрагмента использовать, если его данные реплицируются;

какое из местоположений должно использоваться [7].

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

время доступа, включающее физический доступ к данным на диске;

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

время, необходимое для передачи данных по сетевым соединениям.

Первые два фактора аналогичны тем, которые учитываются в централизованных системах для оптимизации выполнения запросов. Но в СУРБД доминирующую роль играет время передачи данных по сетевым соединениям, что особенно актуально для глобальных сетей. Скорость передачи в таких каналах может составлять лишь несколько Кбайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют скорость передачи данных, сравнимую со скоростью доступа к дискам (в локальных сетях). В этом случае целесообразно учитывать все три указанных показателя.

117