Некоторые проблемы администрирования баз данных

ФАЗА 1. Узел-координатор посылает информацию об обновлении и запрос о готовности к фиксации всем узлам, содержащим копии обновляемого объекта базы данных. Каждый узел проверяет, может ли он выполнить фиксацию, и посылает ответный сигнал ДА или НЕТ;

ФАЗА 2. Если хотя бы один узел посылает сигнал НЕТ, узел-координатор посылает по системе сигнал отмены, означающий, что все узлы должны игнорировать информацию об обновлении и работать так, как если бы сигнал-предупреждение о фиксации не посылался. При всех ответных сигналах ДА по всей системе посылается сигнал "Commit" (зафиксировать). После того, как узел выполнил фиксацию, он может считать ее завершенной и снять все локальные блоки.

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

Управление каталогом

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

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

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

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

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

Распределенная обработка запросов

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

Распределенная база данных компании состоит из двух файлов: Emp и Depts. В файле Emp содержится информация о сотрудниках кампании; он горизонтально фрагментирован по трем узлам. Файл Depts полностью хранится в одном узле и содержит информацию об отделах компании. Количественное распределение данных по узлам выглядит следующим образом:

УЗЕЛ 1Depts: 10 записей, длина каждой записи 500 байтов; итого 5 000 байтов. Атрибуты: DeptRef (2 байта), DeptName (20 байтов).Emp: 100 записей, длина каждой 100 байтов; итого 10 000 байтов.Атрибуты: EmpNo (10 байтов), EmpName (30 байтов), DeptNo (2 байта).Все записи Emp имеют значение `Region = 1'.

УЗЕЛ 2Emp: 2 000 записей, длина каждой записи 100 байтов, итого 200 000 байтов. Все записи Emp имеют значение 'Region = 2'.

УЗЕЛЗEmp: 1 000 записей, длина каждой записи 100 байтов, итого 100 000 байтов. Все записи Emp имеют значение 'Region = 3'.

Предположим, в УЗЕЛ 2 поступил следующий запрос.

SELECT EmpNo, EmpName, DeptNameFROM Emp E, Dept DWHERE E. Deptno = D. DeptRefAND Region = 3;

Если каждую запись Emp можно соединить с некой записью Depts, в результате выполнения данного запроса получится таблица из 1 000 строк, причем каждая строка будет содержать следующие атрибуты: EmpNo (10 байтов), EmpName (30 байтов) и DeptName (20 байтов), что составляет в сумме 60 000 байтов (1 000Ч60). Этот результат можно получить следующими способами:

1.а) Переслать содержимое файла Depts из узла 1 в узел 2 (5 000 байтов). б) Переслать данные Emp из узла 3 в узел 2 (100 000 байтов).в) Выполнить соединение в узле 2.

Общее количество пересланных данных: 105 000 байтов.

2. а) Переслать содержимое файла Depts из узла 1 в узел 3 (5 000 байтов). б) Выполнить соединение в узле 3. Переслать результат в узел 2 (60 000 байтов). Общее количество пересланных данных: 65 000 байтов.

3. а) Переслать данные Emp из узла 3 в узел 1 (100 000 байтов). б) Выполнить соединение в узле 1. Переслать результат в узел 2 (60 000 байтов).

Обще количество пересланных данных 160 000 байтов.

В распределенных системах наибольшие издержки связаны с пересылкой данных. В описанных выше стратегиях количество пересылаемых данных варьируется от 65 000 до 160 000 байтов. Разница будет еще более значительной, если условию соединения удовлетворяет лишь небольшое подмножество записей. Предположим, что только 10% сотрудников в узле 3 принадлежат к определенным отделам. Это означает, что в результате получится таблица, занимающая всего 6 000 байтов, а в стратегиях 2 и 3 нужно будет переслать 11 000 и 106 000 байтов соответственно.

В идеале распределенная система должна иметь статистическую информацию о размерах множеств данных, хранящихся в каждом из узлов, чтобы можно было выбрать наилучшую стратегию выполнения запроса. При обслуживании запроса следует также использовать особенности фрагментации. Так, в описанных выше стратегиях предполагается, что обработчик запросов в узле 2, "знает", что все записи Emp со значением Region=3 хранятся в узле 3. Если у процессора нет такой информации, он может действовать только путем исследования записей Emp во всех узлах с целью обнаружить требуемые данные. Стратегии 2 и 3 могут использоваться только в том случае, если существует определенный уровень кооперации между различными системами, который позволяет обработчику запросов в одном узле выполнять соединение, требуемое запросом, инициированным в другом узле.

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

Переслать множество различных значений DeptNo из узла 3 в узел 1 (максимум 10Ч2 = 20 байтов).

Возвратить значения DeptRef, DeptName, которые соответствуют этим номерам (10Ч22 = 220 байтов).

Завершить выполнение данного соединения (Join) в узле 3 и переслать результат в узел 2 (60 000 байтов),

Получится 60 240 байтов - наилучший результат из всех, полученных до сих пор.

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

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

Распределенные системы баз данных можно классифицировать на гомогенные и гетерогенные.

Гомогенная распределенная система баз данных - это такая система, в которой каждый узел имеет СУБД одного и того же типа (рис.1).

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

Предположим, есть два узла, причем в обоих находятся реляционные базы данных, но поставщики этих баз данных - различные производители (например, ORACLE и SQL SERVER). Если узел ORACLE хочет получить доступ к базе данных в узле SQL SERVER и использовать ее так же, как если бы она была частью распределенной базы данных ORACLE, ему необходим шлюз к узлу SQL SERVER.

Шлюз - это уровень программного обеспечения, благодаря которому один продукт может "выглядеть" как другой. Так шлюз SQL SERVER/ORACLE дает возможность базе данных SQL SERVER "выглядеть" как база данных ORACLE. Помимо прочего, он обеспечивает отображение типов данных SQL SERVER в типы данных ORACLE, соответствие между SQL-диалектами, используемыми этими двумя программными продуктами, протоколы синхронизации блокировок и стандартных процедур фиксации и т.д. Шлюз находится над программным обеспечением SQL SERVER, и делает его похожим на узел ORACLE. Таким образом аналогичная, но не идентичная СУБД может участвовать в системе, которая в остальном гомогенна.

Предложенное решение дает возможность приложениям в узле ORACLE использовать базу данных SQL SERVER так, как если бы она была частью распределенной системы ORACLE. Чтобы приложения в узле SQL SERVER могли использовать базу данных ORACLE как часть распределенной SQL SERVER-системы, необходимо установить в ORACLE-узле ORACLE/SQL SERVER-шлюз, который будет находиться между локальной системой и SQL SERVER-уровнем программного обеспечения распределенной базы данных.

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

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

фрагментация шифрование репликация сервер

5. Нераспределенные мультибазовые СУБД

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

Клиент-серверные системы

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

Клиент - это машина, обеспечивающая внешнюю оболочку (front end) базы данных. Под внешней оболочкой подразумевается все, что обеспечивает интерфейс пользователя базы данных, будь то SQL-интерпретатор, генератор отчетов, другая вспомогательная программа базы данных или любая прикладная программа, в которую встроены обращения к базе данных. Когда клиентскому приложению требуются услуги базы данных, оно должно послать запрос серверу. Сервер - это машина, на которой установлена СУБД и хранятся данные. Она представляет собой внутреннюю часть базы данных (back end).

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

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

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

Системы с общими ресурсами

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



Литература

1. К.Дж. Дейт. Введение в системы баз данных. Шестое издание. - М.: Вильямс, 2009. - 847 С.)

2. Роланд Ф.Д. Основные концепции баз данных - М.: Вильямс, 2012. - 254 с.

3. Кренке Д. Теория и практика построения баз данных. - СПб.: Питер, 2005 -859 с.

4. Codd E.F. A Relation Model of Data for Large Share Data Banks //CACM. - 1970. -13, No.6.

5. Джо Селко. Программирование на SQL для профессионалов. - М.: Лори, 2014. - 442 С.

6. Фиайли К. SQL. - СПб.: Питер, 2014. 464 с.

7. Астахова И.Ф., Толстобров А.П., Мельников В.М. SQL в примерах и задачах. Учеб. пособие - Мн.: Новое знание, 2012. - 176 с.

8. Чарльз Е. Браун, Рон Петруша. Access VBA: Программирование в примерах. - М.: КУДИЦ-ОБРАЗ, 2006. - 432 с.

9. Дженнингс Р. Использование Microsoft Access 2000. Специальное издание. -М.: Вильямс, 2000. 1148 с.

10. Ахаян Р., Горев А., Макашарипов С. Эффективная работа с СУБД. С-Пб.: Питер Пресс, 2007. 700 с.

11. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989. - 351 с.

12. Мейер М. Теория реляционных баз данных. - М.: Мир, 1987. - 608 с.

13. Дженнингс Р. Руководство разработчика баз данных на Visual Basic 6. - М.: Вильямс, 2010. - 976 с.

14. Информатика. Базовый курс. Под ред. С.В. Симоновича. - СПб.: Питер, 2011. 638 с.

Размещено на Allbest.ru