Метод двухфазного завершения гарантирует целостность распределенных транзакций, но при его реализации значительно возрастает сетевой трафик Если транзакция охватывает п систем, то для успешного завершения транзакции координатор должен послать и получить 4хп сообщений Причем эти сообщения будут отправлены помимо тех сообщений, посредством которых осуществляется передача инструкций SQL и результатов запросов между системами К сожалению, если к распределенной транзакции предъявляется требование обеспечения целостности базы данных в случае системных ошибок, то избежать подобного потока сообщений невозможно

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

Сетевые приложения и архитектура баз данных

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

Появление производительных серверов на базе UNIX (например, производства компании Sun) вызвало новую волну расширения и усовершенствования различных СУБД, которая привела к появлению архитектуры клиент/сервер, доминировавшей в сфере обработки корпоративных данных в конце 80-х и в 90-х годах В конце концов рост корпоративных сетей и появление крупномасштабных корпоративных приложений вызвали пофебность в новом уровне масштабируемости баз данных и новых эффективных технологиях для поддержки распределенной обработки данных Эту тенденцию усиливает рост популярности Internet, фебующий от баз данных невиданной ранее интенсивности фанзакций, из-за чего в последнее время активно развиваются технологии кэширования баз данных и размещения их в оперативной памяти

Приложения клиент/сервер

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

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

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

Под адиянием этих и других факторов и получила столь широкое распространение архитектура клиент/сервер (рис. 22.15). Многие современные приложения разработаны именно для нее. Важнейшую роль во взаимодействии между клиентской и серверной подсистемами играет SQL. Расположенное на ПК клиентское приложетгие направляет расположенной на сервере СУБД запросы в виде инструкций SQL. Ответы СУБД отправляются обратно по сети в виде кодов завершения или таблиц результатов запроса

Персональный компьютер

Прикладная программа......

Сервер баз данных

Инструкции SQL

СУБД Л

Результаты

База данных

Рис. 225.Архитектура клиенгсврввр

Приложения клиент/сервер с хранимыми процедурами

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

в ходе одной транзакции типичного OLTP-приложения обычно выполняется по меньшей мере десяток инструкций SQL. Например, для принятия заказа на один товар в нашей учебной базе данных приложение должно вьшолнить следующее:

получить идентификатор клиента по его имени (одиночная инструкция select);

получить лимит кредита этого клиента для проверки его платежеспособности (одиночная инструкция select);

получить информацию о товаре, такую как цена и количество на складе (одиночная инструкция select);

добавить в таблицу orders строку нового заказа (инструкция insert);

обновить информацию о товаре, чтобы отразить уменьшение его количества на складе (инструкция update);

обновить информацию о клиенте, чтобы отразить уменьшение лимита его кредита (инструкция update);

завершить всю транзакцию (инструкция commit).

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

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

Прикладная программа

Сервер баз данных

Вызов хранимой процедуры

СУБД

Хранимая процедура

Результаты

База данных

Рис 22.16. Архитектура клиент/сервер с хранимыми процедурами

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