Подобный подход оказывается весьма эффективным, если соотношение запросов на выборку к запросам на изменение очень высоко (например, 95% составляют запросы на выборку и 5% - запросы на добавление, удаление или обновление). Если же процент запросов на изменение выше определенного предела, то издержки связанные с репликацией и разрешением конфликтов, могут свести на нет эффек! тивность всей системы в целом.

Повысить эффективность в такой ситуации можно, если распределять запросы на изменение, руководствуясь определенными правилами. Например, если реплицируется таблица клиентов, то первичным ключом в ней может быть имя клиента. Тогда программу распределения нагрузки можно написать так, что запросы на изменение данных о клиентах, чьи имена начинаются с букв от А до О, будут направляться одной системе, а запросы на изменение данных о клиентах, чьи имена начинаются с букв от П до Я, - другой. Это уменьшает вероятность возникновения конфликтов. Поскольку в данной схеме таблица по-прежнему целиком реплицируется во все системы, запросы на выборку можно произвольным образом распределять между системами для выравнивания нагрузки.

Доступ К распределенным базам данных

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

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

уровень

3. Распределенная транзакция

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

Описание

Каждая инструкция транзакции обращается к одной удаленной базе данных, но транзакция в целом может обращаться к нескольким базам данных

Инструкция SQL может обращаться к нескольким удаленным базам данных; транзакция, состоящая из нескольких инструкций, также может обращаться к нескольким базам данных

Модель компании JBM, состоящая из четырех уровней доступа, основана на простой формулировке задачи доступа к распределенным данным: пользователю, работающему с одной вычислительной системой, требуется получить доступ к данным, хранящимся в других вычислительных системах (одной или нескольких). Сложность распределенного доступа увеличивается на каждом последующем уровне. Таким образом, возможности СУБД можно охарактеризовать тем, какого уровня она достигла. Кроме того, на каждом уровне можно различать доступ только для выборки данных (посредством инструкции select) и доступ для изменения данных (посредством инструкций insert, delete и update). Часто в СУБД для некоторого уровня сначала вводится возможность только выборки данных и лишь впоследствии появляется поддержка как выборки, так и изменения данных.

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

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

Локальная система

Транзакция Транзакция Транзакция{ Транзакция

Удаленная система

Рис. 22.9. Доступ красирщешвнным данным: удаленные*запросы

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

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

Удаленные транзакции

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

Локальная система

Транзакция

Транзак1;ия

Инструкция

Инструкция

Инструкция

Инструкция

Удаленная система

СУБД

Удаленна,я система

СУБД

.pjfic. 22.10. Доступ кспредвпенным данный: удаленные транзакции