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

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

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), позволяющий создавать клиентские приложения таким образом, чтобы они не были привязаны к конкретному типу используемой СУБД;

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

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

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

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

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

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

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