37. Распределенные базы данных. Двенадцать правил Дейта для распределенных баз данных.

Распределенная база данных (DDB – distributed database) – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. Распределенная система управления базой данных определяется как программная система, которая позволяет управлять распределенной базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей [Ozsu and Valduriez, 1991a]. В этом определении следует уточнить две отличительных архитектурных особенности. Первая из них заключается в том, что система состоит из (возможно, пустого) множества узлов приема запросов(query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов – нет. В узлах приема запросов лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Вторая особенность состоит в том, что узлы логически представляют собой независимые компьютеры. Следовательно, у такого узла имеется собственная основная и внешняя память, установлена собственная операционная система (может быть, одна и та же на всех узлах, а возможно, и нет) и имеется возможность выполнять приложения. Узлы связаны компьютерной сетью, а не входят в мультипроцессорную конфигурацию. Важно подчеркнуть слабую связанность процессоров, которые обладают собственными операционными системами и функционирует независимо.

База данных физически распределяется по узлам данных на основе фрагментации и репликацииданных [Ceri et al., 1987]. При наличии схемы реляционной базы данных каждое отношение фрагментируется на горизонтальные или вертикальные разделы. Горизонтальная фрагментацияреализуется при помощи операции селекции, которая направляет каждый кортеж отношения в один из разделов, руководствуясь предикатом фрагментации. Например, для отношения Employee возможна фрагментация в соответствии с местоположением рабочих мест служащих. При вертикальной фрагментации отношение делится на разделы при помощи операции проекции. Например, один раздел отношения Employee может содержать поля Emp_number, Emp_name и Address, а другой – поля Emp_number,Salary и Manager. За счет фрагментации данные приближаются к месту их наиболее интенсивного использования, что потенциально снижает затраты на пересылки; уменьшаются также размеры отношений, участвующих в пользовательских запросах.

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

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

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

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

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

Характеристики распределенной базы данных определяются рядом основополагающих принципов, однако в коммерческих СУБД большинство этих принципов до сих пор не реализовано Необходимо по меньшей мере найти компромисс между этими принципами, поскольку в рамках существующих технологий многие из (них находятся в противоречии друг с другом. Некоторые среды РаБД/РаСУБД однородны локальные менеджеры данных в них представлены одним и тем же продуктом СУБД. Другие по своей природе разнородны в них используются разные продукты СУБД (иногда даже основанные на разных моделях данных, вплоть до плоских файлов). Некоторые среды создаются «сверху вниз», как говорится, «с чистого листа» Однако более типична ситуация, когда для включения унаследованных систем приходится прибегать к конструированию «снизу вверх» Конструирование «снизу вверх» оказывается значительно более сложным, поскольку при объединении    поддерживающих сред обычно возникают характерные проблемы избыточности  данных, обеспечения непротиворечивости, структурного несоответствия. В некоторых системах используются различные модели разбиения (называемого также фрагментацией), которые позволяют распределять данные между различными системами, обеспечивая тем не менее возможность трактовать их глобальным образом, как если бы они были централизованы Другие модели распределения предусматривают тиражирование части или всех данных по множеству систем с целью увеличения общей пропускной способности среды и повышения доступности данных

Что может дать эта технология

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

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

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

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

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

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

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

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

11. Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РаБД, но и для информационных систем вообще.

12. Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД.

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

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

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

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

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

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