Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

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

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 78 / 168 9 10 11 12 13 14 15 16 > Следующая >>>

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

Для обеспечения оптимизации запроса по времени его выполнения введены параметры, указывая которые, пользователь определяет поведение алгоритмов работы с «медленными» ИД [43]. Параметр DSTimeout указывает максимально допустимое время ожидания данных от источника данных в миллисекундах. Параметр FullResult позволяет пользователю указать, насколько желательным является получение канонического ответа (опрос всех ИД). Алгоритмы обработки запроса предполагают существование периодически обновляемого списка недоступных ИД. Задавая параметр FullResult=1, пользователь указывает, что время отклика ИД его не интересует, но допустимо игнорировать ИД, о недоступности которых известно. Указывая параметр FullResult=2, пользователь указывает, что необходимо попытаться опросить все ИД, даже отмеченные ранее как недоступные. По умолчанию считается, что FullResult=0, при этом на основе имеющейся статистики выполняется примерная оценка времени

извлечения информации. Если ожидаемое время извлечения информации из некоторого ИД превышает DSTimeout, то этот ИД не используется при формировании ответа.

Ожидаемое время извлечения информации оценивается следующим образом. Пусть P – явный предикат в запросе пользователя, отображаемый на отношение R подсоединенного источника данных D. Пусть Q – запрос (выраженный на языке РА) к отношению R, который предполагается выполнить для извлечения информации, необходимой для формирования ответа на пользовательский запрос. Запрос Q строится таким образом, что он содержит только одно обращение только к одному отношению (select-project запрос). Тогда размер ответа на запрос Q - s(Q) – будет равен , где S(Q) –селективность запроса, T(s,Q) - оценка размера представления Q, учитывающая операции проекции и добавления. Считается, что проекция атрибутов

сохраняет часть информации объемом , а операция

добавления атрибута A (R ADD A AS A1) добавляет к ответу порцию размером , где

— количество строк в отношении R, - множество атрибутов отношения R, — размер отношения R. При этих условиях время получения ответа

на запрос Q оценивается как , где –

пропускная способность канала до ИД D, а – задержка канала.

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

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

Предложенные алгоритмы предполагают «отсечение» некоторых ИД, то есть исключают обращение ним, если считают его нецелесообразным ввиду того, что прогнозируемое время запроса к таким ИД превышает установленное ограничение на время получения ответа на запрос. В работах [27,44] предлагается отсечение ИД согласно ограничениям, наложенным администратором СИД, но не по ожидаемому времени выполнения запроса к ИД. Описываемые выше алгоритмы исключают из рассмотрения ИД ввиду недоступности, или исходя из оценки времени извлечения информации. Отсечение ИД по времени получения ответа на запрос может быть применено в большем количестве случаев, так как характеристики информации, предоставляемой отдельным ИД далеко не всегда строго определены.

2.3.3. Оптимизированный метод выполнения запросов

Метод непосредственного выполнения запросов не позволяет оптимизировать пути доступа к данным ИД. Для достижения

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

Основное отличие предложенного метода от метода непосредственного выполнения запросов состоит в том, что в данном случае выполнение запроса разделяется на стадию подготовки (генерации плана выполнения запроса) и на собственно стадию выполнения запроса по данному плану [2] .

Обработка запросов выполняется в несколько шагов, включающих:

1) составление плана доступа к данным (ПДД);

2) оптимизацию ПДД;

3) создание плана выполнения запроса на основе ПДД;

4) выполнение запроса согласно плану.

ПДД представляет собой список ИД и SQL запросов к этим ИД, используемых при определении явных предикатов, фигурирующих в запросе пользователя. При оптимизации ПДД значительно уменьшается количество обращений к ИД. Это происходит за счет того, что при наличии множества обращений к одинаковым представлениям одних и тех же ИД различные запросы могут быть объединены. То есть, выполняется объединение совокупности запросов типа r PROJECT a,b WHERE условие1 и r PROJECT b,c WHERE условие2 в запрос r PROJECT a,b,c WHERE условие1 OR условие2.

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

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

