Транзакция т1х

Ожидает снятия блокировки Lx транзакцией Т1х

Транзакция Т2х

Ожидает завершения транзакции Т1у

Ожидает завершения транзакции Т2х

Транзакция Т1х

Ожидает снятия блокировки Ly транзакцией Т2у

Транзакция Т2х

Удерживает блокировку Ly

СайтУ

Рис 20.6 Пример состояния глобальной взаимной блокировки

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

Изящная (и распределенная) схема для определения состояния глобальной блокиров- ки описана в статьях о системе R* (например, [20.39]).

Замечание. Как указывалось в главе 15, в действительности не все системы обнару- живают состояние взаимной блокировки — некоторые вместо этого просто используют механизм тайм-аута. По очевидным причинам данное замечание справедливо, в частно- сти, и относительно распределенных систем.

20.5. Системы "клиент/сервер"

Как отмечалось в разделе 20.1, системы "клиент/сервер" могут рассматриваться как частный случай распределенных систем в целом. Точнее, система "клиент/сервер" — это распределенная система, в которой одни узлы — клиенты, а другие — серверы; все дан- ные размещены на узлах, которые являются серверами; все приложения выполняются на узлах-клиентах и "швы видны пользователю" (полная локальная независимость не пре- доставляется). Обратимся к рис. 20.7 (или к рис. 2.5 из главы 2).

Во время написания этой книги повышенный коммерческий интерес проявлялся к системам "клиент/сервер" и сравнительно небольшой интерес — к настоящим распреде- ленным системам общего назначения, хотя и начали возникать тенденции к изменению такого положения, в чем мы убедимся в следующем разделе. Мы по-прежнему считаем, что настоящие распределенные системы будут представлять важное перспективное на- правление, поэтому таким системам и уделено особое внимание в данной главе. Но будет уместно рассказать кое-что и о системах "клиент/сервер".

_□

Компьютер клиента

Прозрачный удаленный доступ

Компьютер сервера

Напомним (см. главу 2), что термин "клиент/сервер" под- разумевает, прежде всего, архитектуру, или логическое раз- деление обязанностей. Клиент— это приложение, которое также называют приложением переднего плана (frontend), а сервер— это СУБД или приложение заднего плана (backend). Однако именно потому, что всю систему можно так четко разделить на две части, появилась возможность вы- полнения ее частей на разных машинах. И эта возможность по многим причинам оказалась настолько заманчивой (см. главу 2), что термин "клиент/сервер" на практике подра- зумевает исключительно случай, когда клиент и сервер дей- ствительно размещаются на разных машинах¹³. Хотя это и не- брежное использование термина, однако оно широко распро- странено, и поэтому мы будем его придерживаться.

Напомним, что возможны несколько вариантов основ- ной схемы.

• Несколько клиентов могут совместно использовать один и тот же сервер (фактически это обычная практика).

• Отдельный клиент может иметь доступ к несколь- ким серверам. Эта возможность, в свою очередь, делится на два случая.

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

б) Клиент может иметь одновременный доступ к нескольким серверам, т.е. отдельный запрос может сочетать данные с нескольких серверов. А это оз- начает, что несколько серверов представляются клиенту так, как будто это на самом деле один сервер. Пользователь не должен знать, какие части данных хранятся на каждом сервере.

Но в случае б фактически описан принцип системы распределенной базы данных (швы оказываются скрытыми). Это не совсем то, что обычно подразумевают под терми- ном "клиент/сервер", поэтому мы данный случай рассматривать не будем.

Стандарты для систем "клиент/сервер"

Существует несколько стандартов, имеющих отношение к системам "клиент/сервер".

• Прежде всего, определенные функции для поддержки систем "клиент/сервер" включены в стандарт языка SQL, SQL/92 [4.22]. Обсуждение этих возможностей мы отложим до раздела 20.7.

• Кроме того, имеется стандарт ISO для удаленного доступа к данным (Remote Data Access — RDA) (см. [20.26] и [20.27]). Этот стандарт важен еще и потому, что нечто близкое к нему уже реализовано членами группы SQL Access Group (SAG), которая представляет союз производителей программно- го обеспечения баз данных, принимающих идеи открытых систем и операци- онной совместимости.

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

Задача RDA— определить форматы и протоколы для соединений в среде "клиент/сервер". Подразумевается, что клиент формулирует запрос к базе данных в стандартной форме языка SQL (по существу, это подмножество стандарта SQL/92), а сервер поддерживает стандартный каталог (также, в основном, соот- ветствующий требованиям стандарта SQL/92). Стандарт RDA определяет кон- кретные форматы передаваемых сообщений (SQL-запросы, данные и результаты, диагностическая информация) между клиентом и сервером.

