Главная » Microsoft SQL Server, Базы данных » Архитектуры доступа к данным

0

Прежде всего, SQL Server является сервером баз данных. Сама по себе СУБД не может удовлетворить потребности конечного пользователя (если, конечно, не рассматривать редактор запросов как интерфейс пользователя). Если вы мало знакомы с моделью “клиент/сервер”, ее нужно понять, в противном случае будет сложно понять и саму СУБД.

Модель баз данных “клиент/сервер”

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

Поколения SQL Server

Рис. 3.1. SQL Server 2005— более чем обновленная версия продукта. Учитывая такое множество совершенно новых архитектурных решений, эту систему можно назвать платформой баз данных третьего поколения

Термин клиент/сервер затрагивает многие аспекты вычислений. Файловые серверы, серверы печати и поставщики служб Интернета (провайдеры) — это примеры реализации модели “клиент/сервер”. Файловые серверы открывают доступ пользователю к файлам, серверы печати обрабатывают запросы к принтерам, а провайдеры обслуживают запросы к службам Интернета. В базах данных архитектуры “клиент/сервер” сервер баз данных обслуживает запросы к базе от клиентского процесса.

Базы данных архитектуры “клиент/сервер”

В противоположность настольным базам данных, таким как Microsoft Access, выполняющим всю работу на компьютере клиента, базы данных с архитектурой “клиент/сервер” подобны библиотекарю, который принимает запрос клиента, ищет запрошенную информацию и возвращает фотокопию найденных материалов. Содержащиеся в библиотеке реальные материалы никогда не выходят из поля зрения библиотекаря.

В базах данных с архитектурой “клиент/сервер” клиент подготавливает запрос на языке SQL (небольшое текстовое сообщение) и отсылает его на сервер баз данных, который читает и обрабатывает его (рис. 3.2). В сервере поддерживается система безопасности, индексируются хранящиеся материалы, заносятся и обрабатываются данные, выполняются серверные программы, и выполняется доставка результатов запросов клиенту.

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

Рис. 3.2. База данных с архитектурой “клиент/сервер” выполняет всю работу на сервере

Клиент-серверная модель базы данных обладает рядом преимуществ по сравнению с настольной моделью.

?               Повышена достоверность данных, поскольку они не разбросаны по всей сети и разным приложениям. Данные обслуживает только один процесс.

?               Ограничения целостности данных и бизнес-правила могут поддерживаться на уровне сервера, в результате чего они строго соблюдаются.

?               Повышена базопасность данных, поскольку база данных хранит их в пределах одного сервера. Открыть файл данных, защищаемый сервером, гораздо сложнее, чем файл на рабочей станции.

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

?               В значительной мере сокращаются сетевые потоки. По сравнению с сетевыми потоками, создаваемыми многопользовательскими настольными системами, потоки в архитектуре “клиент/сервер” можно сравнить с одиноким мотоциклистом, несущимся по свободной 10-полосной автостраде. Без преувеличения! Замена перегруженной настольной системы базой данных “клиент/сервер” способна сократить сетевые потоки больше чем на 95%.

?               Снижение сетевых потоков в системах “клиент/сервер” приводит к тому, что приложения хорошо работают даже в распределенной среде и даже при наличии медленных соединений. Такие маленькие сетевые потоки позволяют уравнять в производительности локальную сеть со скоростью 100 Мбит/с с модемным подключением со скоростью 56 Кбит/с для клиентских приложений, использующих .NET-технологии и подключенных к базе данных SQL Server.

Роли в архитектуре “клиент/сервер”

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

Сервер баз данных отвечает за следующее:

?               обработка запросов на извлечение и модификацию данных;

?               интенсивная обработка данных;

?               поддержание всех правил и ограничений базы данных;

?               поддержание безопасности базы данных.

Клиентский процесс отвечает за следующее:

?               представление данных пользователю в понятном и удобном формате;

?               обеспечение интерфейса пользователя всевозможными инструментами, данными и отчетами;

?               отправку запросов серверу.

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

Многоуровневая архитектура

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

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

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

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

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

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

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

Архитектура, ориентированная на службы

Архитектура, ориентированная на службы (SOA), является альтернативой клиент-сервер- ной архитектуре. Вместо программирования прикладного интерфейса “клиент/сервер” между несколькими системами, SOA использует стандартные вызовы HTTP и XML, позволяя множеству систем взаимодействовать с одной, используя один и тот же интерфейс.

Архитектура SOA может оказаться полезной на крупных предприятиях с несколькими особо большими системами, но за такую масштабируемость приходится платить. Данные проходят несколько уровней, и при этом выполняется их преобразование. Интерфейс конечного пользователя, использующий SOA, будет испытывать недостаток производительности по сравнению с прямым подключением в архитектуре “клиент/сервер” с использованием библиотеки ADO.NET.

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

Когда же лучше использовать Web-службы SOA? Они больше подходят в качестве вторичного метода доступа к данным для облегчения взаимодействия с другими особо крупными системами. За исключением этих случаев старайтесь не использовать SOA.

Развертывание хранилищ данных SOA с применением SQL Server 2005 облегчается при использовании новых функций концевых точек HTTP. Более подробно этот вопрос мы обсудим в главе 32.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии