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

Заключительное слово

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

20.7. Средства sql

В настоящее время в языке SQL отсутствует поддержка настоящих распределенных систем. Конечно, в области обработки данных никакой поддержки и не требуется — основная задача распределенной базы данных, с точки зрения пользователя, состоит в том, чтобы сохранить возможности обработки данных неизменными. Тем не менее тре­буются операции определения данных, такие как FRAGMENT, REPLICATE и т.д. [20.15]. Од­нако до сих пор такие операции в языке SQL отсутствуют.

С другой стороны, язык SQL поддерживает некоторые возможности системы построе­ния "клиент/сервер", включая, в частности, операторы CONNECT и DISCONNECT для установ­ления и разрыва соединения. В действительности SQL-приложения должны выполнять операцию CONNECT для соединения с сервером, прежде чем они смогут выдать какой-либо запрос к базе данных (хотя такая операция CONNECT может быть и неявной). Как только со­единение будет установлено, приложение, т.е. клиент, сможет выдать SQL-запрос обычным порядком и необходимая обработка базы данных будет выполнена сервером.

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

Замечание. Стандарт языка SQL также позволяет (но не требует), чтобы реализация поддерживала мультисерверные или многоканальные транзакции. В этом случае кли­ент может переключаться с одного сервера на другой по ходу выполнения транзакции, так что одна часть транзакции выполняется на одном сервере, а другая — на другом. Отметим, в частности, что если для транзакции обновления разрешено охватывать не­сколько серверов, то реализация должна, по-видимому, поддерживать некий вариант двухфазной фиксации, чтобы обесп|чить атомарность транзакции, как предусмотрено стандартом языка SQL.

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

Дополнительную информацию по данному вопросу можно найти в самом стандарте языка SQL [4.22] или в учебном пособии по этому языку [4.19].

20.8. Резюме

В настоящей главе кратко рассматривались системы распределенных баз данных. В качестве плана изложения использовались двенадцать целей для этих систем [20.14]. Однако еще раз подчеркнем, что не все цели равносильны во всех ситуациях. Также здесь речь шла о технических проблемах, которые возникают в областях обработки за­просов, управления каталогом, распространения обновлений, управления восста­новлением и управления параллельностью. Обсуждались те вопросы, попытки реше­ния которых должны обеспечить независимость от СУБД; в частности, в разделе 20.6 описывались шлюзы и промежуточное программное обеспечение для доступа к данным. Затем мы познакомились с обработкой данных в системах "клиент/сервер", которая может рассматриваться как специальный случай распределенной обработки данных в це­лом. Популярность подобных программных продуктов, присутствующих на рынке, по­стоянно возрастает. В частности, в этой главе перечислялись те аспекты языка SQL, ко­торые отвечают требованиям обработки данных в системах "клиент/сервер", а также подчеркивалось, что пользователи должны избегать программирования на уровне за­писей, т.е. операций с курсором. Кратко была описана концепция хранимых процедур и вызовов удаленных процедур.

Замечание. Одна из проблем, которую мы не обсуждали совсем, — проблема физиче­ского проектирования базы данных для распределенных систем. На самом деле, даже если не учитывать возможность фрагментации и репликации, проблема принятия реше­ния о том, какие данные и на каких узлах должны храниться (так называемая проблема размещения), известна как исключительно сложная [20.33]. Фрагментация и репликация лишь еще больше усложняют этот вопрос.

Заслуживает упоминания тот факт, что на рынке программных продуктов стало за­метно присутствие некоторых так называемых .массовых параллельных компьютерных систем (см. аннотацию к [17.58] в главе 17). Такие системы обычно содержат большое количество процессоров, соединенных между собой с помощью высокоскоростной ши­ны. Каждый процессор имеет собственную основную память, собственные дисковые на­копители и выполняет собственную копию программного обеспечения СУБД, а полная база данных распределяется по всему набору дисковых накопителей. Другими словами, такие системы, по существу, представляют собой систему распределенных баз данных "в одном пакете". Безусловно, что для подобных систем остаются справедливыми все наши рассуждения по таким вопросам, как стратегия обработки запросов, двухфазная фикса­ция, ситуация глобальной взаимной блокировки и т.д.

В заключение отметим, что двенадцать целей создания распределенных баз данных (или их подмножество, которое включает по крайней мере цели 4-6 и 8), рассматривае­мых совместно, похоже, равносильны правилам "независимости от распределения" Код-да (Codd) для реляционной СУБД [9.5]. Приведем это правило здесь для ссылок.

■ Независимость от распределения (Кодд): "Реляционная СУБД обладает независи­мостью от распределения... [которая подразумевает, что] СУБД имеет подъязык данных, который позволяет пользовательским программам и процедурам терми­нальной обработки оставаться логически незатронутыми в следующих ситуациях.

а) Когда распределение данных вводится впервые (если первоначально установ- ленная СУБД оперировала только нераспределенными данными).

б) Когда данные перераспределяются (если СУБД оперирует распределенными данными)".

И наконец отметим, что (как уже упоминалось в этой главе) цели 4-6 и 9-12, т.е. все цели, в названии которых есть слово "независимость", могут рассматриваться как рас­ширение привычного понятия независимости данных на случай его применения для рас­пределенной среды. При этом указанные принципы по сути превращаются в инструмент защиты инвестиций в приложения.

Упражнения

1. Дайте определение понятиям независимости от расположения, независимости от фрагментации и независимости от репликации.

2. Почему почти все системы распределенных баз данных являются реляционными?

3. Какими преимуществами обладают распределенные системы? Какие недостатки им свойственны?

4. Объясните следующие термины.

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

5. Опишите схему присвоения имен объектам в системе R*.

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

7. Исследуйте любую доступную вам систему "клиент/сервер". Поддерживаются ли в ней явным образом операции установления соединения CONNECT и разрыва соеди­нения DISCONNECT? Поддерживается ли в ней операция SET CONNECTION или какие-либо другие операции с "соединениями"? Поддерживаются ли в ней многосерверные транзакции? Поддерживается ли в ней двухфазная фиксация? Ка­кие форматы и протоколы используются для установки соединений типа "клиент/сервер"? Какие типы сетевых сред в ней поддерживаются? Какое аппарат­ное обеспечение поддерживается для узлов клиентов и узлов серверов? Какое про­граммное обеспечение (операционная система, СУБД) поддерживается для узлов клиентов и узлов серверов?

20.8. Исследуйте любую доступную вам СУБД, поддерживающую язык SQL. Поддер­живаются ли в ней хранимые процедуры? Если поддерживаются, то как они соз­даются? Как они вызываются? На каких языках они пишутся? Полностью ли в ни> поддерживается стандарт языка SQL? Поддерживаются ли в них условное ветвле­ние (IF-THEN-ELSE) и циклы? Каким образом результаты возвращаются клиенту'. Может ли одна хранимая процедура вызвать другую? А на другом узле? Выполня­ется ли хранимая процедура как часть вызванной транзакции?

Список литературы

20.1. Anderson Т., Breibart Y., Korth Н. F., Wool A. Replication, Consistency, and Practicality: Are These Mutually Exclusive? // Proc. 1998 ACM SIGMOD Int. Conf. or Management of Data. — Seattle, Wash., June, 1998.

В этой статье описаны три схемы для асинхронной репликации (называемой здесь ленивой), схемы, которые гарантируют атомарность транзакций и их глобальную не­прерывность без использования двухфазной фиксации. Также описывается имитаци­онное исследование их относительной производительности. Глобальная блокировка, предложенная в [20.21], используется только в первой схеме. В двух других схемах, первая из которых пессимистическая, а вторая оптимистическая, используется граф репликации. В статье делается вывод, что схемы с графом репликации превосходят схемы с использованием блокировки "обычно с огромным преимуществом".

2. Bell D., Grimson J. Distributed Database Systems. — Reading, Mass.: Addison-Wesley, 1992. Это одно из нескольких существующих учебных пособий, посвященных теме рас­пределенных систем (два других упоминаются в [20.10] и [20.31]). Особенностью книги является подробное изложение учебного материала на основе примера соз­дания сети в учреждениях здравоохранения. К тому же по сравнению с двумя сле­дующими публикациями она является более практической.

3. Bernstein P. A. Middleware: A Model for Distributed System Services // CACM.— February, 1996. — 39, № 2.

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

20.4. Bernstein P. A., Rothnie J. В., Shipman D. W. (eds.). Tutorial: Distributed Data Base Management // IEEE Computer Society. — 5855 Naplas Plaza, Suite 301, Long Beach, Calif., 1978.

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

1. Обзор методов управления реляционной базой данных.

2. Обзор методов управления распределенной базой данных.

