Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

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

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

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

Приложения являются динамическим уровнем в этой модели. Они обеспечивают потенциально бесконечное множество интерфейсов, через которые люди, машины и внешние программные процессы взаимодействуют с клиентским процессом. В этой части клиентский модуль представляется приложениям через понятный, предпочтительно стандартизованный, независимый от языка программирования интерфейс прикладного программирования (Application Programming Interface, API).

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

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

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

Рис. 5.1 иллюстрирует классическую двухуровневую модель клиент-сервер. Промежуточный уровень, который может присутствовать или отсутствовать, представляет собой драйвер, такой как ODBC, JDBC, PHP, или компонент доступа к данным, который интегрирован с программным кодом приложения. Возможны и другие уровни на клиентской стороне. Приложения также могут быть написаны с использованием прямого доступа к API без промежуточного уровня.

Рис. 5.1. Двухуровневая модель клиент-сервер

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

Рис. 5.2. Многоуровневая модель клиент-сервер

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