Ю. А. Григорьев, Г. И. Ревунков - Банки данных

8. Тенденции развития систем распределенной обработки данных

Т а б л и ц а 8.1. Взаимосвязь бизнес-архитектуры и архитектуры информационных систем

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

160

операторов

Запрос к файлу Данные из файла

Рис. 8.1. Модель файлового сервера

На основе модели файлового сервера функционируют такие популяр­ ные СУБД, как FoxPro (Microsoft), dBase (Borland), Clipper (Nantucket Inc.), Paradox (Borland) и др.

Системы управления БД рассматриваемого класса стоят недорого, просты в установке и освоении. Но они обладают и рядом существенных недостатков:

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

эти СУБД не поддерживают распределенную обработку; в FoxPro, dBase, Clipper поддерживается стандарт Xbase.

Модель сервера базы данных

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

161

8. Тенденции развития систем распределенной обработки данных

Рис. 8.2. Модель сервера базы данных

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

В современных СУБД на сервере могут запускаться так называемые хранимые процедуры и триггеры, которые вместе с ядром СУБД образуют сервер СУБД. К хранимым процедурам можно обращаться из приложений на рабочих станциях. Это позволяет сократить размер кода ПП и уменьшить поток SQL-операторов с рабочей станции, так как группу требуемых SQLпредложений можно закодировать в хранимой процедуре. Триггеры — это программы, которые выполняются ядром СУБД перед или после обновле­ ния (UPDATE, INSERT, DELETE) таблицы БД; они позволяют автоматиче­ ски поддерживать целостность БД.

Модель сервера БД поддерживают следующие СУБД: Oracle, Sybase, Informix, Ingress, Progress и др., причем на первые три СУБД приходятся более 80 % рынка.

СУБД рассматриваемого класса имеют преимущества:

162

СУБД

EXEC SQL SELECT

EXEC SQL UPDATE

EXEC SQL INSERT

EXEC SQL DELETE

Рис. 8.3. Модель сервера приложений на базе менеджера транзакций

•системы, разработанные на основе этих СУБД, имеют высокую произ­ водительность, так как по шине передаются только SQL-запросы и результаты выполнения; запросы выполняются на высокоскоростных серверах;

•СУБД поддерживают распределенную обработку;

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

А также недостатки:

•они намного дороже СУБД предыдущего класса, сложны в освоении;

•для эффективной работы этих СУБД требуются высокоскоростные (а поэтому и дорогие) серверы и сети.

Модель сервера приложений

Сервер приложений можно организовать и с помощью хранимых процедур (см. рис. 8.2), но для реализации хранимых процедур используют языки высокого уровня (например, в Oracle — язык PL/SQL), поэтому про-

163

8. Тенденции развития систем распределенной обработки данных

граммы получаются ресурсоемкими. Причем возможности этих языков ог­ раничены: с их помощью нельзя организовать «тонкую» обработку данных на уровне битов. Хранимые процедуры также не поддерживают распреде­ ленные приложения, т.е. они не обеспечивают автоматический запуск тре­ буемой программы на другом сервере.

Для устранения указанных недостатков разработаны специальные средства, которые часто называют менеджерами транзакций, мониторами транзакций, OLTP-мониторами (Online Transaction Processing) (рис. 8.3).

В настоящее время наиболее популярен менеджер транзакций Tuxedo (ВЕА System). Он представляет собой оболочку, в рамках которой выпол­ няются сервисы (ПП), написанные на языке С. Tuxedo выполняет маршру­ тизацию запросов к сервисам, организует динамическое распределение на­ грузки и мультиплексирование запросов к БД. Часто менеджер транзакций и приложения запускаются на том же компьютере (хотя это не является обя­ зательным), где выполняется сервер СУБД, чтобы уменьшить поток SQLзапросов по сети.

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

В дальнейшем под сервером {S) будем понимать компьютер, где функционирует сервер БД и/или сервер приложений.

8.2. Архитектура современных распределенных СУБД

На рис. 8.4 представлена структура системы, где одновременно функ­ ционируют СУБД Oracle и Informix (эти СУБД взяты в качестве примера).

Доступ из Oracle к таблицам Informix и обратно осуществляется с по­ мощью шлюзов. Доступ к данным Oracle и Informix из Windows-приложе­ ний можно также организовать с помощью ODBC-драйверов (Open Data­ Base Connectivity) этих СУБД. Здесь для маршрутизации запросов к при­ кладным программам, выполняемым на разных серверах, используется ме­ неджер транзакций Tuxedo.

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

П е р е н о с и м о с т ь (портируемость — portability) — это такое раз­ деление программной системы и ее операционного окружения, которое по­ зволяет без существенных изменений перенести программу в другое опера­ ционное окружение.

Переносимость рассматривается в трех аспектах:

• возможность функционирования СУБД на множестве платформ;

164

8.2. Архитектура современных распределенных СУБД

Рис. 8.4. Пример структуры системы распределенной обработки данных

•качество коммуникационных средств, обеспечивающих связь клиен­ та и сервера способом, не зависящим ни от платформ клиента и сервера, ни от используемого сетевого протокола;

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

Первое касается собственно сервера СУБД, второе — организации взаимодействия клиента и сервера, третье — средств разработки приложе­ ний, поставляемых вместе с СУБД.

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

М е ж о п е р а б е л ь н о с т ь (interoperability) можно трактовать как свойство открытой системы, позволяющее встраивать эту систему как ком-

165

8. Тенденции развития систем распределенной обработки данных

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

Для СУБД это свойство может означать следующее:

•возможность приложений, созданных средствами разработки данной СУБД, оперировать над БД в «чужом» формате так, как будто это собствен­ ные БД;