3. Методы обработки распределенных запросов.

4. Методы управления распределенной параллельностью.

5. Методы обеспечения надежности распределенной базы данных.

20.5. Bernstein P. A. et al. Query Processing in a System for Distributed Databases (SDD-1) // ACM TODS. — December, 1981. — 6, № 4. '

См. комментарий к [20.34].

20.6. Bernstein P. A., Shipman D. W., Rothnie J. B. Concurrency Control in a System for Dis- tributed Databases (SDD-1) // ACM TODS. — March, 1980. — 5, № 1.

См. комментарий к [20.34].

20.7. Bontempo С. J., Saracco С. M. Data Access Middleware: Seeking out The Middle Ground // InfoDB. — August, 1995. — 9, № 4.

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

8. Breitbart Y., Garcia-Molina Н., Silberschatz A. Overview of Multi-Database Transaction Management // The VLDB Journal. — October, 1992. — 1, Ns 2.

9. Bright Y., Hurson A. R., Pakzad S. Automated Resolution of Semantic Heterogeneity in Multi-Databases // ACM TODS. — June, 1994. — 19, № 2.

20.10.Ceri S., Pelagatti G. Distributed Databases: Principles and Systems. — New York, N.Y.: McGraw-Hill, 1984.

20.11.Cohen W. W. Integration of Heterogeneous Databases without Common Domains Using Queries Bases on Textual Similarity // Proc. 1998 ACM SIGMOD Int. Conf. on Man­agement of Data. — Seatle, Wash., June, 1998.

Описывается подход, который иногда называют "проблемой ненужных писем". Он позволяет определить, когда две различные текстовые строки (скажем, "AT&T Bell Labs" и "AT&T Research") ссылаются на один и тот же объект (подразумеваются, конечно, определенные семантические различия). Данный подход включает воз­можности определения схожести таких строк, "которые рассчитаны на использо­вание модели векторного пространства, применяемой в выборке статистических данных". По мнению авторов статьи, быстродействие этого подхода значительно выше, чем быстродействие "простых методов вывода", и, кроме того, он действи­тельно дает удивительно точные результаты.

20.12.Daniels D. et al. An Introduction to Distributed Query Compilation in R* // Distributed Data Bases (ed. H.-J. Schneider): Proc. 2nd Int. Symposium on Distributed Data Bases. — New York, N.Y.: North-Holland, 1982. См. комментарий к [20.39].

20.13.Date С. J. Distributed Databases // Date C. J. An Introduction to Database Systems: Vol­ume II. Chapter 7. — Reading, Mass.: Addison-Wesley, 1983. Некоторые части данной главы основаны на этой более ранней публикации.

20.14.Date С. J. What is a Distributed Database System? // Date С. J. Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990. В статье введены двенадцать целей для распределенных систем (раздел 20.3 по­строен строго в соответствии с этой статьей). Как уже упоминалось, требование локальной автономии не может быть достигнуто на все сто процентов. Поэтому определенные ситуации требуют принятия в этом отношении компромиссных ре­шений, кратко перечисленных ниже.

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

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

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

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

• Узел, который действует как участник процесса двухфазной фиксации, должен строго придерживаться указаний (относительно фиксации или отката) соответ­ствующего узла-координатора.

20.15.Date С. J. Distributed Database: A Closer Look // Date С. J. and Darwen H. Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992. Продолжение публикации [20.14], в которой более подробно обсуждаются многие из перечисленных в этой главе двенадцати целей (хотя изложение ведется в стиле учебного пособия).

20.16.Date С. J. Why Is It So Difficult to Provide A relation Interface to IMS? // Relational

Database: Selected Writings. — Reading, Mass.: Addison-Wesley, 1986. 20.17.Epstein R., Stonebraker M., Wong E. A Distributed Query Processing in a Relational

Database System // Proc. 1978 ACM SIGMOD Int. Conf. on Management of Data. —

Austin, Tx., May-June, 1978.

См. комментарий к [20.36]. 20.18.Goldring R. A Discussion of Relational Database Replication Technology // InfoDB. —

1994. —8, № 1.

Прекрасный обзор асинхронной репликации. 20.19.Grant J., Litwin W., Roussopoulos N., Sellis T. Query Languages for Relational Multi-Databases // The VLDB Journal. — April, 1993. — 2, № 2.

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

20.20.Gray J. N. A Discussion of Distributed Systems // Proc. Congresso AICO 79. — Bari, It­aly, October, 1979. (Эта статья также опубликована в виде отчета: IBM Research Report RJ2699. — 1979.)

Краткий, но очень удачный обзор и одновременно учебное пособие. 20.21.Gray J., Helland P., O'Neil P., Shasha D. The Dangers of Replication and a Solution // Proc. 1996 ACM SIGMOD Int. Conf. on Management of Data. — Montreal, Canada, June, 1996.

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

20.22.Gupta R., Haritsa J., Ramamritham K. Revisiting Commit Processing in Distributed Da­tabase Systems // Proc. 1997 ACM SIGMOD Int. Conf. on Management of Data.— Tucson, Ariz, May, 1997.

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

20.23.Hackathorn R. D. Interoperability: DRDA or RDA? // InfoDB. — 1991. — 6, № 2.

20.24.Hammar M., Shipman D. Reliability Mechanism for SDD-1; A System for Distributed Databases // ACM TODS. — December, 1980. — 5, № 4. См. комментарий к [20.34].

20.25.IBM Form №SC26-4651. IBM Corporation: Distributed Relational Database Architec­ture Reference.

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

1. Удаленный запрос.

2. Удаленная часть работы.

3. Распределенная часть работы.

4. Распределенный запрос.

Поскольку эти термины фактически стали стандартами программного обеспечения, по крайней мере некоторой его части, здесь следует объяснить их немного подробнее. Замечание. Термины "запрос" и "часть работы" предложены специалистами фир­мы IBM для понятий оператор SQL и транзакция соответственно.

1. Удаленный запрос. Означает, что приложение на узле X может отослать для выполнения отдельный SQL-оператор некоторому удаленному узлу Y. Этот запрос полностью выполняется и фиксируется (или откатывается) на узле Y. Исходное приложение на узле X может впоследствии отослать другой запрос узлу Y (или, возможно, третьему узлу Z) независимо от того, был ли первый запрос успешным.

2. Удаленная часть работы. Означает, что приложение на одном узле X может отсылать на некоторый удаленный узел Y для выполнения все запросы к базе данных в составе некоторой заданной "части работы" (т.е. транзакции). Таким образом, обработка транзакции для этой базы данных выполняется целиком на удаленном узле Y. Однако решение о том, будет ли данная транзакция заверше­на или отменена, принимается на локальном узле X.

Замечание. Удаленная часть работы, по сути, является некоторым процессом в системе "клиент/сервер" с единственным сервером.

3. Распределенная часть работы. Означает, что приложение на одном узлеУ может отсылать к одному или нескольким удаленным узлам Y, Z, ... для выпол- нения некоторые запросы или все запросы к базе данных в составе некоторой заданной "части работы" (т.е. транзакции). Таким образом, обработка транзак- ции для этой базы данных в общем случае выполняется на нескольких узлах.

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

Замечание. Распределенная часть работы фактически является некоторым про­цессом в системе "клиент/сервер" с несколькими серверами. 4. Распределенный запрос. Это единственный из всех четырех уровней, который наиболее близок к понятию поддержки истинной распределенной базы данных. Понятие "распределенный запрос" означает то же самое, что и "распределенная часть работы", плюс разрешение на выполнение индивидуальных запросов (SQL-операторов) к базе данных с охватом нескольких узлов. Например, со­гласно запросу, поступившему от узла X, может потребоваться выполнить объе­динение или соединение таблицы на узле Y и таблицы на узле Z. Отметим, что только на этом уровне о системе можно сказать, что она обладает истинной не­зависимостью от расположения. Во всех трех предыдущих случаях пользова­тель должен иметь сведения о физическом расположении данных. 20.26. Документ ISO DIS 9579-1. Information Processing Systems, Open Systems Interconnection,

Remote Data Access Part 1: Generic Model, Service, and Protocol. — March, 1990. 20.27.Документ ISO DIS 9579-2. Information Processing Systems, Open Systems Intercon­nection, Remote Data Access Part 2: SQL Specialization. — February, 1990. 20.28.Lindsay B. G. et al. Notes on Distributed Databases // IBM Research Report RJ2571. — July, 1979.

Эта статья некоторыми членами команды разработчиков системы R* разделена на пять глав.

1. Реплицируемые данные.

2. Права доступа и представления.

3. Введение в управление распределенными транзакциями.

4. Инструменты восстановления.

