База рбд что это

Распределенные базы данных

Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.

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

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

а)каждый узел — это полноценная СУБД сама по себе;

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

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1.Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

2.Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

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

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

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

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

8.Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.

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

10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

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

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

1) Распределённые Базы Данных

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

Источник

Архитектура и принципы распределенного подхода. Требования и критерии построения информационных систем на базе распределенных баз данных (РБД)

РБД должна обладать (требования):

Принципы построения РБД.

Критерии построения РБД.

Распределенные архитектуры БД принято подразделять по типам на

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

Это качество можно трактовать как возможность непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а операции над ними выполняются непрерывно».

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

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

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

Источник

Технология РБД¶

Технология РБД (Распределенная База Данных), английский вариант названия DDB (Distributed Data Base), предназначена для построения распределенной базы данных DIGISPOT II PМБД с целью организации автоматического администрируемого обмена информацией между отдельными базами данных DIGISPOT II Медиа БД. Иными словами, если мы имеем несколько инсталляций Медиа БД, разнесенных территориально, но объединенных в одну TCP/IP-сеть (или подключенных к какой либо глобальной сети, например Интернет), то, используя технологию РБД и специальное ПО DIGISPOT II РБД-сервер, можно наладить автоматический обмен данными по заданным правилам между отдельными базами. Среди основных функций РМБД:

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

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

Способы применения технологии¶

Существует разные практические применения данной технологии.

Резервирование канала данных студия-передатчик¶

Предлагаемое решение обеспечивает автоматическое резервирование сигнала радиостанции с использованием динамически изменяемого расписания. Комплекс состоит из двух рабочих мест, соединенных по TCP/IP сети.

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

Организации сети автоматического вещания с доставкой по Интернету¶

Технология РБД позволяет организовать автоматическое вещание сети радиостанций с централизованным управлением и подготовкой эфирного материала. Предположим, что мы имеем несколько передающих центров, расположенных в разных городах, и все они имеют постоянный доступ в Интернет. В городе N имеется офис, включающий отдел продаж, редакцию и студию записи. Установив на всех передающих центрах автономные станции вещания (с ПО «Региональный Автомат РБД»), а в так же установив в центральном офисе в городе N (который так же должен быть подключен к Интернету) DIGISPOT II Медиа БД, DIGISPOT II Джинн:Планирование и РБД-сервер, мы получаем Распределенную Медиа БД. После соответствующей настройки в этой сети эфирное расписание, созданное в главном офисе, вместе со всем относящимся к нему эфирным материалом, будет автоматически отправляться в региональные передающие центры для последующего вещания. Время передачи определяется пропускной способностью каналов связи. Очевидно, что такая схема работы подойдет для радиостанций с полностью автоматическим вещанием, без участия оператора (диджея) на эфире. На практике обычно расписание готовиться заранее, за сутки. Для каждого направления (передающего центра) может быть подготовлено свое индивидуальное расписание, содержащее местные рекламу и новости, а для оживления автоматического вещания могут быть использованы технологии ИТ.

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

Организация сети автоматического вещания с доставкой основной программы по спутниковому каналу¶

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

В такой ситуации технология РБД позволяет автоматизировать подготовку, раздачу и выпуск местных рекламных блоков на всех региональных передающих центрах. Состав оборудования и программного обеспечения тот же: Комплект ПО «Региональный Автомат РБД» на всех региональных точках вещания и ПО DIGISPOT II Джинн:Планирование, DIGISPOT II Медиа БД и РБД-сервер в офисе.

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

Организация корреспондентской сети¶

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

Создание резервного сервера¶

Еще один вариант использования технологии РБД – это создание резервного вещательного сервера, т.е. дешевый вариант кластерной технологии.

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

Источник

База рбд что это

К концу 80-х годов возникли новые условия работы для БД : большие объемы информации возникают во многих местах (например, розничная торговля, полиграфическое и другие производства); источником большого количества данных мог быть и центр, но к этим данным требуется быстрый доступ с периферии (географически распределенное производство, работающее по одному графику). К тому же данные могут запрашиваться и центром, и удаленными потребителями в удаленных местах. Имеется большое количество данных, которые используются в срочных запросах, чаще всего местного характера (продажа авиа- и железнодорожных билетов).

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

Централизованные БД, особенно построенные на классическом подходе, не могли удовлетворить новым требованиям .

Быстрое распространение сетей передачи данных, резкое увеличение объема внешней памяти ПК при ее удешевлении в 80-е годы способствовали широкому внедрению РБД.

К достоинствам РБД относятся:

1) соответствие структуры РБД структуре организаций;

2) гибкое взаимодействие локальных БД;

3) широкие возможности централизации узлов;

4) непосредственный доступ к информации, снижение стоимости передач (за счет уплотнения и концентрации данных);

5) высокие системные характеристики (малое время отклика за счет распараллеливания процессов, высокая надежность);

6) модульная реализация взаимодействия, расширения аппаратных средств, возможность использования объектно-ориентированного подхода в программировании;

7) возможность распределения файлов в соответствии с их активностью;

8) независимые разработки локальных БД через стандартный интерфейс.

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

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

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

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

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

Дополнительными специфическими требованиями являются :

1) ЯОД в рамках схемы должен быть один для всех локальных БД;

2) доступ должен быть коллективным к любой области РБД с соответствующей защитой информации;

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

4) степень централизации должна быть разумной;

5) необходимы сбор и обработка информации об эффективности функционирования РБД .

В дальнейшем рассмотрении РБД выделим:

1) изучение состава, работы и особенностей РБД при условии, что она спроектирована (процедура использования РБД);

2) рассмотрение процедуры создания РБД (проектирование РБД).

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

Общий набор (система таблиц) данных, хранимых в РБД, показан в табл. 12.1.

