Архитектура распределенных СУБД

                                                СОДЕРЖАНИЕ 

Введение…………………………………………………………………………...3

1. Понятие  распределенных и параллельных  СУБД……………………………4

2. Функциональные  возможности СУБД………………………………………..6

3.Архитектура  распределенных СУБД…………………………………………..7

Заключение……………………………………………………………………….10

Список использованной литературы…………………………………………...11

     . 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

                                                      ВВЕДЕНИЕ 

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

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

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

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

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

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

     1. Понятие распределенных  и параллельных  СУБД

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

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

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

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

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

     Архитектуры параллельных систем варьируются между двумя крайними точками, называемыми архитектура без разделяемых ресурсов (shared-nothing) и архитектура с разделяемой памятью (shared-memory). Промежуточную позицию занимает архитектура с разделяемыми дисками (shared-disk).

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

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

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

     Наиболее  существенные характерные для них проблемы – сложность реализации и (потенциальные) трудности соблюдения балансировки нагрузки.

     Примерами систем параллельных баз данных являются продукты DBC (Teradata) и NonStop-SQL (Tandem), а также  ряд прототипов, таких как BUBBA, EDS, GAMMA, GRACE, PRISMA и ARBRE.

     Подход c разделяемой памятью заключается  в том, что каждый процессор посредством  быстрых линий связи (высокоскоростных шин или координатных коммутаторов) соединен со всеми модулями памяти и дисковыми устройствами. Существуют несколько типов мэйнфреймов, следующих этому подходу: IBM3090, DPS8 (Bull), а также симметричные многопроцессорные системы типа Sequent и Encore. Две сильные стороны систем с разделяемой памятью – простота и хорошая балансировка нагрузки. Три наиболее существенные проблемы, связанные с этим подходом, – стоимость, ограниченная масштабируемость, невысокая надежность.

     К системам параллельных баз данных с  разделяемой памятью относятся XPRS, DBS3 и Volcano, а также перенесенные на мультипроцессоры с разделяемой памятью наиболее известные промышленные СУБД. Первым примером такой системы была реализация СУБД DB2 на IBM3090 с шестью процессорами. Во всех известных на сегодня коммерческих продуктах (таких как Ingres и Oracle) используется только межзапросный (но не внутризапросный) параллелизм.

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

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

     Примеры параллельных СУБД с разделяемыми дисками: продукт IMS/VS Data Sharing (IBM), а также продукты VAX DBMS и Rdb компании DEC. Реализация Oracle на компьютерах VAXcluster (DEC) и NCUBE также использует разделение дисков, поскольку этот подход требует минимальных расширений в ядре СУБД. Отметим, что во всех этих системах применяется только межзапросный параллелизм. 

     2. Функциональные возможности  СУБД

     Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

• управление данными во внешней памяти;
• управление буферами оперативной памяти (рабочими областями, в которые осуществляется подкачка данных из базы для повышения скорости работы);
• управление транзакциями.

     Непосредственное  управление данными  во внешней памяти.

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

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

     Управление  буторами оперативной  памяти.

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

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

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

     Управление  транзакциями.

     Транзакция  – это последовательность операций над БД, рассматриваемая СУБД как единое целое. При выполнении транзакция может быть либо успешно завершена, и СУБД зафиксирует произведенные изменения во внешней памяти, либо, например, при сбое в аппаратной части ПК, ни одного из изменений не отразится в БД.

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