тест по распределенкам. Лекция 01. Основные принципы построения распределенных информационных систем Скворцов С. Е. 15 января 2019

• Название: Лекция 01. Основные принципы построения распределенных информационных систем Скворцов С. Е. 15 января 2019
• Анкор: --1785
• Дата: 27.01.2023
• Размер: 1.13 Mb.
• Имя файла: тест по распределенкам.docx
• Тип: Лекция; #907922
• страница: 2 из 4

Лекция № 02. Архитектура распределенной обработки данных

 Скворцов С.Е.

 

 15 января 2019

 

 Просмотров: 258

 Empty

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

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

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

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

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

Разделение процесса выполнения запроса на «клиентскую» и «серверную» компоненту позволяет:

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

Базовые архитектуры распределенной обработки

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

Архитектура «Файл-сервер»

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

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



Рисунок 1 - Архитектура «файл-сервер»

Достоинство - возможность обслуживания запросов нескольких клиентов.

Недостатки:

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

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

 

Архитектура «Выделенный сервер базы данных»

В архитектуре сервера базы данных, схема которой представлена на рисунке 2, средства управления базой данных и база данных размещены на машине-сервере.

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



Рисунок 2 - Архитектура с выделенным сервером базы данных

Достоинства:

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

Недостатки:

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

 

Архитектура «Активный сервер баз данных»

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

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

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

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

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



Рисунок 3 - Архитектура «активный сервер баз данных»

Архитектура «Сервер приложений»

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

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



Рисунок 4 - Архитектура сервера приложений

К другим (организационно-технологическим) достоинствам трехзвенной архитектуры можно отнести:

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

Архитектура сервера баз данных

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

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

Рассмотрим архитектуры, реализующие следующие модели совместной обработки клиентских запросов.

Архитектура «один к одному»

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

Рисунок 5 - Архитектура сервера «один к одному»

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

Обработку всех клиентских запросов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами (рисунок 6). При этом для отдельного клиентского процесса создается поток, (thread) в рамках которого локализуется обработка запроса.

Рисунок 6 - Многопотоковая односерверная архитектура

Мультисерверная архитектура

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



Рисунок 7 - Многопотоковая односерверная архитектура

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

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

Серверные архитектуры с параллельной обработкой запроса

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

1. 
   Размещение хранимых данных БД на нескольких физических носителях (сегментирование базы). Для обработки запроса в этом случае запускаются несколько серверных процессов (использующих обычно отдельные процессоры), каждый из которых независимо от других выполняет одинаковую последовательность действий, определяемую существом запроса, но с данными, принадлежащими разным сегментам базы. Полученные таким образом результаты объединяются и передаются клиенту. Такой тип распараллеливания называют моделью горизонтального параллелизма.
   
2. 
   Запрос обрабатывается по конвейерной технологии. Для этого запрос разбивается на взаимосвязанные по результатам подзапросы, каждый из которых может быть обслужен отдельным серверным процессом независимо от обработки других подзапросов. Получаемые результаты объединяются согласно схеме декомпозиции запроса и передаются клиенту. Такой тип распараллеливания называют моделью вертикального параллелизма.
   

Примерная схема обработки клиентского запроса, построенная с использование обеих моделей параллелизма (гибридная модель) приведена на рисунке 8.

Рисунок 8 - Архитектура сервера обработки запроса при гибридном параллелизме

Использование моделей параллельной обработки позволяет существенно сократить общее время обслуживания запроса, что особенно важно в случае работы с большими базами данных и аналитической обработки (OLAP-приложений).