Это глобальный уровень, который определяется при проектировании теми же методами, что и концептуальная модель централизованной БД.

Не все данные глобального уровня доступны конкретному пользователю. Наиболее полные данные (пользовательский, внешний уровень) имеются в узле 1 головного предприятия. В узлах (участках) 2, 3 данные менее полные. Так, в узле 3 они имеют вид, показанный в табл. 12.2.

Выделяют горизонтальную и вертикальную фрагментацию (расчленение).

Горизонтальное фрагментирование связано с делением данных по узлам. Горизонтальные фрагменты не перекрываются.

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

Фрагментация чаще всего не предполагает дублирования информации в узлах. В то же время при размещении фрагментов по узлам ( локализации ) распределенного уровня в узлах разрешается иметь копии той или иной части РБД.

Так, например, локализация для примера в табл. 12.1. может иметь вид, показанный в табл. 12.3.

Локализация данных

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

Иначе говоря, РБД можно представить в виде, показанном на рис. 12.3.

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предназначавшихся для использования в сети, следует назвать BTrieve, Oracle, Interbase, Sybase, Informix.

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

В общем случае могут быть выделены сетевой, общий внешний, общий концептуальный, локальные внешние, локальные концептуальные и внутренние составляющие словаря РБД.

Естественно, что для работы в РБД необходимы администраторы РБД и локальных БД, рабочими инструментами которых являются перечисленные словари.

Возможны четыре стратегии хранения данных: централизованная (часто обеспечиваемая архитектурой клиент/сервер), расчленение (фрагментации), дублирование, смешанная.

Сравнительные характеристики стратегий хранения приведены в табл. 12.4.

Стратегии хранения данных в РБД

На ее основе может быть построен простейший алгоритм выбора стратегии, показанный на рис. 12.5.

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

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

В этой структуре один из компьютеров, имеющий самый большой объем памяти и наиболее высокое быстродействие, становится приоритетным, называемым сервером.

На сервере чаще всего хранятся только данные, запрашиваемые клиентами.

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

Работа в архитектуре клиент/сервер может поддерживаться и с помощью схемы Open DataBase Connectivity (ODBC), как показано на рис. 12.7.

Сеть образуется в этом случае путем соединения серверов.

Совместно с термином «клиент/сервер» используются три понятия.

Архитектура: речь идет о концепции построения варианта РБД.

Технология: говорят о последовательности действий в РБД.

Система: рассматриваются совокупность элементов и их взаимодействие.

Об архитектуре клиент/сервер говорилось ранее.

Технология клиент/сервер позволяет повысить производительность труда:

1) сокращается общее время выполнения запросов за счет мощного сервера;

2) уменьшается доля и увеличивается эффективность использования клиентом (для вычислений) центрального процессора;

3) уменьшается объем использования клиентом памяти «своего» компьютера;

4) сокращается сетевой трафик.

К таким крупномасштабным системам предъявляются следующие требования:

1) гибкость структуры;

3) доступность данных;

4) легкая обслуживаемость системы;

5) масштабируемость приложений;

6) переносимость приложений (на разные платформы);

7) многозадачность (возможность выполнения многих приложений).

В системе клиент/сервер возможно выделить следующие составляющие: сервер, клиент, интерфейс между клиентом и сервером, администратор.

Сервер осуществляет управление общим для множества клиентов ресурсом. Он выполняет следующие задачи:

1) управляет общей БД;

2) осуществляет доступ и защиту данных, их восстановление;

3) обеспечивает целостность данных.

К БД на сервере предъявляются те же требования, как и к централизованной многопользовательской БД.

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

Клиент хранит в компьютере свои приложения, с помощью которых осуществляется запрос данных на сервере. Клиент решает следующие задачи:

1) предоставляет интерфейс пользователю;

2) управляет логикой работы приложений;

3) проверяет допустимость данных;

4) осуществляет запрос и получение данных с сервера.

Сюда относятся Open Database Connectivity (ODBC) и Integrated Database Application Programming Interface (IDAPI), используемый в приложении Delphi и СУБД InterBase.

Взаимодействие клиентов и сервера можно представить себе следующим образом.

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

Процессы переднего раздела непосредственно обрабатывают запросы, фоновая составляющая связана с управлением процессом обработки.

Работа сервера может иметь такой порядок.

Процесс переднего раздела выбирает «самый старый»запрос и начинает его обработку. После завершения результаты помещаются в очередь для передачи клиенту.

Диспетчер посылает результаты из очереди соответствующему клиенту.

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

Запись данных из БД в промежуточную (буферную) память рабочей области (при чтении) и обратно (при обновлении).

Запись в журнал транзакций.

Архивация (копирование) групп транзакций.

Аварийное завершение транзакций.

Периодическая запись на диск контрольных точек для обеспечения восстановления данных в РБД после аппаратного сбоя.

Администратор РБД (АРБД) должен решать следующие задачи .

Планирование РБД и распределение памяти.

Настройка конфигурации сети.

Работа с разработчиками приложений.

Создание новых пользователей и управление полномочиями.

Регулярная архивация БД и выполнение операций по ее восстановлению.

Управление доступом к БД с помощью ОС и СОС, средств защиты и доступа.

В больших системах АРБД может состоять из ряда лиц, отвечающих, например, за ОС, сеть, архивацию, защиту.

Таким образом, система клиент/сервер своеобразна: с одной стороны, ее можно считать разновидностью централизованной многопользовательской БД, с другой стороны, она является частным случаем РБД.

Использование для составления сценария CASE-средств значительно сокращает трудоемкость работ по проектированию. Иначе эта процедура выполняется вручную с помощью команд языка SQL.

Чтобы его снизить, возможно использовать следующие рекомендации.

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

© Центр дистанционного образования МГУП

Источник