Что является особенностью распределенной базы данных кратко

Обновлено: 04.07.2024

Локальная независимость - узел должен функционировать даже в изоляции

(имеется в виду отвечать как на запросы на чтение, так и на изменение).

Отсутствие центрального узла, так как при его наличии и отключении не выполнится локальная независимость.
Непрерывное функционирование;
- Надежность, то есть все наши изменения будут применены и никогда не потеряются;
- Доступность, даже при отсутствии связности.
Вынуждены использовать стратегию равноправности узлов, но могут выбираться локальные временные координаторы, которые будут координировать запросы, затрагивающие несколько узлов.
- Независимость от расположения;
  - Программы могут работать на любом узле (данные действительно хранятся распределенно в отличие от репликации);
  - Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле);
  Распределенная БД должна логически себя вести как одна большая БД, хотя временные задержки скрыть не удастся.
  - Программы не знают на каком узле находятся данные.
  - Унифицированный доступ к данным, неважно, на локальном ли они узле или удаленном.
  - Географическое секционирование, некоторые узлы могут быть географически удаленных и это надо учитывать.
  - Автоматическая поддержка репликации.
  - Выбор узла для обновления.
  Могут как реплицироваться отдельные узлы, так и целиком вся БД.
  
  Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.
  - Поддержка распределенных запросов.
    - Один запрос получает данные с разных узлов;
    - Несколько узлов могут участвовать в одной транзакции;
    - Должна быть согласованность фиксаций и отката.
    - От аппаратуры, то есть должны быть унифицированное представление данных;
    - От ОС, то есть должна быть конвертация данных и поддержка разных ОС;
    - От сети, например, в дата центрах будет быстрая локальная связь;
    - От типа СУБД, хотелось бы уметь делать распределенную БД, которая обслуживается разными системами управления БД (Oracle, Postgres, etc). Но в реальности все очень печально.
    Можем удовлетворить только двум из следующих трем свойств одновременно:
    - Consistency — информация на разных узлах согласована;
    - Availability — система отвечает на запросы в любой момент времени;
    - Partition tolerance — связи между узлами могут обрываться.
    Но свойства не бинарные, а доказательство верно только для бинарных свойств.
    То есть зачастую согласованность нужна не во всех случаях, не в всегда нельзя пережить без ответа системы и так далее, а значит, что не попадаем под условие CAP-теоремы.
    
    Чаще всего компромиссы рассматривают с точки зрения partition tolerance. В случае разрыва связи можем:
    - Частично отказаться от доступности, поэтому функционировать
    будет только одна часть системы (например, самая большая);
    - Частично отказаться от согласованности, поэтому не все узлы будут в согласованном состоянии,
    но при объединении системы будут протоколы, приводящие всю систему в согласование.
    
    Без обрыва связи система не разделена и будет полностью выполняться как доступность, так и согласованность.
    
    Есть подход BASE, ослабляющий CAP
    - Basically Available - сбой узла приводит к отказу только для части пользователей
    (тех, которые присоединены были в данному узлу);
    - Soft-state - изменение состояния без внешнего вмешательства, данные могут поменяться без изменений со стороны пользователя;
    - Eventual consistency - временная несогласованность.
    Soft-state происходит только в ситуации, когда клиенты отдельно изменяли данные при обрыве соединений, и при восстановлении связи у каждого из клиентов будут изменения произошедшие без его вмешательства.
    Eventual consistency нужен для того, чтобы была гарантия, что мы узнаем обо всех изменениях после применения протокола объединения при восстановлении оборванной связи.
    Последние два свойства нужны для того, чтоб при восстановлении связи система постепенно (не мгновенно) приходила в согласованное состояние.
    
    Этот подход возможно реализовать в реальном мире.
    
    Если разрешать при чтении, то замедляется чтение.
    Можем узнавать, не появилось ли на каком-то удаленном узле изменение наших данных, о котором он еще не успел сообщить, что небыстро.
    
    При записи - замедляется запись.
    Можем запрещать изменять удаленные данные в случае разрыва соединения, но локальные изменять свободно.
    
    Может быть отдельный асинхронный процесс, приводящий систему к согласованию, но это тоже ресурсы.
    Будет честно запрашивать изменения, объединять их и доносить новое состояние до всех узлов БД.
    
    Итого, у нас будет несколько изменений, которые нужно как-то объединить.
    Можно, например, с помощью меток времени или векторных часов.
    
    В распределенном случае еще сложнее, поскольку нужны новые механизмы агрегации, которые будет учитывать планировщик запросов.
    К тому же мы не можем предсказать какой объем данных придет от удаленного узла, а предзапрос для выяснения этого требует дополнительных ресурсов.
    
    Хотим того же, что и при наличии всего одного узла:
    - Минимизация время выполнения;
    - Минимизация количества затронутых данных (в том числе удаленных), чтобы не загружать лишний раз каналы.
    - Минимизация количества коммуникаций, так как сходить лишний раз на удаленный узел - потеря производительности.
    Обычно либо данные напрямую пересылаются к клиенту, либо выбирается один из узлов на которых данные исходно хранятся, но могут быть и более сложные схемы, на которых в теории некий промежуточный узел может агрегировать все данные и уже он их отошлет клиенту.
    - Полусоединения (половины будущего объединения) - один узел может от другого узла спросить id только те, которые ему нужны для построения соединения и делается это за одну коммуникацию;
    - Применение репликации, тогда зачастую клиентскому узлу нужно будет запросить у исходных узлов, нет ли у них изменений в запрашиваемых данных.
    Большое количество узлов может дать как ускорение получение данных, но так и дает большие сложности по синхронизации, все проблемы распределенных систем находят свое место и в распределенных БД.
    - Распараллеливание запроса (достижим гораздо более высокий параллелизм благодаря наличию кучи различных узлов из которых параллельно достаем данные, что быстро);
    - Изоляция транзакций или удаленные распределенные блокировки, что очень непросто;
    - Детектирование распределенных взаимных блокировок тоже усложняет задачу.
    - Распределенные транзакции;
    - Распределенные блокировки;
    - Стратегия основной копии.
    При связной системе можно обойти сложности засчет основной копии, но нужно все равно решать вышеуказанные сложности, так как есть потенциальный отказ коммуникации в системе.
    
    Для каталога (мета-описания наших данных) невозможна Soft-state синхронизация, потому что могут прийти данные, не описанные в каталоге, поэтому с ними действия должны быть синхронны.
    - Независимость от расположения (независимо от узла запрос должен вернуть одни и те же данные);
    - Независимость от фрагментации;
    - Возможность переноса данных.
    - Централизованное хранилище;
    - Полная репликация;
    - Локальное секционирование;
    - Секционирование и репликация.
    Вынуждены хранить реплики каталога во всех местах, но его объем небольшой, поэтому это не проблема. Для изменения делаем одну большую синхронную операцию.
    БД секционирована по конкретным узлам, на которых хранятся данные, и в каталоге явно указано где какие данные хранятся.
    Можем добавлять, удалять узлы Обычно запрещается менять каталог БД, если не все узлы доступны, так как объединить изменение каталогов на практике обычно является нерешаемой задачей.
    
    Используется механизм шлюзов — разные СУБД могут общаться друг с другом за данными несмотря на разные форматы хранения данных, запросов.
    - Реализация протоколов с помощью семантического взаимодействия;
    - Конвертация данных, запросов, каталога;
    - Поддержка распределенных транзакций, блокировок.
    Одна СУБД является координатором запроса, через шлюз достает данные другой СУБД. При запросе шлюз притворяется, что является удаленной копией инициировавшей запрос БД, но получив запрос, транслирует его синтаксис или конвертирует один бинарный протокол в другой, после чего шлюз исполняет запрос на реальной БД другого типа, конвертирует ответ в вид, понятный первой БД и отдает.
    
    Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.
    
    Основные принципы
    
    РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
    
    а)каждый узел — это полноценная СУБД сама по себе;
    
    б)узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
    
    Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
    
    Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:
    
    1.Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
    
    3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
    
    4.Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
    
    5.Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
    
    6.Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
    
    7.Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
    
    8.Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
    
    9.Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
    
    10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
    
    11.Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
    
    12.Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
    
    Типы Распределённых Баз Данных
    
    1) Распределённые Базы Данных
    
    2) Мультибазы данных с глобальной схемой. Система Мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.
    
    3) Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.
    
    4) Мультибазы с общим языком доступа - распределённые среды управления с технологией "клиент-сервер"
    
    5) Интероперабельные системы - это системы, в которых сами приложения, выполняемые в среде той или иной СУБД, ответственны за интерфейсы между различными средами приложения, независимо от того, являются они однородными или неоднородными. Системы ориентированы главным образом на обмен данными. Дальнейшее развитие этих систем является объектно-ориентированные БД.
    
    Системы распределенных вычислений появляются, прежде всего, по той причине, что в крупных автоматизированных информационных системах, построенных на основе корпоративных сетей, не всегда удается организовать централизованное размещение всех баз данных и СУБД на одном узле сети. Поэтому системы распределенных вычислений тесно связаны с системами управления распределенными базами данных.
    
    Распределенная база данных - это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети.
    
    Система управления распределенной базой данных - это программная система, которая обеспечивает управление распределенной базой данных и прозрачность ее распределенности для пользователей.
    
    Распределенная база данных может объединять базы данных, поддерживающие любые модели (иерархические, сетевые, реляционные и объектно-ориентированные базы данных) в рамках единой глобальной схемы. Подобная конфигурация должна обеспечивать для всех приложений прозрачный доступ к любым данным независимо от их местоположения и формата.
    
    Основные принципы создания и функционирования распределенных баз данных:
    
    § прозрачность расположения данных для пользователя (иначе говоря, для пользователя распределенная база данных должна представляться и выглядеть точно так же, как и нераспределенная);
    
    § изолированность пользователей друг от друга (пользователь должен "не чувствовать", "не видеть" работу других пользователей в тот момент, когда он изменяет, обновляет, удаляет данные);
    
    § синхронизация и согласованность (непротиворечивость) состояния данных в любой момент времени.
    
    Из основных вытекает ряд дополнительных принципов:
    
    § локальная автономия (ни одна вычислительная установка для своего успешного функционирования не должна зависеть от любой другой установки);
    
    § отсутствие центральной установки (следствие предыдущею пункта);
    
    § независимость от местоположения (пользователю все равно, где физически находятся данные, он работает так, как будто они находятся на его локальной установке);
    
    § непрерывность функционирования (отсутствие плановых отключений системы в целом, например для подключения новой установки или обновления версии СУБД);
    
    § независимость от фрагментации данных (как от горизонтальной фрагментации, когда различные группы записей одной таблицы размещены на различных установках или в различных локальных базах, так и от вертикальной фрагментации, когда различные поля-столбцы одной таблицы размещены на разных установках);
    
    § независимость от реплицирования (дублирования) данных (когда какая-либо таблица базы данных (или ее часть) физически может быть представлена несколькими копиями, расположенными на различных установках);
    
    § распределенная обработка запросов (оптимизация запросов должна носить распределенный характер - сначала глобальная оптимизация, а далее локальная оптимизация на каждой из задействованных установок);
    
    § распределенное управление транзакциями (в распределенной системе отдельная транзакция может требовать выполнения действий на разных установках, транзакция считается завершенной, если она успешно завершена на всех вовлеченных установках);
    
    § независимость от аппаратуры (желательно, чтобы система могла функционировать на установках, включающих компьютеры разных типов);
    
    § независимость от типа операционной системы (система должна функционировать вне зависимости от возможного различия ОС на различных вычислительных установках);
    
    § независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах);
    
    § независимость от СУБД (на разных установках могут функционировать СУБД различного типа, на практике ограничиваемые кругом СУБД, поддерживающих SQL).
    
    В обиходе СУБД, на основе которых создаются распределенные информационные системы, также характеризуют термином "распределенные СУБД", и, соответственно, используют термин "распределенные базы данных".
    
    Практическая реализация распределенных вычислений осуществляется через отступление от некоторых рассмотренных выше принципов создания и функционирования распределенных систем. В зависимости от того, какой принцип приносится в "жертву" (отсутствие центральной установки, непрерывность функционирования, согласованного состояния данных и др.) выделились несколько самостоятельных направлений в технологиях распределенных систем - технологии "Клиент-сервер", технологии реплицирования, технологии объектного связывания.
    
    Реальные распределенные информационные системы, как правило, построены на основе сочетания всех трех технологий, но в методическом плане их целесообразно рассмотреть отдельно.
    
    5.3 Технологии и модели "Клиент-сервер"
    
    Системы на основе технологий "Клиент-сервер" исторически выросли из первых централизованных многопользовательских автоматизированных информационных систем, интенсивно развивавшихся в 70-х годах (системы mainframe), и получили, вероятно, наиболее широкое распространение в сфере информационного обеспечения крупных предприятий и корпораций.
    
    В технологиях "Клиент-сервер" отступают от одного из главных принципов создания и функционирования распределенных систем - отсутствия центральной установки. Поэтому можно выделить две основные идеи, лежащие в основе клиент-серверных технологий:
    
    § общие для всех пользователей данные на одном или нескольких серверах;
    
    § много пользователей (клиентов), на различных вычислительных установках, совместно (параллельно и одновременно) обрабатывающих общие данные.
    
    Иначе говоря, системы, основанные на технологиях "Клиент-сервер", распределены только в отношении пользователей, поэтому часто их не относят к "настоящим" распределенным системам, а считают отдельным классом многопользовательских систем.
    
    Важное значение в технологиях "Клиент-сервер" имеют понятия сервера и клиента.
    
    Под сервером в широком смысле понимается любая система, процесс, компьютер, владеющие каким-либо вычислительным ресурсом (памятью, временем, производительностью процессора и т. д.).
    
    Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом.
    
    В своем развитии системы "Клиент-сервер" прошли несколько этапов, в ходе которых сформировались различные модели систем "Клиент-сервер". Их реализация и, следовательно, правильное понимание основаны на разделении структуры СУБД на три компонента:
    
    § компонент представления, реализующий функции ввода и отображения данных, называемый иногда еще просто как интерфейс пользователя;
    
    § прикладной компонент, включающий набор запросов, событий, правил, процедур и других вычислительных функций, реализующий предназначение автоматизированной информационной системы в конкретной предметной области;
    
    § компонент доступа к данным, реализующий функции хранения-извлечения, физического обновления и изменения данных.
    
    Исходя из особенностей реализации и распределения в системе этих трех компонентов различают четыре модели технологий "Клиент-сервер":
    
    § модель файлового сервера (File Server - FS);
    
    § модель удаленного доступа к данным (Remote Data Access - RDA);
    
    § модель сервера базы данных (DataBase Server - DBS);
    
    § модель сервера приложений (Application Server - AS).
    
    Системы распределенных вычислений появляются, прежде всего, по той причине, что в крупных автоматизированных информационных системах, построенных на основе корпоративных сетей, не всегда удается организовать централизованное размещение всех баз данных и СУБД на одном узле сети. Поэтому системы распределенных вычислений тесно связаны с системами управления распределенными базами данных.
    
    Распределенная база данных - это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети.
    
    Система управления распределенной базой данных - это программная система, которая обеспечивает управление распределенной базой данных и прозрачность ее распределенности для пользователей.
    
    Распределенная база данных может объединять базы данных, поддерживающие любые модели (иерархические, сетевые, реляционные и объектно-ориентированные базы данных) в рамках единой глобальной схемы. Подобная конфигурация должна обеспечивать для всех приложений прозрачный доступ к любым данным независимо от их местоположения и формата.
    
    Основные принципы создания и функционирования распределенных баз данных:
    
    § прозрачность расположения данных для пользователя (иначе говоря, для пользователя распределенная база данных должна представляться и выглядеть точно так же, как и нераспределенная);
    
    § изолированность пользователей друг от друга (пользователь должен "не чувствовать", "не видеть" работу других пользователей в тот момент, когда он изменяет, обновляет, удаляет данные);
    
    § синхронизация и согласованность (непротиворечивость) состояния данных в любой момент времени.
    
    Из основных вытекает ряд дополнительных принципов:
    
    § локальная автономия (ни одна вычислительная установка для своего успешного функционирования не должна зависеть от любой другой установки);
    
    § отсутствие центральной установки (следствие предыдущею пункта);
    
    § независимость от местоположения (пользователю все равно, где физически находятся данные, он работает так, как будто они находятся на его локальной установке);
    
    § непрерывность функционирования (отсутствие плановых отключений системы в целом, например для подключения новой установки или обновления версии СУБД);
    
    § независимость от фрагментации данных (как от горизонтальной фрагментации, когда различные группы записей одной таблицы размещены на различных установках или в различных локальных базах, так и от вертикальной фрагментации, когда различные поля-столбцы одной таблицы размещены на разных установках);
    
    § независимость от реплицирования (дублирования) данных (когда какая-либо таблица базы данных (или ее часть) физически может быть представлена несколькими копиями, расположенными на различных установках);
    
    § распределенная обработка запросов (оптимизация запросов должна носить распределенный характер - сначала глобальная оптимизация, а далее локальная оптимизация на каждой из задействованных установок);
    
    § распределенное управление транзакциями (в распределенной системе отдельная транзакция может требовать выполнения действий на разных установках, транзакция считается завершенной, если она успешно завершена на всех вовлеченных установках);
    
    § независимость от аппаратуры (желательно, чтобы система могла функционировать на установках, включающих компьютеры разных типов);
    
    § независимость от типа операционной системы (система должна функционировать вне зависимости от возможного различия ОС на различных вычислительных установках);
    
    § независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах);
    
    § независимость от СУБД (на разных установках могут функционировать СУБД различного типа, на практике ограничиваемые кругом СУБД, поддерживающих SQL).
    
    В обиходе СУБД, на основе которых создаются распределенные информационные системы, также характеризуют термином "распределенные СУБД", и, соответственно, используют термин "распределенные базы данных".
    
    Практическая реализация распределенных вычислений осуществляется через отступление от некоторых рассмотренных выше принципов создания и функционирования распределенных систем. В зависимости от того, какой принцип приносится в "жертву" (отсутствие центральной установки, непрерывность функционирования, согласованного состояния данных и др.) выделились несколько самостоятельных направлений в технологиях распределенных систем - технологии "Клиент-сервер", технологии реплицирования, технологии объектного связывания.
    
    Реальные распределенные информационные системы, как правило, построены на основе сочетания всех трех технологий, но в методическом плане их целесообразно рассмотреть отдельно.
    
    5.3 Технологии и модели "Клиент-сервер"
    
    Системы на основе технологий "Клиент-сервер" исторически выросли из первых централизованных многопользовательских автоматизированных информационных систем, интенсивно развивавшихся в 70-х годах (системы mainframe), и получили, вероятно, наиболее широкое распространение в сфере информационного обеспечения крупных предприятий и корпораций.
    
    В технологиях "Клиент-сервер" отступают от одного из главных принципов создания и функционирования распределенных систем - отсутствия центральной установки. Поэтому можно выделить две основные идеи, лежащие в основе клиент-серверных технологий:
    
    § общие для всех пользователей данные на одном или нескольких серверах;
    
    § много пользователей (клиентов), на различных вычислительных установках, совместно (параллельно и одновременно) обрабатывающих общие данные.
    
    Иначе говоря, системы, основанные на технологиях "Клиент-сервер", распределены только в отношении пользователей, поэтому часто их не относят к "настоящим" распределенным системам, а считают отдельным классом многопользовательских систем.
    
    Важное значение в технологиях "Клиент-сервер" имеют понятия сервера и клиента.
    
    Под сервером в широком смысле понимается любая система, процесс, компьютер, владеющие каким-либо вычислительным ресурсом (памятью, временем, производительностью процессора и т. д.).
    
    Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом.
    
    В своем развитии системы "Клиент-сервер" прошли несколько этапов, в ходе которых сформировались различные модели систем "Клиент-сервер". Их реализация и, следовательно, правильное понимание основаны на разделении структуры СУБД на три компонента:
    
    § компонент представления, реализующий функции ввода и отображения данных, называемый иногда еще просто как интерфейс пользователя;
    
    § прикладной компонент, включающий набор запросов, событий, правил, процедур и других вычислительных функций, реализующий предназначение автоматизированной информационной системы в конкретной предметной области;
    
    § компонент доступа к данным, реализующий функции хранения-извлечения, физического обновления и изменения данных.
    
    Исходя из особенностей реализации и распределения в системе этих трех компонентов различают четыре модели технологий "Клиент-сервер":
    
    Под распределенной (Distributed DataBase - DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику. ("распределенность" базы данных невидима извне).
    
    Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных [1].
    
    При этом должны обеспечиваться:
    
    - простота использования системы;
    
    - возможности автономного функционирования при нарушениях связности сети или при административных потребностях;
    
    - высокая степень эффективности.
    
    Свойства распределенных баз данных
    
    Определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date). Он установил 12 свойств или качеств идеальной DDB [4]:
    
    - Локальная автономия (local autonomy)
    
    - Независимость узлов (no reliance on central site)
    
    - Непрерывные операции (continuous operation)
    
    - Прозрачность расположения (location independence)
    
    - Прозрачная фрагментация (fragmentation independence)
    
    - Прозрачное тиражирование (replication independence)
    
    - Обработка распределенных запросов (distributed query processing)
    
    - Обработка распределенных транзакций (distributed transaction processing)
    
    - Независимость от оборудования (hardware independence)
    
    - Независимость от операционных систем (operationg system independence)
    
    - Прозрачность сети (network independence)
    
    - Независимость от баз данных (database independence)
    
    Локальная автономия. Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. Будучи фрагментом общего пространства данных, БД , в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы [4].
    
    Независимость от центрального узла. В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа.
    
    Прозрачность расположения. Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета знаний их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.
    
    Прозрачная фрагментация. Это свойство трактуется как возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Горизонтальная означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вертикальная означает распределение столбцов логической таблицы по нескольким узлам.
    
    SELECT * FROM employee@phoenix, employee@denver ORDER BY emp_id
    
    В то же время запрос "получить информацию о заработной плате сотрудников компании" будет выглядеть следующим образом:
    
    SELECT employee.emp_id, emp_name, salary FROM employee@denver, employee@phoenix, emp_salary@dallas ORDER BY emp_id
    
    Прозрачность тиражирования. Тиражирование данных - это асинхронный процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном контексте прозрачность тиражирования означает возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.
    
    Обработка распределенных запросов. Это свойство DDB трактуется как возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных. Например,
    
    SELECT customer.name, customer.address, order.number, order.date FROM customer@london, order@paris WHERE customer.cust_number = order.cust_number
    
    Обработка распределенных транзакций. Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной транзакции.
    
    Независимость от оборудования. Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".
    
    Независимость от операционных систем. Это качество вытекает из предыдущего и означает многообразие операционных систем, управляющих узлами распределенной системы.
    
    Прозрачность сети. Доступ к любым базам данных осуществляется по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы.
    
    Независимость от баз данных. Это качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.
    
    Целостность данных
    
    В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB - достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции - СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют СУБД CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.
    
    Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать [4].
    
    Обработка распределенных запросов. Обработка распределенных запросов (Distributed Query -DQ) - задача, более сложная, нежели обработка локальных и она требует решения с помощью особого компонента - оптимизатора DQ. Обратимся к базе данных, распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier - на другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков). Результирующая таблица представляет собой объединение таблиц detail и supplier. Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица supplier. Следовательно, оптимизатор DQ запросов должен учитывать такие параметры, как, в первую очередь, размер таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т.д. От интеллекта оптимизатора DQ впрямую зависит скорость выполнения распределенных запросов.
    
    Межоперабельность. В контексте DDB межоперабельность означает две вещи.
    
    Во-первых, - это качество, позволяющее обмениваться данными между базами данных различных поставщиков.
    
    Во-вторых, это возможность некоторого унифицированного доступа к данным в DDB из приложения. Возможны как универсальные решения (стандарт ODBC), так и специализированные подходы. Очевидный недостаток ODBC - недоступность для приложения многих механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения не поддерживаются.
    Специальные подходы - это, например, использование шлюзов, позволяющее приложениям оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных. Вообще, цель шлюза - организация доступа к унаследованным (legacy) базам данных и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Следовательно, шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует - все определяется конкретной ситуацией, историей информационной системы и массой других факторов [2].
    
    Технология тиражирования данных. Тиражирование данных (Data Replication - DR) - это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции DR выполняет, как правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к Oracle7 DBMS опцию Replication Option [7].
    
    Детали тиражирования данных полностью скрыты от прикладной программы. В этом, собственно, состоит качество 6 в определении Дэйта. Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы. Ee "Ахиллесова пята" - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
    DR-технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
    
    Преимущества DR-технологии. Во-первых, данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным позволяет значительно уменьшить трафик. В-третьих, со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано [7].
    
    DR-технология данных не лишена недостатков. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. При проектировании распределенной среды с использованием DR-технологии необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения. В этом смысле применение DR-технологии - наиболее сильная угроза целостности DDB.
    
    Прозрачность расположения. Это качество DDB в реальных продуктах должно поддерживаться соответствующими механизмами. Разработчики СУБД придерживаются различных подходов. Рассмотрим пример из Oracle. Допустим, что DDB включает локальную базу данных, которая размещена на узле в Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем (london_unix), транслируемым в IP-адрес узла в Лондоне.
    
    Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в операторе SELECT таблицу, хранящуюся в этой базе:
    
    и в результате можем написать полностью независимый от расположения базы данных запрос:
    
    SELECT customer.cust_name, order.order_date FROM customer, order WHERE customer.cust_number = order.cust_number
    
    Задача решается с помощью оператора SQL CREATE SYNONYM, который позволяет создавать новые имена для существующих таблиц. При этом оказывается возможным обращаться к другим базам данных и к другим компьютерам.
    
    Во многих СУБД задача управления именами объектов DDB решается путем использования глобального словаря данных, хранящего информацию о DDB: расположение данных, возможности других СУБД (если используются шлюзы), сведения о скорости передачи по сети с различной топологией и т.д.
    
    1.4 Распределенная система управления базами данных System R*
    
    Читайте также:

Что является особенностью распределенной базы данных кратко

Основные принципы

Типы Распределённых Баз Данных