Проблемы и особенности распределенных баз данных

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

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

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

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

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

На сегодняшний день реализовано несколько коммерческих распределенных СУБД. Во-первых, это System for Distributor Database (SDD) от компании Computer Corporation of America. Далее идут R* (со звездой) от компании IBM и Distributor Ingress фирмы Relation and Technology. Есть свои РСУБД и у Oracle.

Правила Дейта для распределенных СУБД, выдвинутые в 1987 году:
1) Основной принцип – с точки зрения конечного пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная;

2) Локальная автономность – узлы в распределенной системе должны быть автономными;

3) Отсутствие опорного центрального узла – в системе не должно быть ни одного узла, без которого система не сможет функционировать;

4) Непрерывное функционирование – в идеале в системе никогда не должна возникать потребность в плановой остановке ее функционирования для добавления или удаления узлов или фрагментов;

5) Независимость от расположения – пользователь должен получать доступ к базе данных с любого из узлов;

6) Независимость от фрагментации – пользователь должен получать доступ к данным независимо от способа фрагментации;

7) Независимость от репликации (обновления);

8) Обработка распределенных запросов – система должна поддерживать обработку запросов, ссылающихся на данные, ссылающиеся на данные, расположенные на более чем одном узле;

9) Обработка распределенных транзакций – система должна поддерживать выполнение транзакций, как единицы восстановления;

10) Независимость от типа оборудования – РСУБД должна быть способна функционировать на оборудовании с различными вычислительными платформами;

11) Независимость от операционной системы – РСУБД должна быть способна функционировать под управлением различных операционных систем;
12) Независимость от сетевой архитектуры – РСУБД должна быть способна функционировать в сетях с различной архитектурой и типами носителей;

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

На практике трудно найти РСУБД, которая удовлетворяла бы всем этим характеристикам сразу. Существует ряд препятствий, из-за которых трудно построить идеальную РСУБД, а именно:
1) Низкая производительность – в централизованной базе данных доступ к данным осуществляется за единицы миллисекунд, а скорость передачи – миллионы символов в секунду, в то время как скорость передачи данных по телефонной линии через модем значительно ниже, время доступа уже исчисляется секундами, пропускная способность файла уменьшается до 500 символов в секунду;

2) Проблема сохранения целостности данных – чтобы при выполнении распределенных транзакций соблюдался принцип «все или ничего», необходимо активное взаимодействие двух или более СУБД, возможно, работающих на разных вычислительных системах;

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

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

5) Проблема совместимости данных – связана с тем, что в различных вычислительных системах существуют различные типы данных и разные форматы представления;

6) Проблема хранения системного каталога – под системным каталогом понимаются системные таблицы, в которых хранятся все сведения о базе данных (домены, типы данных, таблицы, индексы, ключи и прочее). Когда база данных распределенная, возникает вопрос, где хранить эти сведения;

7) Оборудование от разных поставщиков – парк компьютеров в организациях формируется годами, поэтому РСУБД вынуждена функционировать на некой смеси машин от разных производителей;

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

9) Проблема восстановления – возникает, когда система, например, из-за сбоев в питании, приходит в негодность, и требуется ее восстановление. Для этого используется журнал транзакций и так далее. Реанимация же распределенной системы вызывает трудности.


Оставить комментарий





Статистика

Рейтинг@Mail.ru