Раздел 6. Интегрированные информационные технологии
Тема 19. Интеграция информационных ресурсов и систем
Распределённые системы обработки данных
Основные условия и требования к распределённой обработке данных
Такая отличительная особенность БД, как многоцелевое параллельное использование данных, предопределяет наличие средств, обеспечивающих практически одновременный и независимый доступ к одним и тем же данным. Причём сама база может быть размещена на одном или нескольких компьютерах.
Ведущими поставщиками СУБД сформулированные следующие свойства «идеальной» системы управления распределёнными БД:
●Прозрачность относительно расположения данных: СУБД должна представлять все данные так, как если бы они были локальными.
●Гетерогенность системы: СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью (независимость от СУБД).
●Прозрачность относительно сети: СУБД должна одинаково работать в условиях разнородных сетей.
●Поддержка распределенных запросов: пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах.
●Поддержка распределенных изменений: пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах.
●Поддержка распределенных транзакций: СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети.
●Безопасность: СУБД должна обеспечивать защиту всей распределённой БД от несанкционированного доступа.
●Универсальность доступа: СУБД должна обеспечивать единую методику доступа ко всем данным.
Однако, ни одна из существующих СУБД не достигает этого идеала вследствие следующих практических проблем:
•Низкая и несбалансированная производительность сетей передачи данных, что в распределённых транзакциях сильно снижает общую производительность обработки.
•Обеспечение целостности данных в распределённых транзакциях базируется на принципе «всё или ничего» и требует
385
специального протокола двухфазного завершения транзакций, что приводит к длительной блокировке изменяемых данных.
•Необходимо обеспечить совместимость данных стандартного типа, для хранения которых в разных системах используются разные физические форматы и кодировки.
•Выбор схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удалённый доступ будет замедлен. Если будет размножен – то изменения придётся распространять и синхронизировать.
•Необходимо обеспечить совместимость СУБД разных типов и поставщиков.
•Увеличение потребностей в ресурсах для координации работы приложений с целью обнаружения и устранения тупиковых ситуаций в распределённых транзакциях.
Именно указанные причины определили на практике частичность и «этапность» введения в СУБД тех или иных возможностей распределённой обработки данных. В простейшем случае пользователь имеет возможность обращаться по сети к записям в БД, размещённым на других компьютерах. В других случаях СУБД сама производит аутентификацию удалённого клиента и устанавливает сетевые соединения.
В общем случае режимы работы с БД можно классифицировать по следующим признакам:
•многозадачность – однопользовательский или многопользовательский;
•правило обслуживания запросов – последовательное или параллельное;
•схема размещение данных – централизованная или распределённая БД.
Следует отметить, что общая тенденция развития технологий обработки данных вполне соответствует этапам развития средств вычислительной техники и информационных технологий, и в первую очередь – сетевых. В этом смысле следует выделить два класса:
системы распределённой обработки данных и системы распределённых баз данных.
Системы распределённой обработки данных в основном отражают структуру и свойства многопользовательских ОС с БД, размещённой на большом центральном компьютере (мэйнфрейме). Ещё до недавнего времени это был единственно возможный вариант вычислительной среды для реализации больших БД. Клиентские места в этом случае реализовались в виде терминалов или мини-ЭВМ, обеспечивающих в основном ввод-вывод данных и не имеющих собственных
386
вычислительных ресурсов для функционально-ориентированной обработки получаемых данных.
Развитие сетевых технологий в сочетании с широким распространением персональных ЭВМ и внедрением стандартов открытых систем привело к появлению систем баз данных, размещённых в сети разнотипных компьютеров. Такие системы распределённых баз данных обеспечивают обработку распределённых запросов, когда при обработке одного запроса используются ресурсы базы, размещённые на различных ЭВМ сети. Система распределённых БД состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что БД любого узла будет доступна пользователю, так как если бы она была локальной.
Соответственно, программы, обеспечивающие целевую (функциональную) обработку данных, могут быть организованы таким образом, чтобы обеспечить более эффективное использование совокупных вычислительных ресурсов за счёт специализированного разделения функций обработки между центральным процессом СУБД и клиентскими функционально-ориентированными процедурами.
Для «типового» приложения обработки данных можно выделить следующие группы (уровни) функций:
•ввод и отображение данных: внешний (пользовательский) уровень реализации целевой функциональной обработки и представления (Presentation logic);
•функциональная обработка, реализующая алгоритм решения задач пользователя. Соответствующие «бизнес-правила» реализуются обычно средствами высокоуровневого языка программирования или расширенного языка манипулирования данными типа ADABAS Natural
или 4-GL (Business logic);
•манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (Database logic);
•управление данными и другими ресурсами БД, реализуемое специализированными (внутренними) средствами конкретной СУБД обычно в рамках файловой системы ОС;
•управление процессами обработки: связывание и синхронизация процессов обработки данных разного уровня.
Архитектура распределенной обработки данных
Почти все модели организации взаимодействия пользователя с БД, построены на основе модели «клиент-сервер». Т.е. предполагается, что каждое такое приложение отличается способом распределения функций ранее приведённых групп обработки данных между как минимум двумя частями:
• клиентской, отвечающей за целевую обработку данных и организацию взаимодействия с пользователем;
387
• серверной, обеспечивающей хранение данных – обрабатывает запросы и посылает результаты клиенту для специальной обработки.
В общем случае предполагается, что эти части приложения функционируют на отдельных компьютерах, т.е. к серверу БД с помощью сети подключены компьютеры пользователей (клиенты).
Сервер – программа, реализующая функции собственно СУБД: определение данных, запись-чтение данных, поддержка схем внешнего, концептуального и внутреннего уровней, диспетчеризация и оптимизация выполнения запросов, защита данных.
Клиент – различные программы, написанные как пользователями, так и поставщиками СУБД, внешние или «встроенные» по отношению к СУБД. Программа-клиент организована в виде приложения, работающего «поверх» СУБД, и обращающегося для выполнения
операций над данными к компонентам СУБД через интерфейс внешнего уровня24.
Разделение процесса выполнения запроса на «клиентскую» и «серверную» компоненту позволяет:
•различным прикладным (клиентским) программам одновременно использовать общую БД;
•централизовать функции управления, такие, как защита информации, обеспечение целостности данных, управление совместным использованием ресурсов;
•обеспечивать параллельную обработку запроса в случае распределенных БД;
•высвобождать ресурсы рабочих станций и сети;
•повышать эффективность управления данными за счёт использования ЭВМ, специально разработанных для работы СУБД (серверы баз данных и машины баз данных).
Базовые архитектуры распределенной обработки
Учитывая, что одним из основных показателей эффективности сетевой обработки данных является время обслуживания запроса, рассмотрим различные модели архитектуры распределённой обработки на примере, когда прикладная программа работы с БД, расположенной на сервере, загружена на рабочую станцию, и пользователю необходимо получить все записи, удовлетворяющие некоторым поисковым условиям.
Архитектура «файл-сервер»
24 Инструментальные средства, в том числе и утилиты, не отнесены к серверной части очень условно. Являясь не менее важной составляющей, чем ядро СУБД, они выполняются самостоятельно, как пользовательское приложение.
388
В архитектуре «файл-сервер», схема которой представлена на Рис. 19-1, средства организации и управления БД (в том числе и СУБД) целиком располагаются на машине клиента, а БД, представляющая собой обычно набор специализированных структурированных файлов, – на машине-сервере. В этом случае серверная компонента представлена даже не средствами СУБД, а сетевыми составляющими операционной системы, обеспечивающими удалённый разделяемый доступ к файлам. Таким образом, «файл-сервер» представляет вырожденный случай клиент-серверной архитектуры.
Рис. 19-1. Архитектура «файл-сервер»
Взаимодействие между клиентом и сервером происходит на уровне команд ввода-вывода файловой системы, которая возвращает запись или блок данных. Запрос к базе, сформулированный на языке манипулирования данными, преобразуется самой СУБД в последовательность команд ввода-вывода, которые обрабатываются операционной системой машины-сервера.
Достоинство - возможность обслуживания запросов нескольких клиентов.
Недостатки:
•высокая загрузка сети и машин-клиентов, т.к. обмен идёт на уровне единиц информации файловой системы – физических записей, блоков или даже файлов, из которых на машине клиента будут выбраны
ипредставлены необходимые для приложения элементы данных;
•низкий уровень защиты данных, т.к. доступ к файлам БД управляется общими средствами ОС сервера;
•низкий уровень управления целостностью и непротиворечивостью информации, т.к. бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми и несихронизированными.
В среде файлового сервера программа управления данными, которая выполняется на машине-клиенте, должна осуществить запрос
389
каждой записи базы, после чего она может определить, удовлетворяет ли запись поисковым условиям, лишь после этого передать для функциональной обработки. Очевидно, что для этой схемы характерно наибольшее суммарное время обработки информации.
390
Архитектура «выделенный сервер базы данных»
В архитектуре сервера БД, схема которого представлена на Рис. 19-2, средства управления базой данных и БД размещены на машинесервере.
Взаимодействие между клиентом и сервером происходит на уровне команд языка манипулирования данными СУБД (обычно SQL), которые обрабатываются СУБД на машине-сервере. Сервер базы данных осуществляет поиск записей и анализирует их. Записи, удовлетворяющие условиям, могут накапливаться на сервере и после того, как запрос будет целиком обработан, пользователю на клиентскую машину передаются все логические записи (запрашиваемые элементы данных), удовлетворяющие поисковым условиям.
Рис. 19-2. Архитектура с выделенным сервером базы данных
Достоинства:
•возможность обслуживания запросов нескольких клиентов;
•снижение нагрузки на сеть и машины сервера и клиентов;
•защита данных осуществляется средствами СУБД, что позволяет блокировать неразрешенные пользователю действия;
•сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей.
Недостатки:
•бизнес-логика функциональной обработки и представление данных могут быть одинаковыми для нескольких клиентских приложений, и это увеличит совокупные потребности в ресурсах при исполнении – повторение части кода программ и запросов;
•низкий уровень управления непротиворечивостью информации, т.к. бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми.
Данная технология позволяет снизить сетевой трафик и повысить общую эффективность обработки за счёт оптимизации и буферизации ввода-вывода. Т.о., сервер может осуществить поиск и обрабатывать
391
запросы даже быстрее, чем, если бы они обрабатывались на рабочей станции.
Архитектура «активный сервер баз данных»
Для того чтобы устранить недостатки, свойственные архитектуре сервера базы данных необходимо, чтобы непротиворечивость бизнеслогики и изменения БД контролировались на стороне сервера. Причём некоторые, заранее специфицированные состояния могли бы изменять последовательность взаимодействия приложения с БД.
Для этого функции бизнес-логики разделяются между клиентской и серверной частью. Общие или критически значимые функции оформляются в виде хранимых процедур, включаемых в состав БД. Кроме этого, вводится механизм отслеживания событий БД – триггеров, также включаемых в состав базы. При возникновении соответствующего события (обычно изменения данных), СУБД вызывает для выполнения хранимую процедуру, связанную с триггером, что позволяет эффективно контролировать изменение БД.
Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с БД. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса (Рис. 19-3).
Рис. 19-3. Архитектура «активный сервер баз данных»
Недостатком такой архитектуры становится существенно возрастающая загрузка сервера за счёт необходимости отслеживания событий и выполнения части бизнес-правил.
Такую архитектуру организации взаимодействия и рассматриваемый далее сервер приложений иногда называют моделью с «тонким клиентом», в отличие от предыдущих архитектур, называемых моделью с «толстым клиентом», где на стороне клиента выполняется большинство функций.
392