■ Третий, и последний, стандарт, который мы здесь упоминаем, — стандарт ар- хитектуры распределенных реляционных баз данных (Distributed Relational Database Architecture — DRDA), предложенный компанией IBM [20.25] (он яв- ляется стандартом де-факто, но не де-юре). Стандарты DRDA и RDA имеют много общего, однако стандарт DRDA отличается от стандарта RDA во многих важных отношениях. В частности, в стандарте DRDA явно проявляется тенден- ция к отражению его происхождения в компании IBM. Например, в стандарте DRDA клиент необязательно должен использовать стандартную версию языка SQL и разрешено применение какого бы то ни было диалекта языка SQL. След- ствием этого, возможно, является повышение производительности, поскольку клиенту разрешается использовать некоторые специфические возможности сер- вера. Но, с другой стороны, этот подход снижает возможности переносимости, поскольку подобные специфические функции не являются скрытыми от клиен- та, т.е. клиенту известно, с каким типом сервера он соединен. Аналогично этому в стандарте DRDA допускается использование любых конкретных особенностей структуры каталога сервера. Форматы и протоколы DRDA существенно отли- чаются от форматов стандарта RDA. По существу, стандарт DRDA базируется на собственной архитектуре и собственных стандартах IBM, в то время как стандарт RDA основывается на международных стандартах, независимых от конкретных поставщиков.

Более подробно эти стандарты в настоящей книге не рассматриваются. (См. [20.23] и [20.30], где приводится их сравнительный анализ.)

Программирование приложений "клиент/сервер"

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

Замечание. Согласно этому простому определению, конечно, узел клиента вовсе не явля- ется "узлом системы баз данных" в полном смысле этого понятия, и такая система противоре- чит определению систем распределенных баз данных общего назначения, которое было дано в разделе 20.2. (Узел клиента может иметь собственную локальную базу данных, однако такие базы данных не имеют непосредственного отношения к системе "клиент/сервер" как таковой.)

Но, как бы там ни было, подход "клиент/сервер" имеет определенные особенности с точки зрения программирования (как и распределенные системы в целом). На одну из таких особен- ностей мы уже указывали при обсуждении распределенной обработки запросов в разде- ле 20.3, а именно— на то, что реляционные системы по определению и по построе- нию являются системами, в которых данные обрабатываются на уровне множеств. В систе- мах "клиент/сервер" (как и в распределенных системах в целом) чрезвычайно важно то, что программист, пишущий приложение, не просто "использует сервер как некоторый метод дос- тупа" и пишет код обработки на уровне записей. Функциональность приложения в как можно большей степени должна быть увязана с запросами на уровне множеств. В противном случае неизбежны существенные потери в производительности системы, связанные с передачей слишком большого количества сообщений. (В терминах языка SQL предыдущее высказыва- ние означает, что требуется в как можно большей степени избегать использования курсоров, т.е. циклов с оператором FETCH и форм CURRENT для операций UPDATE и DELETE. См. главу 4.)

Количество сообщений между клиентом и сервером может быть сокращено еще больше, если система предоставляет в распоряжение пользователя некоторый механизм поддержки хранимых процедур. Хранимые процедуры представляют, по существу, предварительно откомпилированные программы, которые хранятся на узле сервера (и известны серверу). Клиент обращается к хранимой процедуре с помощью механизма вы- зова удаленных процедур (remote procedure call — RPC). Поэтому, в частности, потери в производительности, связанные с обработкой данных на уровне записей, могут быть частично компенсированы за счет создания подходящих хранимых процедур, позволяю- щих выполнить обработку данных непосредственно на узле сервера.

Замечание. Хотя это и не имеет прямого отношения к теме обработки данных в сис- темах "клиент/сервер", необходимо отметить, что более высокая производительность — это не единственное преимущество, которое предоставляют хранимые процедуры. Назо- вем и другие преимущества хранимых процедур.

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

• Одна хранимая процедура может совместно использоваться многими клиентами.

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

■ Хранимые процедуры позволяют обеспечить более высокую степень безопасности данных. Например, некоторому пользователю может быть разрешено вызывать определенную процедуру, но не разрешено непосредственно обрабатывать дан- ные, к которым он может иметь доступ через эту хранимую процедуру.

Недостатком хранимых процедур является то, что поставщики программного обеспе- чения предоставляют в этой области слишком отличающиеся между собой средства, а расширение языка SQL для поддержки хранимых процедур появилось, к сожалению, лишь в 1996 году. Как указывалось в главе 4, это средство называется Persistent Stored Modules (PSM — постоянные хранимые модули).