Преимущества и недостатки РСУБД

Системы с распределенными базами данных имеют преимущества перед традиционными централизованными системами баз данных:

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

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

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

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

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

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

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

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

К сожалению, системы с распределенными базами данных не лишены некоторых недостатков:

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

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

3. Проблемы защиты.В централизованных системах доступ к данным легко контролируется. Однако в распределенных системах потребуется организовать контроль доступа не только к дан­ным, реплицируемым на несколько различных сайтов, но и защиту сетевых соедине­ний самих по себе. Раньше сети рассматривались как совершенно незащищенные ка­налы связи. Хотя это отчасти справедливо и для настоящего времени, тем не менее в отношении защиты сетевых соединений достигнут весьма существенный прогресс.

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

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

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

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

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

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

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

• иной тип используемого оборудования;

• иной тип используемой СУБД;

• иной тип применяемых оборудования и СУБД.

Если используется иной тип оборудования, однако на сайте установлен тот же самый тип СУБД, методы выполнения трансляции вполне очевидны и включают замену кодов и изменение длины слова. Если типы используемых на сайтах СУБД различны, процедура трансляции усложняется тем, что необходимо отображать структуры данных одной моде­ли в соответствующие структуры данных другой модели. Например, отношения в реля­ционной модели данных должны быть преобразованы в записи и наборы, типичные для сетевой модели данных. Кроме того, потребуется транслировать текст запросов с одного используемого языка на другой (например, запросы с SQL-оператором SELECT потребуется преобразовать в запросы с операторами FIND и GET языка манипулирования данными сете­вой СУБД). Если отличаются и тип используемого оборудования, и тип программного обеспечения, потребуется выполнять оба вида трансляции. Все изложенное выше чрезвы­чайно усложняет обработку данных в гетерогенных СУБД.

Комитет Open Groupорганизовал рабочую группу (Specification Working Group – SWG), призванную подготовить ответ на поступающие запросы по поводу открытого доступа и взаимодействия баз данных. Цель работы SWG со­стоит в подготовке спецификаций (или в получении подтверждений того, что требуе­мые спецификации существуют или разрабатываются), регламентирующих инфра­структуру среды базы данных, включающую в себя следующие элементы:

• унифицированный и достаточно мощный интерфейс языка SQL (SQL API), позволяющий создавать клиентские приложения таким образом, чтобы они не были привязаны к конкретному типу используемой СУБД;

• унифицированный протокол доступа к базе данных, позволяющий СУБД одного типа непосредственно взаимодействовать с СУБД другого типа без необходимости использования какого-либо шлюза;

• унифицированный сетевой протокол, позволяющий осуществлять взаимо­действие СУБД различного типа.

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

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

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

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

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