Конструирование репликационных схем в системе документооборота вуза Текст научной статьи по специальности «Компьютерные и информационные науки»

КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

УДК 681.3

КОНСТРУИРОВАНИЕ РЕПЛИКАЦИОННЫХ СХЕМ В СИСТЕМЕ ДОКУМЕНТООБОРОТА ВУЗА

© 2007 г. Г.В. Сучков, В.Н. Кухарев

Введение

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

Конструирование множества состояний системы

Проанализируем процесс функционирования системы документооборота вуза. Выделим два основных типа клиентов (рис. 1): клиенты, формирующие шаблоны документов, которые далее хранятся на выделенном сервере - хранилище шаблонов, и клиенты -потребители, которые занимаются вводом - выводом документов в системе (отделы бухгалтерии, кадров, финансового планирования и другие).

Создание шаблонов документов будем рассматривать как отдельную замкнутую сеть массового обслуживания, содержащую т док клиентов, формирующих шаблоны документов с индивидуальными интенсив-ностями X; док для каждого '-го клиента и образующих суммарную интенсивность X сум к серверу шаблону документов Рдок.

Сервер в случае возможности передачи шаблона в хранилище передает его туда с вероятностью Рст, Х'док, а в случае несоответствия шаблона внутренним стандартам с вероятностью Рвд обрабатывает

запрос самостоятельно. Аналогично вышеприведенным вероятностям направлений запросов вводятся вероятности для других фрагментов системы: Рмод -

вероятность, что сотрудникам отдела шаблонов необходимо будет модифицировать созданные ранее шаб-

лоны; Рвд - вероятность успешной обработки запроса клиентов отдела формирования шаблонов на внутреннем сервере подразделения; Ршкд - вероятность передачи шаблона документа на сервер корпоративного доступа; Ршцв - вероятность передачи шаблона документа к подразделениям центрального вуза; Рдцв -

вероятность передачи готового документа к подразделениям центрального вуза; Ркдш - вероятность передачи шаблона документа в хранилище шаблонов с сервера корпоративного доступа; Ркхд - вероятность

передачи документа в хранилище документов с сервера корпоративного доступа; Рдб - вероятность передачи информации от подразделения бухгалтерии центрального вуза к хранилищам документов и шаблонов; Рдк - вероятность передачи информации от подразделения отдела кадров центрального вуза к хранилищам документов и шаблонов; Рдб,ф , Рдк,ф, Рдфп,ф -

соответственно вероятности передачи информации от подразделений бухгалтерии, отдела кадров, отдела финансового планирования филиала вуза к серверу доступа филиала; Робв, Рокв, Рфпв - вероятности

успешной обработки запроса на внутренних серверах подразделений в центральном вузе; Робв,ф, Рокв,ф,

P.

фпв,ф

- вероятности успешной обработки запроса на

внутренних серверах подразделений филиала вуза; Рдфв - вероятность передачи информации от филиала

к серверу корпоративного доступа в центральном вузе; Рвд,ф - вероятности успешной обработки запроса подразделений филиала вуза на сервере доступа филиала; Рдкд - вероятность передачи информации из

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

Полная траектория движения шаблона документа от создания до клиентов - потребителей представлена знаками . Траектория движения документа от его создания на основе шаблона до клиентов - потребителей для головного вуза представлена знаками , а для филиала знаками о.

Хранилище

Рис. 1. Концептуальная модель документооборота информационной системы

Моделирование репликационной схемы в системе документооборота

При разработке модели учтем, что первичные данные (а соответственно и менеджеры, журналы транзакций и центральные репозитории) находятся в хранилищах шаблонов и документов, физически расположенных в центральном вузе. Филиалы посредством собственных репликационных серверов производят периодическое асинхронное обновление данных (в первую очередь это относится к наиболее часто используемым шаблонам и документам - формату приказов, объявлений, командировочных удостоверений и др.).

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

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

Хранилище шаблонов

Хранилище документов

Корпоративный сервер

1 филиал 2 филиал к-й филиал

Подразделения центрального _вуза_

Рис. 2. Распределение реплик по типу «звезда»

Хранилище шаблонов

Корпоративный сервер

Хранилище документов

Представленная схема «звезда» характеризуется минимальной вероятностью возникновения конфликтов, в схеме «многие ко многим» конфликты носят более сложный характер.

Смоделировав данные схемы (рис. 2, 3) в среде ОРББ, можно заметить, что процесс обновления реплик данных в случае применения схемы «звезда», подразумевающего существование отдельных линий связи (включая Интернет) между центральным вузом и филиалами, требует высокой надежности и быстродействия от корпоративного сервера.

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

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

Анализ результатов решения

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

ЗС1770&-МЕЗСот Switch SuperStack 3 Switch 4950 4060 (с модулями расширения)

Рис. 3. Распределение реплик по типу «многие ко многим»

Рис. 4. Принятие решений по установке нового коммутатора и сервера: 1 - допустимость времени ожидания в среднем; 2 - допустимость распределения времени; 3 - допустимость

потерь

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

На основе данной диаграммы (по данным для системы документооборота ЮРГТУ) рекомендуется замена текущего коммутатора центрального узла 3Com 4900SX на более мощный из аналогичного ряда. Однако следует учитывать, что данная диаграмма описывает модельные ситуации, конкретный выбор в пользу того или иного сервера требует практических испытаний.

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

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

Выводы

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

10 декабря 2006 г.

tab_blk_cnt(tab,cnt) - cnt - количество блоков в таблице tab;

col_blk_cnt(tab,col,val,cnt) - cnt - количество блоков, занимаемых строками таблицы tab, в которых столбец col имеет значение val;

tab_row_cnt(tab,cnt) - cnt - количество строк в таблице tab;

que_row_cnt(que,tab,cnt) - запрос que выбирает cnt строк из таблицы tab;

low_selectivity(que,col) - запрос que обладает низкой избирательностью по столбцу col; greater(y,x) - x больше y;

table_disorg(tab,col) - таблица tab дезорганизована по столбцу col;

query_column(col,que) - столбец col задействован в ограничениях запроса que;

percent(y,x) = x/y - функция, определяющая, каков процент от y занимает x.

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

ytabBcntl (tab _ row _ cnt (tab, cntl) л

A3que3col3cnt2 (que _ row _ cnt (que, tab,cnt2) л

лquery _ column (col, que) л

л greater (0.08, percent (cntl, cnt 2)) —

— low _ selectivity (que, col))), (l)

Южно-Российский государственный технический университет (Новочеркасский политехнический институт)

УДК 681.3

РЕАЛИЗАЦИЯ РАССУЖДЕНИЙ В ЭКСПЕРТНОЙ СИСТЕМЕ ДИАГНОСТИКИ СУБД

© 2007 г. Т.В. Коломиец, М.П. Малыхина