Централизованная архитектура

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

 

Рисунок 3.2 ─ Место СУБД в централизованной архитектуре

 

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

 

Архитектура файл/сервер

Появление персональных компьютеров и локальных вычислительных сетей привело к разработке архитектуры файл/сервер (рис. 3.3). При такой архитектуре приложение, выполняемое на персональном компьютере, может получить “прозрачный” доступ к файловому серверу, на котором хранятся совместно используемые файлы. Когда приложению, работающему на ПК, требуется получить данные из такого файла, сетевое программное обеспечение автоматически считывает требуемый блок данных с сервера. Архитектура файл/сервер поддерживалась первыми СУБД для персональных компьютеров, такими как dBASE и позднее Microsoft Access, при этом на каждом ПК работала своя копия СУБД.

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

 

 

Рисунок 3.3 ─ Место СУБД в архитектуре файл/сервер

 

Архитектура клиент/сервер

 

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

 

 

Рисунок 3.4 ─ Место СУБД в архитектуре клиент/сервер

 

Давайте снова вернемся к примеру с вычислением средней стоимости заказа. В архитектуре клиент/сервер запрос передается по сети на сервер баз данных в виде SQL-запроса. Ядро базы данных на сервере обрабатывает запрос и просматривает базу данных, которая также расположена на сервере. После вычисления результата ядро базы данных посылает его обратно по сети клиентскому приложению, которое отображает его на экране персонального компьютера.

Архитектура клиент/сервер позволяет сократить сетевой трафик и распределить процесс загрузки базы данных. Функции работы с пользователем, такие как обработка ввода и отображение данных, выполняются на персональном компьютере пользователя. Функции работы с данными, такие как дисковый

ввод/вывод и выполнение запросов, выполняются сервером баз данных. Наиболее важно здесь то, что SQL обеспечивает четко определенный интерфейс между клиентской и серверной системами, эффективно передавая запросы на доступ к базе данных.

Преимущества данной архитектуры обеспечили ей большую популярность к
середине 90-х годов. Все ведущие СУБД — Oracle, Informix, Sybase, SQL Server, DB2 и многие другие — стали предлагать клиент-серверные возможности Многие компании начали выпускать средства разработки приложений клиент/сервер.

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