•свойство сервера СУБД, позволяющее ему выступать менеджером ресурсов (resource manager) в системе обработки распределенных транзак­ ций (Distributed Transaction Processing — DTP);

•свойство СУБД, позволяющее ей служить поставщиком данных для любых приложений, созданных средствами разработки третьих фирм, под­ держивающих некоторый стандарт обращения к БД.

Первое свойство достигается двумя путями: использование шлюзов, ко­ торые представляют собой специальные средства доступа к унаследованным (legacy) БД; встраивание в средства разработки данной СУБД драйверов связи с другими системами. Шлюзы обычно включают в состав коммуникационных средств СУБД (см. рис. 8.4), и их можно рассматривать как расширение сервера СУБД, в то время как драйверы — атрибут средств разработки приложений. Второе свойство определяется поддержкой СУБД ХА-интерфейса стандарта Х/Ореп DTP, используемого в менеджерах транзакций. Наконец, третье свойст­ во достигается за счет поддержки коммуникационными средствами СУБД стандарта ODBC, разработанного специалистами корпорации Microsoft.

Р а с ш и р я е м о с т ь можно трактовать как возможность качествен­ ного наращивания функций сервера СУБД. Это свойство используется раз­ работчиками для следующих целей:

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

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

•для расширения спектра типов обрабатываемых данных, для инте­ грации в сервер возможностей обработки новых типов данных, характерных для ПО. Это обеспечивается сервером СУБД путем поддержки типов дан­ ных, определяемых пользователем (СУБД Ingres).

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

166

8.2. Архитектура современных распределенных СУБД

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

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

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

сустановленными на них серверами СУБД.

Ин т е р н а ц и о н а л и з а ц и я . Отметим здесь только некоторые важ­ ные аспекты СУБД, позволяющие говорить об их «интернациональных» возможностях:

•очень важно, сколько бит используется для представления символа. Вряд ли возможна нормальная локализация системы (адаптация к требованиям национальной информационной среды), если для представления символа отво­ дится семь бит. В профессиональных многопользовательских СУБД символ — это несколько байт, что дает возможность охватить практически весь спектр символов национальных алфавитов (включая иероглифы);

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

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

В гл. 13 приведены свойства некоторых крупных СУБД, подтверж­ дающие открытый характер этих систем.

167

8. Тенденции развития систем распределенной обработки данных

Intranet,

Internet

-Ж

Удаленный сервер СУБД

Рис. 8.5. Организация связи HTML-документов с базами данных

8.3. Распределенные базы данных и Internet

Для описания Web-страниц, отображаемых в окне Web-броузера, ис­ пользуются HTML-программы и Java-программы.

Web-броузер работает с HTML-программой (рис. 8.5). В настоящее время наиболее популярными продуктами, позволяющими работать с Webстраницами, являются Netscape Navigator (Netscape) и Microsoft Explorer (Microsoft). Эти продукты еще часто называют Web-броузерами.

Сначала по запросу Web-броузера из Web-сервера Internet читается HTML-форма (это HTML-программа, которая содержит описание полей

168

8.3. Распределенные базы данных и Internet

ввода для Web-страницы и имя CGI-программы для их обработки). Webброузер интерпретирует эту программу и выводит страницу на экран рабо­ чей станции. Пользователь должен заполнить поля ввода и нажать кнопку типа SUBMIT. Web-броузер пересылает Web-серверу имя CGI-программы обработки, имена полей ввода и их значения. Web-сервер, в свою очередь, используя интерфейс CGI (Common Gateway Interface), запускает CGIпрограмму, которая с помощью SELECT-запроса через ODBC-интерфейс читает данные из локальной или удаленной БД и с помощью оператора print генерирует новую HTML-программу, содержащую результаты поиска. Эта программа передается на рабочую станцию, где и интерпретируется Webброузером. Пользователь видит Web-страницу с данными, полученными из БД. В основном используются Web-серверы фирм Netscape и Microsoft: Net­ scape Communication Server (Unix) и Microsoft Internet Information Server (только под Windows NT). Фирма Novell также разработала свой Webсервер NetWare Web Server (только под NetWare 4.1 и 4.11).

Для написания CGI-программ для Web-серверов применяют языки Perl, С, TCL (Tool Command Language) и командный процессор Unix Bourne. Встречаются CGI-программы, написанные на Visual Basic, Access и на спе­ цифических языках (NetBasic для NetWare 4.11 Web Server, Basic для Net­ Ware 4.1 Web Server, PL/SQL для Oracle Web Server и т.д.)

Web-броузер работает с Java-программой, представленной на рис. 8.6, где приняты следующие обозначения:

1 — запрос к Web-серверу на чтение Java-программы (апплета). Webброузер инициирует загрузку апплета, когда при интерпретации HTMLпрограммы встречается следующий тег: <applet имя Java-мoдyля> </applet>; 2 — чтение из Web-сервера Java-программы в Web-броузер и запуск

Java-машины (интерпретатора Java-программы);

3 — в процессе выполнения Java-программы на рабочей станции она может через интерфейс JDBC (Java Data Base Connectivity) обращаться к удаленному серверу СУБД. Для этого JDBC подгружает и использует соот­ ветствующий ODBC-драйвер.

Большинство современных Web-серверов и Web-броузеров одновре­ менно поддерживают HTML- и Java-программы.

8.4. Примеры систем распределенной обработки данных

Пример структуры информационной системы крупного коммер­ ческого банка приведен на рис. 8.7.

Разработчиками проекта была выбрана архитектура клиент/сервер с использованием монитора транзакций Tuxedo. Общее распределение вы­ числительной нагрузки следующее: сервер приложений занимается ответст­ венными вычислительными задачами (быстрые транзакции, генерация отче­ тов, поддержка логической целостности базы данных, реализация алгорит-

169