5. Инициирование, миграция и завершение выполнения транзакции.

В главе 1 обсуждается проблема распространения обновлений. Глава 2, за исключе­нием нескольких замечаний в самом ее конце, почти полностью посвящена вопросам предоставления прав доступа в нераспределенной системе (в стиле системы R). В главе 3 очень кратко рассматриваются вопросы инициирования, миграции и завер­шения выполнения транзакций, а также управления параллельностью и восстановле­нием. Глава 4 посвящена восстановлению, опять же, в нераспределенной системе. Наконец, в главе 5 более подробно обсуждается управление распределенными тран­закциями, в частности дается детальное описание протокола двухфазной фиксации.

20.29.Mohan С, Lindsay В. G. Effecient Commit Protocols for the Tree of Processes Model of Distributed Transaction // Proc. 2nd ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing. — 1983. См. комментарий к [20.39].

20.30. Newman S., Gray J. Which Way to Remote SQL? // DBP&D. — December, 1991. — 4, № 12. См. комментарий к [20.39].

20.31.Oszu M. Т., Valduriez P. Principles of Distributed Database Systems (2nd edition).— Englewood Cliffs, N.J.: Prentice-Hall, 1999.

20.32. Rennhackkamp M. Mobile Database Replication // DBMS. — October, 1997. — 10, № 11. Благодаря невысокой стоимости и портативности компьютеров, а также наличию беспроводных коммуникаций стало возможным появление систем распределенных баз данных нового типа, которые имеют свои специфические преимущества и не­достатки. В частности, данные в таких системах могут быть реплицированы бук­вально на тысячи "узлов", но эти узлы мобильны, часто отключаются, их операци­онные характеристики очень отличаются от характеристик обычных узлов (например, в стоимость соединений входит и использование аккумуляторных бата­рей, и время соединения) и т.д. Исследования таких систем начаты сравнительно недавно (см. [20.1], [20.21]). В этой краткой статье освещены некоторые принци­пиальные концепции и проблемы.

20.33.Rothnie J. В., Goodman N. A Survay of Research and Development in Distributed Database Management // Proc. 3rd Int. Conf. on Very Large Data Bases. — Tokyo, Japan, October, 1977. (Эта статья также опубликована в [20.4].) Очень полезный обзор следующих тем.

1. Синхронизация транзакций обновления.

2. Обработка распределенного запроса.

3. Управление при неисправностях компонентов.

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

5. Проектирование базы данных.

Последняя тема относится к проблеме физического проектирования, которая в раз­деле 20.8 называется проблемой размещения.

20.34.Rothnie J.B. et al. Introduction to a System for Distributed Databases (SDD-1) // ACM TODS. — March, 1980. — 5, № 1.

Работы [20.5], [20.6], [20.24], [20.34] и [20.40] связаны с ранним вариантом рас­пределенной системы SDD-1, которая работала на нескольких компьютерах PDP-10s фирмы DEC, подключенных к сети Arpanet. В этой системе обеспечивалась полная независимость от размещения, фрагментации и репликации. Ниже приво­дится несколько замечаний по поводу некоторых ее особенностей.

Обработка запросов. Оптимизатор запросов в системе SDD-1 (см. [20.5] и [20.40]) в значительной мере использует оператор полусоединения, который упоминался в гла­ве 6. Преимущество использования полусоединений при обработке распределенных запросов заключается в том, что они могут привести к сокращению объема данных, пересылаемых по сети. Предположим, например, что переменная-отношение по­ставщиков S хранится на узле А, переменная-отношение поставок SP — на узле В, а запрос формулируется следующим образом: "Определите результат соединения от­ношений поставщиков и поставок". Вместо того чтобы пересылать все отношение S на узел В, можно выполнить перечисленные ниже действия.

• Вычислить проекцию (TEMPI) переменной-отношения SP по атрибуту SI на уз­ле В.

• Переслать проекцию TEMPI на узел А.

• Вычислить полусоединение (ТЕМР2) проекции TEMPI и отношения S по атрибуту St на узле А.

• Переслать полусоединение ТЕМР2 на узел В.

• Вычислить полусоединение проекции ТЕМР2 и отношения SP по атрибуту S# на узле В. В результате будет получен ответ на сформулированный выше запрос.

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

size (TEMPI) + size (ТЕМР2) < size (S)

