Введение в системы БД (542480), страница 206
Текст из файла (страница 206)
(Если теперь на узле координатора произойдет сбой во время первой фазы фиксации транзакции, то после его перезапуска он сможет передать всем участникам сообщение "выполнить откат".) Необходимость физического ввода-вывода при обращении к журналу координатора таит в себе опасность для каждой транзакции. Поэтому схема предполагаемой фиксации не так заманчива, как могло показаться на первый взгляд. В действительности можно без преувеличения сказать, что ко времени написания данной книги схема предполагаемого отката стала фактическим стандартом в реализованных системах.
790 Часть и'. Дополнительные аспекты Управление параллельностью Как объяснялось в разделе 20.3, управление параллельным доступом в большинстве распределенных систем строится на использовании механизма блокирования, т.е, точно так, как и в большинстве не распределенных систем. Однако в распределенных системах запросы на проверку, установку и отмену блокировки становятся сообщениами (если считать, что рассматриваемый объект расположен на удаленном узле), а сообщения означают дополнительные накладные расходы. Рассмотрим, например, транзакцию Т, которой необходимо обновить объект, для которого существуют лубликаты на л удаленных узлах.
Если каждый узел отвечает за блокировку объектов, которые на нем хранятся (как предполагается в соответствии с принципом локальной независимости), то непосредственная реализация будет требовать по крайней мере 5л сообщений: л запросов на блокировку; л разрешений на блокировку; л сообщений об обновлении; л подтверждений; л запросов на снятие блокировки. Конечно, мы можем разумно воспользоваться, как и в предыдущем случае, "комбинированными" сообщениями. Например, можно объединить сообщение запроса на блокировку и сообщение об обновлении, а также сообщение о разрешении блокировки и сообщение о подтверждении.
Но даже в этом случае общее время обновления может быть на порядок больше, чем в централизованной системе. Для решения проблемы обычно выбирается стратегия первичной копии, схематически описанная выше, в разделе "Распространение обновлений". Для данного объекта й узел, содержащий первичную копию объекта Х, будет обрабатывать все операции блокировки для этого объекта (напомним, что первичные копии различных объектов будут в общем случае размещаться на различных узлах). При использовании этой стратегии набор всех копий объекта можно рассматривать как отдельный объект для блокировки, а общее количество сообщений будет сокращено с 5л до 2л+3 (один запрос блокировки, одно разрешение блокировки, п обновлений, л подтверждений и один запрос на снятие блокировки). Однако обратите внимание, что это решение влечет за собой серьезную потерю независимости — транзакция может теперь не завершиться, если первичная копия окажется недоступной, даже если в транзакции выполнялось лишь чтение и локальная копия была доступна.
(Отметим, что блокировка первичной копии требуется не только для операций обновления, но и для операций выборки 120.15). Таким образом, у стратегии первичной копии есть нежелательный побочный эффект — снижение уровня производительности и доступности как для выборки, так и для обновления.) Другая проблема, касающаяся блокировок в распределенных системах, состоит в том, что блокировка может привести к состоянию глобальной взаимной блокировки, охватывающей два и более узлов. Обратимся, например, к рис.
20,6. 1. Агент транзакции Т2 на узле Х ожидает, пока агент транзакции Т1 на узле Х отменит блокировку. 2. Агент транзакции Т1 на узле Х ожидает, пока агент транзакции Т1 на узле Х завершит транзакцию. Глава 20. Распределенные базы данных 791 3. Агент транзакции Т1 на узле Х ожидает, пока агент транзакции Т2 на узле У отменит блокировку. 4. Агент транзакции Т2 на узле У ожидает, пока агент транзакции Т2 на узле Х завершит транзакцию. Взаимная блокировка) Садт Х аа трапа ия ии Т2х Саят т Рис 20.б Пример состояния атобатьной взаимной блокировки 20.5.
Системы "клиент/сервер" Как отмечалось в разделе 20.1, системы "клиент)сервер" могут рассматриваться как частный случай распределенных систем в целом. Точнее, система "клиент/сервер*' — это распределенная система, в которой одни узлы — ктиенты, а другие — серверы; все данные размещены на узлах, которые являются серверами; все приложения выполняются на узлах-клиентах и "швы видны пользователю" (полная локальная независимость не предоставляется).
Обратимся к рис. 20.7 (или к рис. 2.5 из главы 2). 792 Часть (л дополнительные аспекты В состоянии глобальной взаимной блокировки, подобном только что рассмотренному, никакой узел не может обнаружить сиптуачию взаичной блокировки, используя лишь собственную внутреннюю информат)ию.
Иными словами, в локальном графе ожиданий нет никаких циклов и подобный цикл возникает только при обьединении локальных графов в обший глобальный граф. Поэтому при обнаружении состояния глобальной блокировки требуются дополнительные коммуникационные расходы, поскольку необходимо, чтобы отдельные локальные графы рассматривались вместе.
Изяшная (и распределенная) схема для определения состояния глобальной блокировки описана в статьях о системе йа (например, (20.39)). Зачечание. Как указывалось в главе 15, в действительности не все системы обнаруживают состояние взаимной блокировки — некоторые вместо этого просто используют механизм тайм-аута. По очевидным причинам данное замечание справедливо, в частности, и относительно распределенных систем. Прозрачный удаленный доступ ° Несколько клиентов могут совместно использовать один и тот же сервер (фактически это обычная практика). Рис.
20. 7. Система ° Отдельный клиент может иметь доступ к несколь- "клиент/сервер" ким серверам. Эта возможность, в свою очередь, делится на два случая. а) Клиент ограничен доступом лишь к одному серверу за один раз, т.е, каждый отдельный запрос к базе данных должен быть ориентированным на один сервер. Невозможно в пределах одного запроса получить данные с двух или более различных серверов. Более того, пользователь должен знать, на каком именно сервере хранятся те или иные части данных.
б) Клиент может иметь одновременный доступ к нескольким серверам, т.е, отдельный запрос может сочетать данные с нескольких серверов. А это означает, что несколько серверов представляются клиенту так, как будто это на самом деле один сервер. Пользователь не должен знать, какие части данных хранятся на каждом сервере.
Но в случае 6 фактически описан принцип системы распределенной базы данных (швы оказываются скрытыми). Это не совсем то, что обычно подразумевают под терми- ном "клиент/сервер*', поэтому мы данный случай рассматривать не будем. 4 Также по очевидным соображениям используется термин "двухуровневая система", в основном, с тем же смыслом. 793 Глава 20. Распределенные базы данных Во время написания этой книги повышенный коммерческий интерес проявлялся к системам "клиент/сервер" и сравнительно небольшой интерес — к настоящим распределенным системам общего назначения, хотя и начали возникать тенденции к изменению такого положения, в чем мы убедимся в следующем разделе. Мы по-прежнему считаем, что настоящие распределенные системы будут представлять важное перспективное направление, поэтому таким системам и уделено особое внимание в данной главе.
Но будет уместно рассказать кое-что и о системах "клиент/сервер". Напомним (см. главу 2), что термин "клиент/сервер" подразумевает, прежде всего, архитектуру, или логическое раз- ( Д деление обязанностей. Клиент — это приложение, которое также называют приложением переднеео плана (Тгопгепд), а сервер — это СУБД или приложение заднеео плана (Ьаскепд). Однако именно потому, что всю систему можно Компьютер Приложения так четко разделить на две части, появилась возможность выполнения ее частей на разных машинах. И эта возможность по многим причинам оказалась настолько заманчивой (см.
главу 2), что термин "клиент/сервер" на практике подразумевает исключительно случай, когда клиент и сервер действительно размещаются на разных машинах4. Хотя это и небрежное использование термина, однако оно широко распространено, и поэтому мы будем его придерживаться. Напомним, что возможны несколько вариантов основной схемы. Стандарты для систем "клиент/сервер" Существует несколько стандартов, имеющих отношение к системам "клиент/сервер".
° Прежде всего, определенные функции для поддержки систем "клиент/сервер** включены в стандарт языка БЯЬ, БОЬ/92 [4.22). Обсуждение этих возможностей мы отложим до раздела 20.7. ° Кроме того, имеется стандарт 1БО для удаленного доступа к данным (Кешоге Оага Асеева — КОА) (см. [20.26) и [20.27!). Этот стандарт важен еще и потому, что нечто близкое к нему уже реализовано членами группы БОЬ Асеева Сгоцр (БАР), которая представляет союз производителей программного обеспечения баз данных, принимающих идеи открытых систем и операционной совместимости. Замечание.
Для наших целей не стоит тратить время на перечисление различий между этими версиями стандарта удаленного доступа к данным. Мы будем использовать сокращенное название КОА для обшей ссылки на обе эти версии. Задача КОА — определить форматы и протоколы для соединений в среде "клиент/сервер". Подразумевается, что клиент формулирует запрос к базе данных в стандартной форме языка БЯЬ (по существу, это подмножество стандарта БЯЬ/92), а сервер поддерживает стандартный каталог (также, в основном, соответствующий требованиям стандарта БЯЬ/92). Стандарт КОА определяет конкретные форматы передаваемых сообщений (БОЬ-запросы, данные и результаты, диагностическая информация) между клиентом и сервером.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