обеспечения возможности параллельного выполнения подзапросов нами введено понятие группы операций (ГО). ГО - это множество операций по извлечению и преобразованию данных, которое нужно выполнить для формирования ответа на подзапрос в обрабатываемом выражении РА, такое что все операции группы могут выполняться параллельно. ГО не может включать вложенных ГО, но может иметь зависимости от других групп. При обработке дерева операций выражения РА к одной ГО относятся операции выборки информации из отношений различных ИД, соответствующих одному отношению в запросе и операции выборки информации из отношений, связанных операцией UNION. При этом обработка дерева операций выражения РА осуществляется сверху вниз, слева направо. По умолчанию для корня дерева создается текущая ГО. Если очередная рассматриваемая вершина дерева соответствует операции РА обращения к отношению, то к текущей ГО добавляются некоторые операции по извлечению или преобразованию данных. Если очередная рассматриваемая вершина дерева соответствует операциям JOIN, MINUS или TIMES, то происходит генерация двух новых ГО, текущая ГО помечается как зависимая от данных ГО, и новые ГО становятся текущими для всех вершин левого и правого поддерева обрабатываемой вершины соответственно. Если очередная рассматриваемая вершина дерева соответствует операции UNION, то текущая ГО остается прежней и происходит обработка поддеревьев рассматриваемой вершины. Отметим, что упоминаемые при описании способа обработки вершин дерева операции MINUS и TIMES здесь рассматриваются только для общности, предлагаемые методы обработки запросов никогда не приводят к генерации данных операций.

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

неполного ответа на запрос. Показатель устойчивости к сбоям определяется при построении ГО в процессе обхода дерева операций выражения РА. При создании ГО ее показатель устойчивости к сбоям полагается равным 0. Если очередная рассматриваемая вершина дерева соответствует операции обращения к отношению R, и данное отношение R отображается на n ИД, к показателю устойчивости текущей ГО добавляется значение n-1. При обработке вершин дерева операций выражения РА, соответствующих операциям UNION, показатель устойчивости текущей ГО увеличивается на единицу.

Между ГО во время построения плана запроса формируются зависимости, которые определяют порядок выполнения операций. Зависимости формируются естественным образом на основе древовидной структуры выражения запроса, общих операций доступа к данным и определений рекурсивных предикатов в запросе пользователя. При этом выполнение ГО, соответствующих отдельным подвыражениям, является обязательным для выполнения включающего их выражения РА (например, перед выполнением группы операций, соответствующей операции, включающей оператор JOIN запроса, необходимо выполнить группы операций, соответствующие аргументам оператора JOIN). В ходе выполнения запроса отслеживается количество сбоев, имевших место при выполнении ГО. Если в какой-либо ГО зафиксировано количество сбоев, превышающее показатель ее устойчивости к сбоям, данная ГО помечается как сбойная. При этом количество сбоев зависимых ГО увеличивается на единицу. Кроме того, в целях оптимизации, все группы, от которых зависит данная ГО, но не зависят другие несбойные ГО, также помечаются как сбойные, так как их дальнейшее выполнение бессмысленно.

Стоит отметить, что от одной ГО может зависеть несколько других групп (это верно для групп, содержащих операции выборки данных, обращение к которым происходит в нескольких независимых подвыражениях одного выражения РА). Пусть, например, ГО A

зависит от ГО C и D, а ГО B зависит от группы D (см. рис. 2.5, стрелки показывают зависимости между ГО и ориентированы от источника зависимости к зависимой ГО). Тогда при сбое в ГО C группа A помечается как сбойная, но на группу D сбой не распространяется (так как в противном случае сбой перекинется на ГО B, которую еще можно обработать). Если бы ГО B не зависела от ГО D, то группу D можно было бы пометить как сбойную, так как ее исполнение тогда было бы бессмысленным.

Рис. 2.5. Пример зависимостей между группами операций

Рассмотрим применение описанных методов оптимизации при обработке следующего запроса. Пусть в глобальной схеме определены предикаты emps(empName,email, age,degree), jobs (jobTitle, empName, dptName, subDept), dpts(dptName, address, email), jh(jobTitle, dptName, empName, beginDate, endDate), которые описывают сотрудников подразделений (факультетов и НИИ) университета, их должности и подразделения, в которых они работают. Предикат jh (job history) описывает, что сотрудник с именем empName работал в должности jobTitle в подразделении университета deptName начиная с даты beginDate и по дату endDate. Запрос на языке РА, выбирающий названия кафедр и подразделения, в которых когдалибо работали доктора технических наук, будет выглядеть следующим образом (см. рис. 2.6).