Здесь функция size() возвращает кардинальность отношения, указанного в качестве аргумента, умноженную на длину отдельного кортежа (скажем, в битах). Это позволяет оптимизатору оценивать размер промежуточных результатов типа TEMPI и ТЕМР2.

Распространение обновления. Алгоритмом распространения обновления в сис­теме SDD-1 предусматривается "немедленное распространение" (понятие первич­ной копии в ней не вводится).

Управление параллельностью. Управление параллельностью основано не на механизме блокировок, а на методе синхронизации с использованием времен-иых отметок. Цель выбора этого метода состоит в попытке избежать допол­нительных накладных расходов на отправку сообщений о блокировке, однако расплатой за это будет относительно небольшая степень параллельности! До­полнительные подробности в этой книге не приводятся, хотя в аннотации к [15.3] очень кратко описана основная идея. Более подробную информацию можно получить в [20.6] и [20.13].

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

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

20.35.Selinger P. G., Adiba М Е. Access Path Selection in Distributed Data Base Management Systems // S.M. Deen and P. Hammersley. Proc. Int. Conf. On Data Bases. — Aberdeen, Scotland; England: Heyden and Sons Ltd., 1980. См. комментарий к [20.39].

20.36.Stonebraker M. R., Neuhold E. J. Distributed Data Base Version of Ingres // Proc. 2nd Berkley Conf. On Distributed Data Management and Computer Networks. — Lowrence Berkley Laboratory, May, 1977.

Работы [20.17], [20.36] и [20.37] связаны с прототипом распределенной системы INGRES. Распределенная система Distributed Ingres состоит из нескольких копий программного обеспечения University Ingres, установленных и запущенных на не­скольких компьютерах PDP-1 Is фирмы DEC. Она поддерживает независимость от расположения (как в системах SDD-1 и R*), независимость от фрагментации, реп­ликацию данных для фрагментов и независимость от репликации. В отличие от систем SDD-1 и R* в системе Distributed Ingres не предполагается, что передача данных в сети обязательно должна быть медленной; наоборот, эта система спроек­тирована как для медленных сетей дальней связи, так и для сравнительно быстрых локальных сетей. Причем оптимизатор запросов может обнаружить разницу между двумя этими случаями. Алгоритм оптимизации запросов является расширением стратегии декомпозиции системы Ingres, описанной в главе 17. Более подробно он рассматривается в [20.17].

В системе Distributed Ingres обеспечиваются два алгоритма распространения об­новления: "эффективный" алгоритм, согласно которому обновляется первичная копия и управление возвращается данной транзакции (причем распространение обновлений выполняется параллельно с помощью набора подчиненных процес­сов), а также "надежный" алгоритм, согласно которому все копии обновляются од­новременно [20.37]. В обоих случаях управление параллельностью основано на механизме блокировки, а управление восстановлением — на протоколе двухфаз­ной фиксации (с некоторыми усовершенствованиями).

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

20.37. Stonebraker М. R. Concurency Control and Consistency of Multiple Copies in Distributed

Ingres // IEEE Transactions on Software Engineering. — May, 1979. — 5, № 3.

См. комментарий к [20.36]. 20.38,Wen-Syan Li and Clifton C. Semantic Integration in Heterogeneous Databases Using

Neural Networks // Proc. 20th Int. Conf. on Very Large Data Bases. — Santiago, Chile,

September, 1994.

20.39. Williams R. et al. R*: An Overview of the Architecture // P. Scheuermann. Improving Database Usability and Responsiveness. — New York, N.Y.: Academy Press, 1982. (Эта работа также опубликована в виде отчета: IBM Research RJ3325. — December, 1981.)

В работах [20.12], [20.29], [20.35] и [20.39] обсуждается система R*, которая яв­ляется распределенной версией системы System R. В системе R* обеспечивается независимость от расположения, но не поддерживаются фрагментация и репли­кация, а значит, не обеспечивается независимость от фрагментации и реплика­ции. По той же причине для данной системы не возникает вопрос о распростра­нении обновления. Управление параллельностью основано на механизме блоки­

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

20.40. Wong Е. Retrieving Dispersed Data from SDD-1: A System for Distributed Databases. (Опубликовано в [20.4].) См. комментарий к [20.34].

20.41.Yu С. Т., Chang С. С. Distributed Query Processing // ACM Сотр. Surv. — 1984. — 16, №4.

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

Глава

₂₁

Поддержка принятия решений