🗊Презентация Модели «клиент-сервер» в технологии распределенных баз данных

1. Модель удаленного управления данными. Модель файлового сервера. 2. Модель удаленного доступа к данным. 3. Модель сервера баз данных.

Модели «клиент—сервер» в технологии баз данных

Структура типового интерактивного приложения, работающего с базой данных

Презентационная логика

Бизнес-логика

Логика обработки данных

Database Manager System Processing

Централизованная архитектура В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.

Распределение функций приложения в моделях «клиент -сервер»

Двухуровневые модели

Модель удаленного управления данными. Модель файлового сервера

Модель файлового сервера

Модель файлового сервера

Модель файлового сервера

Алгоритм выполнения запроса клиента в модели файлового сервера

Недостатки модели файлового сервера

Модель удаленного доступа к данным

Модель удаленного доступа к данным (RDA)

Обращение клиента за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызова специальной библиотеки API (Application Programming Interface –интерфейс прикладного программирования). Обращение клиента за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызова специальной библиотеки API (Application Programming Interface –интерфейс прикладного программирования).

Преимущества модели удаленного доступа

Модель удаленного доступа Основное достоинство RDA-модели — унификация интерфейса «клиент-сервер», стандартом при общении приложения-клиента и сервера становится язык SQL.

Недостатки модели удаленного доступа (RDA)

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

Модель активного сервера БД

Недостатки модели серверов БД

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

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

Клиент в модели сервера приложений

Серверы приложений

Серверы баз данных

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

Взаимодействие серверных и клиентских процессов в модели «один - к – одному»

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

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

Многопотоковая односерверная архитектура Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы. Такая архитектура называется многопотоковой односерверной («multi-threaded») и позволяет уменьшить нагрузку на операционную систему.

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

Но эта архитектура имеет недостатки, т.к. в систему добавляется новый слой, размещаемый между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов («load balancing») и ограничивает возможности управления взаимодействием «клиент-сервер». Но эта архитектура имеет недостатки, т.к. в систему добавляется новый слой, размещаемый между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов («load balancing») и ограничивает возможности управления взаимодействием «клиент-сервер». Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу; во-вторых, серверы становятся равноправными - нет возможности устанавливать приоритеты для обслуживания запросов.

Архитектура с виртуальным сервером

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

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

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

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

Горизонтальный параллелизм Существует несколько путей распараллеливания запросов. Параллелизм возникает тогда, когда хранимая в БД информация распределяется по нескольким физическим устройствам хранения — нескольким дискам. При этом информация из одного отношения разбивается на части по горизонтали. Этот вид параллелизма называют распараллеливанием или сегментацией данных. И параллельность здесь достигается путем выполнения одинаковых операций, например фильтрации, над разными физическими хранимыми данными. Эти операции могут выполняться параллельно разными процессами, они независимы. Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.

Выполнение запроса при горизонтальном параллелизме

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

Вертикальный параллелизм Действительно, если рассмотреть, например, последовательность операций реляционной алгебры: R5=R1 [ A,C] R6=R2 [A,B,D] R7 = R5[A > 128] R8 = R5[A]R6, то операции первую и третью можно объединить и выполнить параллельно с операцией два, а затем выполнить над результатами последнюю четвертую операцию. Общее время выполнения подобного запроса будет существенно меньше, чем при традиционном способе выполнения последовательности из четырех операций.

Гибридный параллелизм

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