Распределенные базы данных

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

    Многие  поставщики СУБД предлагают программные  продукты, поддерживающие удаленные транзакции. Например, СУБД SQL Server можно отнести к приложениям архитектуры клиент/сервер благодаря тому, что в ней обеспечивается возможность выполнения удаленных транзакций, т.е. пользователь работает, к примеру, на персональном компьютере, а база данных расположена на сервере в ЛВС. Протокол ODBC фирмы Microsoft также поддерживает выполнение удаленных транзакций.

    Удаленные транзакции часто поддерживаются специальными шлюзовыми программами, связывающими СУБД разных типов. В частности, программа SQL*Net компании Oracle обеспечивает посредством использования шлюзов связь между Oracle и DB2, а также между Oracle и SQL/DS. Ingress обеспечивает аналогичные связи с DB2 и другими СУБД. Компания Sybase выпустила Open Server — интерфейс программирования приложений для SQL Server, который позволяет независимым поставщикам программного обеспечения разрабатывать шлюзовые программы для связи SQL Server с другими СУБД.

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

    Распределенные  транзакции

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

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

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

    Распределенные  транзакции поддерживаются, в частности, в СУБД Sybase и SQL Server, но в них вся тяжесть выполнения распределенной транзакции ложится на прикладную программу. Например, программа должна явным образом установить соединения с двумя СУБД SQL Server и послать соответствующие операторы SQL по каждому соединению. Когда наступает время завершить или отменить транзакцию, программа не посылает стандартный оператор commit или rollback, а использует специальный набор API-вызовов для синхронизации завершения транзакции в обеих СУБД. Хотя данная схема обеспечивает полную поддержку распределенных транзакций (включая распределенные обновления), она подверглась критике за недостаточную прозрачность.

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

    Последним уровнем доступа к распределенным данным в модели IBM является распределенный запрос, схема выполнения которого показана на рис. 20.5. На этом уровне один оператор SQL может обращаться к таблицам из двух или более баз данных, расположенных в различных вычислительных системах. СУБД отвечает за автоматическое выполнение оператора во всех участвующих системах. Последовательность операторов, представляющих собой распределенные запросы, может быть объединена в транзакцию. Как и на предыдущем уровне, СУБД должна гарантировать целостность распределенной транзакции во всех участвующих системах.

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

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

    В конечном счете, на уровне распределенных запросов главная цель — сделать так, чтобы вся распределенная база данных выглядела для пользователя как одна большая база данных. В идеальном случае пользователь имел бы полный доступ к любой таблице распределенной базы данных и мог бы выполнять транзакции SQL, ничего не зная о физическом местоположении данных. К сожалению, этот "идеальный" вариант в реальных сетях оказывается нежизнеспособным. Число таблиц распределенной базы данных в сети любого размера быстро стало бы очень большим, и пользователи обнаружили бы, что невозможно найти интересующие их данные. К тому же пришлось бы координировать идентификаторы пользователей во всех базах данных на предприятии, чтобы каждый идентификатор пользователя был уникальным во всех базах данных. Администратору базы данных также было бы очень трудно выполнять свою работу.

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

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

    Распределенные  таблицы

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

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

    Горизонтальное  разделение таблиц

    Распределить  таблицу по сети можно следующим  образом: разделить таблицу горизонтально, помещая разные строки таблицы в различные системы. На рис. 20.6 изображен простой пример, когда требуется горизонтальное разделение таблицы. Здесь компания имеет три оптовых склада со своими вычислительными системами, в каждой из которых располагается СУБД и база данных товарных запасов. Деятельность каждого оптового склада в основном связана с локально хранимыми данными, но компания проводит следующую политику: если на каком-нибудь складе требуемый товар отсутствует, то заказ клиента удовлетворяется из запасов любого другого оптового склада.

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

    Горизонтально разделенные таблицы требуют  значительных изменений в СУБД и ее логике оптимизации. Рассмотрим три запроса к таблице products, которые выполняются в Нью-Йорке:

• Вывести на экран список всех товаров производства компании ACI, имеющихся на нью-йоркском оптовом складе.

    SELECT *

    FROM PRODUCTS

    WHERE LOCATION = 'New York' AND MFR_ID = 'ACI'

• Вывести на экран список всех товаров производства компании ACI, имеющихся на чикагском оптовом складе.

    SELECT *

    FROM PRODUCTS

    WHERE LOCATION = 'Chicago' AND MFR_ID = 'ACI'

• Вывести на экран список всех товаров производства компании ACI.

    SELECT *

    FROM PRODUCTS WHERE MFR_ID = 'ACI'

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

    Обновление  базы данных также должно выполняться  в СУБД особым образом. Например, когда СУБД выполняет следующий оператор insert:

    INSERT INTO PRODUCTS (MFR_ID, PRODUCT_ID, LOCATION, ...) VALUES ('ACI', '41004', 'New York', ...)

    она должна определить, в какой системе следует хранить новую строку. Далее, когда выполняется такое обновление строки:

    UPDATE PRODUCTS

    SET LOCATION = 'Chicago' WHERE MFR_ID = 'ACI' AND PRODUCT = '41004'

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