базы данных. Объектом исследования являются Распределенные базы данных
 Скачать 3.84 Mb.
|
|
Содержание Введение Актуальность исследования. В условиях современного динамического развития общества и усложнения технической и социальной инфраструктуры информация становится таким же стратегическим ресурсом, как традиционные материальные и энергетические ресурсы [1]. Современные информационные технологии, позволяющие создавать, хранить, перерабатывать и обеспечивать эффективные способы представления информационных ресурсов потребителю, стали важным фактором жизни общества и средством повышения эффективности управления всеми сферами общественной деятельности. Уровень использования информации становится одним из существенных факторов успешного экономического развития и конкурентоспособности региона как на внутреннем, так и на внешнем рынке. Современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия или учреждения. Для принятия обоснованных и эффективных решений в производственной деятельности, в управлении экономикой современный специалист должен уметь с помощью компьютеров и средств связи получать, накапливать, хранить и обрабатывать данные, представляя результат в виде наглядных документов. Основной причиной разработки систем, использующих базы данных, является стремление интегрировать все обрабатываемые в организации данные в единое целое и обеспечить к ним контролируемый доступ. На практике создание компьютерных сетей приводит к децентрализации обработки данных. Разработка распределенных баз данных позволяет сделать данные, поддерживаемые каждым из существующих подразделений организации, общедоступными, обеспечив при этом их сохранение именно в тех местах, где они чаще всего используются. Подобный подход расширяет возможности совместного использования информации, одновременно повышая эффективность доступа к ней. Объектом исследования являются Распределенные базы данных. Предметом исследования является изучение видов распределенных баз данных, а также процессы их функционирования. Цель исследования состоит в исследовании и анализе распределенных баз данных и распределенных СУБД. Соответственно задачами исследования являются: рассмотрение понятия распределенных баз данных и системы баз данных; реализация систем распределенных баз данных; изучение основ проектирования распределенных баз данных Структура исследования. Данная работа состоит из введения, 2 глав, 5 параграфов, заключения и списка литературы. Основное содержание работы изложено на 35 страницах. Список литературы состоит из 24 источников. 1. Теоретическое описание баз данных 1.1 Определение и характеристики распределенных систем баз данных База данных – это организованная структура, предназначенная для хранения информации. В современных базах данных хранятся не только данные, но и информация. Под распределенной базой данных (Distributed DataBase - DDB) подразумевается база данных, которая включает в себя фрагменты из нескольких баз данных, располагающихся на различных узлах сети компьютеров и могут управляться различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово «распределенная» отражает способ организации базы данных, но не внешнюю ее характеристику («распределенность» базы данных невидима извне). К. Дейтом были сформулированы 12 свойств типичной распределенной базы данных: 1. Локальная автономия (local autonomy) - управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы. 2. Независимость узлов (no reliance on central site) - все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа. 3. Непрерывные операции (continuous operation) - возможность непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках базы данных вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а операции над ними выполняются непрерывно». 4. Прозрачность расположения (location independence) - полную прозрачность расположения данных. Пользователь, обращающийся к базе данных, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами. 5. Прозрачная фрагментация (fragmentation independence) - озможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам. 6. Прозрачное тиражирование (replication independence) - возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами. 7. Обработка распределенных запросов (distributed query processing) – возможны несколько способов пересылки данных, позволяющих выполнить рассматриваемый запрос. 8. Обработка распределенных транзакций (distributed transaction processing) - возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), которые не разрушают целостность и согласованность данных. Эта цель достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции. 9. Независимость от оборудования (hardware independence) - в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей. 10. Независимость от операционных систем (operationg system independence) - многообразие операционных систем, управляющих узлами распределенной системы. 11. Прозрачность сети (network independence) - доступ к любым базам данных может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы. 12. Независимость от баз данных (database independence) - могут сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. Основой этих правил является то, что распределенная база данных должна восприниматься пользователем точно так же, как и привычная централизованная база данных. Работу с распределенными базами данных обеспечивают распределенные системы управления баз данных. Распределенная система управления баз данных (РаСУБД) – комплекс программ, предназначенный для управления распределенной базой данных и позволяющий сделать распределенность информации «прозрачной» для конечного пользователя. Из определения РаСУБД следует, что распределенная база данных состоит из нескольких фрагментов, которые могут размещаться на нескольких компьютерах, расположенных в сети и к ней возможен параллельный доступ нескольких пользователей. Назначение обеспечения «прозрачности» состоит в том, чтобы распределенная система внешне вела себя точно так же, как и централизованная. Такое распределение данных позволяет, например, хранить в узле сети те данные, которые наиболее часто используются в этом узле. Такой подход облегчает и ускоряет работу с этими данными и оставляет возможность работать с остальными данными базы данных, хотя для доступа к ним требуется потратить некоторое время на передачу данных по сети. Основной целью системы распределенных баз данных является обеспечение управляемого доступа и независимого обращения к данным, распределенным в сети ЭВМ. При управляемым доступом понимается степень безопасности, необходимая для защиты данных от неавторизованного доступа. Независимость обращения, или разделимость, позволяет пользователям получать доступ к данным через различные вычислительные средства. Система управления распределенными базами данных обеспечивает средства интеграции локальных баз данных, располагающихся в некоторых узлах компьютерной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных [1]. При этом должны обеспечиваться простота использования системы, возможности автономного функционирования при нарушениях связности сети или при административных потребностях, высокая степень эффективности. Для клиентских приложений распределенная база данных представляется не набором баз, а единым целым. Каждый фрагмент базы данных сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи и каждый из них работает под управлением отдельной системой управления базой данных. Пользователь взаимодействует с распределенной базой данной через приложения. Приложения могут быть классифицированы как те, которые требуют доступа к данным на других узлах (локальные приложения), и те, которые требуют подобного доступа (глобальные приложения). В РаСУБД должно существовать хотя бы одно глобальное приложение, поэтому любая РаСУБД должна иметь следующие особенности: набор логически связанных разделяемых данных; сохраняемые данные разбиты на некоторое количество фрагментов; между фрагментами может быть организована репликация данных; фрагменты и их реплики распределены по различным узлам; узлы связаны между собой сетевыми соединениями; работа с данными на каждом узле управляется локальной СУБД. СУБД на каждом узле способна поддерживать автономную работу локальных приложений. 1.2 Однородные и неоднородные базы данных Распределенные системы часто строятся путем «интеграции» разнородных аппаратных и программных средств. Следовательно, должен быть сделан выбор между однородной и неоднородной вычислительными системами. Во-первых, необходимо определить связь сетевой и локальных СУБД. В случае однородных СУБД нет проблем ни с моделью данных, ни с языком запросов, ни с другими средствами, которые должны быть предоставлены пользователям. Все это совпадает с тем, что поддерживается локальной СУБД. Однако все же существует ряд вопросов, которые необходимо решить, например, должны ли абсолютно все пользователи взаимодействовать с сетевой СУБД или же те пользователи, которым нужны данные, хранящиеся в локальном узле, должны взаимодействовать непосредственно с локальной СУБД. Так как желательно, чтобы возможности, предоставляемые пользователям сетевой СУБД, были эквивалентны или по меньшей мере весьма сходны, вопрос касается главным образом архитектуры программного обеспечения и преимуществ общего программного интерфейса по сравнению с затратами на его поддержание. Если же распределенная база данных поддерживается неоднородными СУБД, то вопросы усложняются. Использование неоднородных СУБД обычно является следствием формирования распределенной базы данных из ряда существовавших ранее автономных баз данных. Стоящая перед разработчиками цель — достичь прозрачности доступа, что представляет собой нечто большее, чем простое обеспечение доступа к удаленным СУБД и их базам данных. Прозрачность означает, что пользователю либо неизвестно расположение данных, либо такие сведения для работы с базой данных ему не требуются. В системах с неоднородными СУБД такое возможно лишь в том случае, если локальная СУБД, управляющая данными, также «прозрачна», т. е. пользователь не обязан знать, какая локальная СУБД обслуживает его запрос. Это можно реализовать двумя принципиально отличными путями. Один путь состоит в том, чтобы дать пользователю возможность использовать в каждом узле пользовательский интерфейс, предоставляемый локальной СУБД. При этом имеющаяся схема должна быть расширена с целью включения данных, имевшихся в других узлах, но пользователи должны работать так, как если бы удаленные данные были добавлены в данную локальную базу данных. Проблема заключается в том, чтобы программное обеспечение сетевой СУБД в каждом узле позволяло обращаться к данным любого другого узла независимо от модели данных и других факторов. При увеличении количества разнородных локальных СУБД количество типов преобразования схем быстро растет. Использование единого для всей сети стандартного пользовательского интерфейса и стандартных внутренних форм представления запроса облегчает решение проблемы преобразования схем. При таком подходе все пользователи или по меньшей мере те из них, кому нужны данные из удаленных узлов, используют общий интерфейс, который может быть отличен от использующегося в любом локальной СУБД. Должна существовать одна схема сетевой базы данных, а не различные схемы в каждом узле, которые зависят от конкретной локальной СУБД. Однородные распределенные системы баз данных имеют в своей основе один продукт СУБД, обычно с единственным языком баз данных (например, SQL с расширениями для управления распределенными данными). СУБД с поддержкой однородного распределения являются сильно связанными системами, их встроенные средства поиска данных и средства обработки запросов оптимизированы и настроены для достижения максимальной производительности и пропускной способности. Существует множество вариантов однородной системы РБД. Так, на некотором узле может существовать одна глобально доступная "главная машина СУБД", с которой связаны компоненты для доступа к данным локальных баз данных, размещенные совместно с самими этими базами данных в пределах всей компании (или отдельного ее подразделения в зависимости от масштаба распределения). Более сложные модели могут допускать распределенность самой СУБД, когда каждый ее компонент на равных правах имеет доступ к данным любого другого узла. Однако относительно собственно управления данными мы имеем здесь идентичные модели хранения, структуры индексирования и форматы данных в рамках всей распределенной среды. Противоположностью однородных систем распределенных БД являются неоднородные распределенные системы БД. Неоднородные системы включают два или более существенно различающихся продукта управления данными (например, реляционные СУБД от разных поставщиков, таких, как Oracle и Digital Equipment Corp., или СУБД одного поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных, такие, как DB2 и SQL/DS компании IBM). Неоднородные системы баз данных можно, в свою очередь, также подразделить на классы в широком диапазоне - от федеративных систем до различных типов систем мультибаз данных; существует и формальная таксономия неоднородных моделей. Однородные распределенные системы баз данных обычно проектируются методом «сверху вниз»; неоднородные же, напротив, чаще всего строятся «снизу вверх» с целью создать общую среду управления над существовавшими ранее разрозненными информационными ресурсами. Проектирование распределенных БД «сверху вниз» осуществляется в целом аналогично проектированию централизованных баз данных. В идеале оно проводится с помощью одной из формальных методологий, которые включают создание концептуальной модели базы данных, отображение ее в логическую модель данных и, наконец, создание и настройку специфических для конкретной СУБД структур (например, таблиц базы данных СУБД Oracle). Однако при проектировании распределенной базы данных методом «сверху вниз» предполагается, что ее объекты не будут сосредоточены в одном месте, а распределятся по нескольким вычислительным системам. В однородных системах все узлы используют один и тот же тип СУБД. В неоднородных системах на узлах могут функционировать различные типы СУБД, использующие разные модели данных. Однородные системы значительно проще проектировать и сопровождать, добавляя новые узлы к уже существующей распределенной системе и повышая производительность системы за счет параллельной обработки информации. Неоднородные системы обычно возникают в тех случаях, когда узлы, уже эксплуатирующие свои собственные системы с базами данных, со временем интегрируются в распределенную систему. В неоднородных системах для организации взаимодействия между различными типами СУБД требуется обеспечить преобразование передаваемых сообщений, для чего каждый из узлов должен иметь возможность формулировать запросы на языке той СУБД, которая используется на их локальном узле или система должна взять на себя выполнение всех необходимых преобразований. 1.3 Дифференциальные файлы Дифференциальный файл в базе данных аналогичен списку опечаток в книге, Вместо того чтобы печатать новое издание книги, всякий раз, когда требуется внести изменения в текст, издатель описывает исправление и указывает номер страницы и строки, куда следует поместить исправление, а затем вносит это описание в список исправлений, который помещает в каждую книгу. Издание, имеющее список исправлений, продается по более низкой цене. При использовании отредактированного варианта книги читатель, прежде чем начать чтение основного текста, должен просмотреть список опечаток. Увеличение времени доступа компенсируется таким образом снижением стоимости поддержания. Если количество изменений в тексте растет, то также растет список опечаток. Он может достичь такого размера, при котором становятся оправданными затраты на реорганизацию. При этом все изменения должны быть непосредственно включены в книгу, тем самым образуя новое издание. Обновление больших баз данных ставит аналогичную задачу. Как и в случае с книгой, обычно наиболее простой и наименее дорогой путь состоит в накоплении изменений за период времени и в последующем перенесении их всех вместе во вновь созданную редакцию (поколение) базы данных. Гораздо более дорогой, основываясь на стоимости хранения, времени поддержания и суммарной сложности системы, является модификация базы данных всякий раз, когда выполняется транзакция обновления. В качестве компромиссного решения может быть использован дифференциальный файл, аналогичный списку опечаток, который осуществляет сбор и идентификацию будущих изменений записей. Предварительное обращение к дифференциальному файлу, являющееся первым шагом при выполнении операции выборки, — эффективное средство доступа к самому последнему состоянию базы данных. Таким образом, путем увеличения времени доступа затраты на обновление базы дынных могут быть уменьшены. Когда дифференциальный файл достигает достаточно больших размеров, проводится реорганизация, в процессе которой все изменения, хранящиеся в дифференциальном файле, вносятся в базу данных, образуя тем самым ее новое поколение, А опустевший дифференциальный файл может снова начать накапливать изменении. Концепция дифференциального файла для различных приложений и различных вариантов появлялась много раз. Применительно к распределенным системам баз данных описаны три способа дифференциального файла. Дифференциальная структура для ленточных систем разработана для того, чтобы исключить запись неизменяемых данных при последовательной пакетной обработке обновлений. Файл данных разбивается на одинаково упорядоченные подфайлы: большая совокупность записей, для которых разрешено только чтение, хранится на одной ленте, в то время как небольшая совокупность модифицируемых записей содержится на отдельной «ленте изменений». Для обновления файла данных обе ленты сливаются, при этом получается новая измененная лента. Неизменяемые записи с ленты, доступной только для чтения, никогда не записываются. Поэтому рекомендуется проводить реорганизацию файла данных после модификации половины всех записей. В файловой системе с прямым доступом необходимо использовать принцип дифференциального файла для обработки изменений. Система обращается к записям через уникальный идентификатор, и любая ссылка на данные проходит через индекс базы данных, которая адресует все записи. Созданный однажды, главный файл данных никогда не модифицируется. Новые записи базы данных обращаются к индексу, но запоминаются в отдельной области переполнения. Все модификации записей данных трактуются как записи добавления. При этом создается новая копия записи и обновляется индекс для указания на область переполнения. Старая запись не уничтожается, а, наоборот, поддерживается как предшествующий образ, на который указывает новая запись, и свидетельствует о том, что новая запись в результате обновления увеличивается в размерах без нарушения размещения соседних записей. Система с подобной структурой была разработана с целью обеспечения восстановления базы данных при внезапном отключении электрического питания, И в этом случае все обращения осуществляются через системный индекс и все модификации выделяются в файл изменений, называемый MODFILE. Каждая измененная запись указывает на свой предыдущий образ. При отключении электрического питании информация из журнала транзакций совместно с информацией из файла MODFILE используется для удаления незавершенных обновлений. Всякий раз, когда запись обновляется одним из описанных в способов, механизм поиска записи (связанный ранее лишь с главным файлом) модифицируется таким образом, чтобы указывать на новую копию записи, которая запоминается в дифференциальном файле. Доступ к текущему значению идентифицированной записи независимо от того, находится ли она в главном или дифференциальном файле, осуществляется при помощи общего механизма поиска – системного индекса. При наличии у каждой записи базы данных своего идентификатора поиск вначале всегда проводится в дифференциальном файле. Если запись там не найдена, выборка осуществляется из главного файла. Подразумевается, что каждый файл может иметь свой собственный механизм поиска. При этом индекс главного файла является неизменяемым и может быть быстро восстановлен в случае сбоя по копии. Изменяемая часть индекса перенесена в меньший и более легко восстанавливаемый индекс дифференциального файла. Чтобы защитить главный файл и его механизм поиска от изменений, приходится идти на накладные расходы в виде поиска в дифференциальном файле при каждом обращении к записи. В том случае, когда оба файла могут быть размещены на отдельных устройствах и доступ к ним осуществляется через независимые каналы, поиск проводится параллельно и пользователи системы не чувствуют дополнительной задержки. Если же параллельный поиск невозможен, приходится ожидать увеличения среднего времени выборки на время произвольного доступа к вторичной памяти. При этом дополнительное время доступа может оказаться сравнительно большим, что значительно снижает производительность системы. В тех случаях, когда значительное увеличение времени доступа недопустимо, предлагается применять модифицированную стратегию поиска, использующую предпоисковый фильтрующий алгоритм для уменьшения количества ненужных обращений к дифференциальному файлу . Дифференциальная организация базы данных имеет ряд преимуществ. Пять из них связаны с целостностью базы данных. Они устанавливают тот факт, что при использовании дифференциального файла можно не только снизить стоимость копирования и скорость восстановления, но даже минимизировать вероятность серьезных потерь данных. Остальные три преимущества связаны с эксплуатацией. Дифференциальный файл может привести к повышению доступности данных и одновременно снизить затраты памяти и стоимость выборки. Снижение стоимости создания дампа базы данных. Путем перезагрузки восстанавливается состояние базы данных, существовавшее в некоторый предыдущей момент времени. Затем в базу данных добавляется накопленный результат обработки всех транзакций обновления, выполняемых с момента последнего копирования базы данных. Частое копирование обеспечивает быстрое восстановление базы данных, но связано с большими системными издержками. Время, требующееся на копирование, пропорционально объему копируемых данных, поэтому применение дифференциального файла может значительно снизить стоимость восстановления большой базы данных, особенно, если доля записей, измененных с момента последнего копирования, невелика. Возможность создания дампа приращениями. Для того, чтобы в любое время обеспечить полное восстановление базы данных, необходимо добавить записи дифференциального файла, созданные после последнего копирования базы данных, к текущему состоянию текущей копии файла. При каждом дампировании приращениями можно сохранять текущее состояние двоичного вектора дифференциального файла и индекс поиска. Возможность дампирования и реорганизации параллельно с обновлением. Путем создания дампа дифференциального файла время, в течение которого запрещены запросы на обновление, может быть существенно снижено. После завершения создания дампа содержащиеся в нем записи должны быть включены в основной дифференциальный файл. Эта же идея дает возможность организовать реорганизацию параллельно с эксплуатацией. После завершения реорганизации происходит замена старого дифференциального файла. Ускорение восстановления после потери данных. Имеется возможность проводить быстрое восстановление системы посредством отката неправильно обработанной или частично не завершенной транзакции. Снижение риска безвозвратной потери данных. Дифференциальный файл концентрирует изменения на малом физическом пространстве и дает потенциальные преимущества: минимизируется критическая незащищенная область; критическая область может быть размещена на более надежном устройстве; небольшая критическая область может быть дублирована для достижения максимальной надежности. Эффективная поддержка «файла памяти». Для того, чтобы исключить существенные издержки, связанные с применением программных средств, обеспечивающих управление многопользовательским доступом, многие системы накапливают изменения для их пакетной обработки после окончания. Упрощение разработки программного обеспечения. В системе с дифференциальным файлом основной файл данных и связанный с ним индекс не подвергаются действию обновлений – это дает возможность использовать имеющиеся средства для разработки нового программного обеспечения. Снижение стоимости хранения базы данных в будущем. Снижение стоимости, обеспечиваемое использование дифференциального файла, значительно увеличит возможную сферу применения автоматизированных информационных систем. 2. Распределение баз данных 2.1 Архитектура распределенных СУБД В сегодняшнем быстро меняющемся компьютерном мире сосуществуют по крайней мере три основные идеологии: клиент-сервер, Web и распределенные объекты (DCOM, CORBA). Внутри каждого направления также существует большое количество решений и стандартов от разных производителей. Сегодняшняя ситуация вызывает очень большую озабоченность независимых разработчиков и потребителей: Какую технологию выбрать и что будет со мной и моим бизнесом, если я приму неправильное решение? При этом очевидно, что цена ошибки будет весьма высока, кроме того большие средства уже вложены в разработку и эксплуатацию уже существующих систем. «Клиент-сервер» - это вид распределенной системы, в которой есть сервер, выполняющий запросы клиента, причем сервер и клиент общаются между собой с использованием того или иного протокола. Под клиентом понимается программа, использующая ресурсы, а под сервером программа, обслуживающая запросы клиентов на получение ресурсов определенного вида. Столь широкое определение включает в себя практически любую программную технологию, в которой участвуют больше одной программы, функции между которыми распределены асимметрично [18]. Существует два подхода к распределению обязанностей между сервером и клиентом при выполнении запросов к базам данных. При использовании технологии файлового сервера клиент делает запрос, сервер передает ему необходимые для выполнения запроса файлы, после чего клиент выбирает из этих файлов нужную информацию. В этом случае львиная доля работы ложится на клиента, по каналам связи передается большое количество данных, большая часть из которых на самом деле не появляется в ответе на запрос. Технология «клиент-сервер» предусматривает, что отбор данных для ответа на запрос делается сервером, а клиенту передается только результат - те данные, которые были запрошены. На рисунке 5 показан процесс обмена информацией между сервером и клиентом при выполнении одного из запросов. При работе с файл-серверной версией вся ответственность за сохранность и целостность базы данных лежит на программе и сетевой операционной системе. Обработка всех данных происходит на рабочих местах, а сервер используется только как разделяемый накопитель. Каждый пользователь непосредственно использует информацию и вносит изменения в файлы данных и в индексные файлы [20]. |