9.Распределенная обработка данных в кис

РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ

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

В состав системы управления РБД должны входить следующие компоненты:

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

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

3. коммуникационные устройства, система управления РБД не должна зависеть от коммуникаций, то есть должна поддерживать несколько типов коммуникационных устройств

4. процессор транзакций(transactionprocessorTP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где выполняется запрос данных.TPназывают также менеджером транзакций (transaction manager TM)

5. процессор данных(dataprocessorDP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где хранятся и извлекаются данные.DPтакже называют менеджером данных (datamanagerDM). Процессор данных может представлять собой централизованную СУБД

Связь между DP и TP поддерживается протоколами. Протоколы определяют то, как система РБД:

1. организует интерфейс с сетью передачи данных и команд между DP и ТP

2. синхронизирует все данные, полученные от DP (сторона TP) и маршрутизирует полученные данные на соответствующие TP (сторона DP)

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

Процессоры DP и TP могут размещаться на одном и том же компьютере, позволяя конечным пользователям получать доступ к локальным и глобальным данным, не заботясь об их местонахождении

Для распределенных баз данных свойственны следующие характеристики:

1. РБД – это логически связанные, разделяемые на некоторое количество фрагментов, данные

2. фрагменты распределяются по разным узлам, связанные между собой сетевыми коммуникациями

3. в обязательном порядке предусмотрена репликация фрагментов

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

Основные требования к распределенной обработке данных:

1. прозрачность относительно расположенияданныхСУБД должна представлять все данные так, как, если бы они были локальными

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

3. прозрачностьотносительносетиСУБД должна одинаково работать в условиях разнородных сетей

4. поддержка распределенных запросовпользователь должен иметь возможность работать с данными из любых баз, даже если они размещены в разных подсистемах

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

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

7. безопасность СУБД должна обеспечивать защиту всей распределенной БД от НСД

8. универсальность доступа СУБД должна обеспечивать единую методику доступа ко всем данным

10. Распределенный запрос в РБД КИС

РАСПРЕДЕЛЕННЫЙ ЗАПРОС

Распределенный запрос позволяет получить данные из разнородных источников, то есть от нескольких узлов DP (процессор данных). Для однократного выполнения распределенного запроса используют динамическое подключение к серверу-источнику данных (путем вызова специального контактного запроса с использованием функций opendatasource или opendataset). Как правило, для многократного выполнения распределенного запроса используют технологию связанного (или прилинкованного) сервера. Это простой и эффективный способ объединения серверов РБД.

Выполнение запроса начинается с его компиляции. Рассмотрим общую схему распределенной компиляции.

Будем называть главным узлом тот узел сети, в котором инициирован процесс компиляции предложения SQL, и дополнительными узлами - те узлы, которые вовлекаются в этот процесс в ходе его выполнения. На самом низком уровне процесс компиляции можно разбить на следующие фазы:

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

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

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

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

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

1. времени доступа при выполнении операций ввода/вывода физических данных на диске

2. коммуникаций передачи данных между узлами в системе РБД

3. нагрузки CPU (центрального процессора)

Хотя затраты часто разделяют на коммуникационные затраты и затраты на обработку, на самом деле их очень трудно отделить друг от друга. Не все алгоритмы оптимизации используют одинаковые параметры и не все алгоритмы присваивают одинаковые веса этим параметрам. Например, некоторые алгоритмы минимизируют общее время, другие - время коммуникаций, а третьи не принимают в расчет время работы CPU, считая эти затраты незначительными по сравнению с другими расходами. Чтобы оценить оптимизацию запроса, следует понимать, что процессор транзакций TP должен получить данные от процессора данных DP, синхронизировать их, скомпоновать ответ и предоставить его конечному пользователю или приложению. Хотя этот процесс является стандартным, необходимо учитывать, что запрос может выполняться на нескольких узлах. Время отклика узлов не всегда легко определить, поскольку некоторые узлы могут выполнить свою часть запроса быстрее других.

Большинство алгоритмов оптимизации запросов основаны на двух принципах:

1. выбор оптимального порядка выполнения

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

На основе этих двух принципов алгоритм оптимизации можно оценить по режиму его работыилирасчетному времени оптимизации.

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

По времени выполнения оптимизации алгоритмы подразделяются настатическиеидинамические.

Статическая оптимизация запроса выполняется во время компиляции. Такой подход применяется в том случае, если SQL-операторы встроены в процедурный язык программирования. Когда программа передается СУБД для компиляции, создается план доступа к БД. При выполнении программы СУБД использует этот план для доступа к БД.

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

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

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

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