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

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

В качестве платформы для NauDoc был выбран Web-сервер приложений Zope, разрабатываемый в рамках лицензии ZPL 2.0 (Zope Public License). Данная лицензия совместима с GPL и поддерживает как коммерческое, так и некоммерческое использование программы. Также, специально для проекта NauDoc, была разработана лицензия Naumen Public License (www.OpenSource.org/licenses/naumen.php), прошедшая проверку в Open Source Initiative. Цель такой проверки заключается в определении соответствия лицензии идеологии открытых исходных кодов.

На сегодняшний день сообщество Zope включает в себя сотни компаний и тысячи разработчиков по всему миру, что упрощает взаимодействие всех участников проекта, позволяя децентрализовать создание ресурсоемких процедур. Например, за счет открытости платформы Zope и системы NauDoc локализация выявленной проблемы снижения быстродействия, возникающей при определенных операциях, была проведена силами самих заказчиков. При этом для проведения нагрузочного и стресс-тестирования использовался инструментарий OpenSTA. Для выявления процедур, которые могут переводить систему в неработоспособные режимы, был использован инструмент Deadlock Debugger, разработанный Zope-сообществом. Непосредственно решение проблемы было выполнено группой, состоящей из сотрудников компании Naumen и заказчика, – предложена гибридная система хранения, в которой одновременно используются объектная и реляционная базы данных. Первая служит для хранения объектов СЭД, а вторая содержит таблицы индексов для разных классов объектов. При такой организации хранения данных для поиска совокупности объектов по запросам различной сложности может быть использован оптимизированный механизм поиска реляционных СУБД. Дальнейшая проработка задачи позволила подобрать готовый компонент ZSQLCatalog, позволяющий организовать гибридное хранение данных.

Особенности реализации

Разработка Web-приложений для сервера Zope ведется при помощи высокоуровневого инструментария на основе объектно-ориентированного языка с множественным наследованием Python.
В качестве хранилища объектов используется объектная база данных ZODB, предназначенная для прозрачного и постоянного хранения Python-объектов. При этом объектно-ориентированный подход, на основе которого написана ZODB, позволяет для непосредственного хранения данных использовать как стандартный класс FileStorage (хранение в файле Data.fs), так и альтернативные классы: BerkleyStorage и SQLStorage. Также можно отметить наличие неограниченного отката в ZODB, который, однако, поддерживается только хранилищем класса FileStorage.

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

Для устранения задержек, связанных с поиском объектов, было решено использовать интегрируемую в Zope реляционную СУБД MySQL для хранения индексной информации об искомых объектах. На базе статистики по качеству и количеству запросов к системе были разработаны таблицы хранения индексов документов, заданий и записей справочников. Непосредственное взаимодействие NauDoc и реляционной СУБД было возложено на Zope-продукт ZSQLCatalog. Организацию соединения с внешней СУБД MySQL обеспечивает специализированный программный адаптер, в качестве которого выступает Zope-продукт MySQLDA. На рисунке представлена архитектура полученного решения.

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

Тестирование производительности

Для проведения нагрузочного тестирования разработанного решения использовалась база из 50 тыс. документов, 10 тыс. записей справочников и 10 тыс. заданий, что соответствует рабочей системе среднего предприятия с численностью сотрудников до 200 человек. Результаты тестирования для разного количества запросов в очереди представлены в таблица 1 и таблица 2.

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

***

Разработка системы NauDoc на компонентах Open Source и ее распространение в открытых исходных кодах позволяют снизить затраты компании – поставщика решения СЭД на локализацию проблем функционирования, например быстродействия, за счет передачи решения заказчику. Такая практика позволила снизить трудозатраты поставщика примерно на 20%. На стороне заказчика работы выполнялись администраторами NauDoc, не являющимися специалистами по платформе Zope и обладающими только пользовательскими навыками работы с инструментами OpenSTA и DeadlockDebugger.

Кроме того, открытый подход позволяет использовать уже существующие решения и компоненты Zope, широко представленные в сообществе разработчиков Zope. Благодаря этому удается снизить стоимость реализации выбранного способа оптимизации системы. Так, разница между предварительной оценкой трудозатрат на разработку SQL-каталогов и реальными трудозатратами с учетом использования продуктов категории Open Sourсe составляет около 50%. Таким образом, суммарное снижение трудозатрат в рамках проекта NauDoc, а следовательно, и стоимость разработки составили 70%.

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

Олег Евсегнеев (oevsegneev@naudoc.ru) – руководитель группы разработки NauDoc компании Naumen (Москва).


Рис. Open Source–платформа для NauDoc

Таблица 1. Среднее время ожидания при использовании стандартных каталогов индексов

Таблица 2. Среднее время ожидания при использовании SQL-каталогов индексов

Поделитесь материалом с коллегами и друзьями