emps JOIN jh JOIN dpts WHERE degree=”д.т.н.” {dptName,subDept} UNION emps JOIN jobs JOIN dpts WHERE degree=”д.т.н.” {dptName,subDept}

Рис. 2.6. Запрос, выбирающий названия кафедр и подразделений

Пусть отношения, на которые отображается предикат dpts, находится в основной БД университета (назовем ее BASE), jobs и

emps - в БД подразделений (назовем их ), а отношение, на которое отображается предикат jh (для тех подразделений, где соответствующее отношение поддерживается) находится в архивах университета (БД ARCH). Пусть существует n БД , тогда план выполнения данного запроса будет выглядеть следующим образом (рис. 2.7).

Рис. 2.7. План выполнения запроса, представленного на рис. 2.6

На рисунке все ГО помечены названиями операций РА, с которыми они соотносятся, а операции извлечения информации — именами таблиц, на которые они отображаются. Стрелки показывают зависимости между операциями и ГО. Они направлены от операции или ГО, необходимой для выполнения другой ГО, к зависимой группе. В скобках после названий операций РА указаны показатели устойчивости к сбоям для данной ГО. Если при обработке данного запроса будет недоступна БД ARCH, то невозможно будет выполнить операцию #JH. Сбой распространится на все ГО в левой части рисунка 2.7. Это увеличит количество сбоев ГО, соответствующей

операции UNION выражения РА, на 1. Но так как ее устойчивость к сбоям равна 1, то на ГО в правой части рисунка сбой не распространится. Пусть также k<n БД подразделений будет недоступно. Тогда количество сбоев в ГО, помеченных как «EMPS» достигнет k. Но так как k<=n-1, то данные группы операций будут выполнены. Пользователю будет возвращен результат, основанный только на данных БД BASE и тех БД , которые были доступны в момент выполнения запроса. Ответ будет помечен как неполный. Стоит отметить, что при выполнении запроса часть операций, помеченных как «#EMPSi» и «#JOBSj» может выполняться параллельно (степень параллельности зависит от количества ИД

и настроек СИД).

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

Примером применения подобных способов оптимизации может служить обработка запросов следующего типа (рис. 2.8).

Предположим, что отношения departments и employees, используемые в запросе, отображаются на отношения различных ИД. Тогда, если количество сотрудников велико, а отделов достаточно мало, то выгодной является следующая стратегия обработки запроса. Вначале происходит выборка информации о различных подразделениях из ИД, в которых содержится такая информация. Затем выполняется следующий запрос к ИД с информацией о сотрудниках: employees PROJECT deptName, name RENAME name AS empName WHERE deptName IN (:deptNames), где deptNames извлеченные ранее названия имеющихся подразделений. Таким образом, извлекается информация только о сотрудниках интересующих подразделений.

(departments PROJECT name RENAME name AS deptName WHERE locationId='RU' JOIN employees PROJECT deptName, name RENAME name AS empName) PROJECT empName,deptName

Рис. 2.8. Пример запроса: соединение отношений departments и

employees

Для оценки целесообразности подобной оптимизации следует выполнить следующие оценки [3]. Пусть ожидаемое время выборки левой части операции JOIN - LTT (left transfer time). Пусть ожидаемое время выборки правой части операции JOIN - RTT (right transfer time). Пусть количество различных значений атрибута для каждого из атрибутов, по которым проходит соединение - LDN (left distinct number) и RDN (right distinct number). Пусть TTA — время, необходимое, чтобы передать атрибуты, по которым происходит соединение из БД центральной СУБД в ИД, на данные которых отображается отношение, указанное в левой части соединения. Тогда при выполнении условия LDN>C*RDN, (где C — константа, определяющая поведение данного алгоритма, которая может задаваться, например, администратором СИД или в качестве параметра запроса пользователя) и условия RTT+LTT*RDN/LDN+TTA<RTT+LTT, целесообразно обработать

<<< < Предыдущая 1 2 3 4 5 6 78 / 168 9 10 11 12 13 14 15 16 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]