Статья содержит анонс выпуска нового модуля аудита в составе платформы Xafari

Описание проблемы

При внедрении прикладных систем (Галактика АММ и Галактика EAM) у Заказчиков возникла потребность вести аудит изменения данных в системе.

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

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

Тестирование стандартного модуля XAF Audit

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

Что бы подтвердить наши опасения мы разработали тест для нашего случая:

  1. Тестовое приложение а-ля Northwind (немного расширен, так у OrderDetails есть еще одна спецификация – OrderDetailsTax)
  2. Включали различные режимы аудита (Light, Full)
  3. Использовали сценарий вставки 100 заказов у каждого по 20 спецификаций и у каждой спецификации еще 5 спецификаций (всего 12 100 объектов)
  4. Create 100 Order + 100*20 OrderDetails + 100*20*5 OrderDetailsTax = 12 100 XAF Objects
  5. Замеряли разницу с отключенным и включенным аудитом
  6. Замеряли требования к памяти в транзакции

Предварительные результаты:

Если в нашем сценарии добавляли в одной транзакции 100 или 500 Orders (с агрегированными спецификациями) 32-битное приложение вываливалось (Out of Memory).

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

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

Поэтому остановились на тестировании только вставки 100 Orders с вызовом Commit после каждого Order (т.е. было 100 транзакций по вставке 121 записи включая вложенные объекты OrderDetails и OrderDetailsTax)

Тест для MS SQL 2008 R2

Локальный компьютер (Win7 8 ГБ CPU 4 core i3 3.3GHz, индекс производительности windows = 7.3) свободной памяти во время тестов 6 ГБ.
Во время теста работало только одно ядро. Однако мы проводили именно сравнительное тестирование, поэтому абсолютные значения затраченного времени не так важны.
Тестировали только создание 100 заказов. Изменение и удаление не тестировали
Создавали 100 Order + 100*20 OrderDetails + 100*20*5 OrderDetailsTax = 12 100 объектов

32-битное приложение, commit после каждого изменения Order (иначе Out of memory)

РежимВремя(сек)Количество добавленных объектов журнала аудита
Журнал 1Журнал 2Журнал 3итого
Full59012 10058 100≈80 000≈150 000
Lite37012 10012 100≈80 000≈104 000
Create Only35012 10012 10012 10024 000
Отключено11----

* Журнал 1 – таблица AuditedObjectWeakReference (наследник от XPWeakReference)
* Журнал 2 – таблица XPWeakReference
* Журнал 3 – таблица AuditDataItemPersistent

В результате при включении аудита падение производительности составило 30-60 раз. Количество создаваемых записей в транзакции увеличивается до 5-10 раз (соответственно возрастают требования к памяти в рамках одной транзакции)

Итоги по результатам тестирования

Применение штатного модуля аудита AuditTrail нельзя рекомендовать для промышленных систем (более 100 тысяч документов). Может применяться при малых изменениях и только для «маленьких» объектов. Массивные бизнес-объекты не могут быть подвержены аудиту (например экземпляр производственной сметы содержащий более 10 тысяч агрегированных объектов).

Поиск решения

Выявленные проблемы штатного модуля не отменили необходимости решить поставленную задачу.

Нашу задачу существенно облегчало то, что наши Заказчики использовали только СУБД Oracle или Microsoft (хотя на долго ли).

Опыт разработки подобного функционала в Галактика ERP

У нас был опыт в рамках другой выпускаемой нашей компанией системы Галактика ERP. В платформе на которой написана данная система Атлантис (ее разрабатывает тоже наша компания) существует модуль «Журнализация» решающий ряд задач:

  1. Журнализация изменений БД с возможностью настройки
  2. Просмотр изменений
  3. Откат изменений
  4. API - используется для целей синхронизации баз (CORPO) и экспорта/импорта

Данный модуль Галактика ERP работает на нескольких целевых платформах Pervasive, MS-SQL, Oracle. Модуль имеет платформа-зависимую реализацию, обеспечивает надежную работу с падением производительности до 15%.

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

Для платформы Oracle данный модуль генерирует для каждой контролируемой таблицы еще одну таблицу «двойник», в которой сохраняется аудит полей.

Рекомендуемые технологии производителями СУБД

Для захвата изменений данных у каждого производителя СУБД есть рекомендуемая технология CDC – Change Data Capture. Технология специально разработана для получения изменений OLTP базы данных с минимальной нагрузкой на СУБД. Данные механизмы подключаются непосредственно к транзакционному протоколу СУБД и позволяют его перенаправлять в еще одну базу данных, для последующего анализа производимых изменений. При этом нагрузка на основную базу данных OLTP практически никак не изменяется. Данная технология используется в сильно нагруженных конфигурациях, когда добавление дополнительных триггеров становится критичным с точки зрения требований к быстродействию основной OLTP системы.

Так для целевых СУБД производителями рекомендуются следующие опции:

  • Oracle DB – Golden Gate
    1. Лицензируется дополнительно (стоимость 17 500 на CPU, минимум 2 CPU)
    2. Требует Oracle Enterprise Edition
  • Microsoft SQL Server – опция Microsoft CDC
    1. Бесплатная опция
    2. Требует Microsoft SQL Server Enterprise Edition

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

Кроме рекомендуемых производителями СУБД есть и другие распространенные продукты с поддержкой CDC технологий. Однако наиболее эффективными являются инструменты от производителей СУБД.

Список бесплатных продуктов класса CDC:

  1. Talend Data Integration - http://www.talend.com/resource/change-data-capture.html
  2. Pentaho Data Integration (бывший Kettle) http://wiki.pentaho.com/display/EAI/Change+Data+Capture+%28CDC%29
  3. LinkedIn DataBus https://github.com/linkedin/databus презентация http://www.slideshare.net/SunilNagaraj1/databus-eventbrite2013
  4. Symmetric DS http://sourceforge.net/projects/symmetricds/ и http://www.jumpmind.com/products/symmetricds/editions

Все они кросс-платформенны по СУБД, однако полностью ориентированы на технологический стек Java.

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

Присутствуют коммерческие технологии, которые лицензируют данные технологии и API у Microsoft и Oracle (например, Attunity CDC, IBM InfoSphere CDC, Informatica PowerExchange CDC), однако их стоимость и возможности сопоставимы с «родными» опциями от производителей.

Найденные пути решения

После изучения проблематики определили для себя три направления:

  • Аудит на уровне бизнес-логики

    1. Реализовать аналог CDC на уровне XAF транзакций, когда в БД будет сбрасываться текстовый (или бинарный) лог одной записью. Далее уже асинхронный сервис будет независимо от транзакций разбирать данный лог и формировать таблицы аудита с нужной нам структурой. Это позволит на порядки уменьшить количество объектов в транзакции тем самым увеличит быстродействие и снизит потребность в оперативной памяти для транзакции.
  • Аудит на уровне СУБД (нам требовалось поддержать только MS-SQL и Oracle)

    1. С использованием триггеров
    2. С использованием механизма CDC

Если выбирать самый масштабируемый механизм, то им окажется «На уровне СУБД CDC». Мы сделали макет и подтвердили работоспособность для XAF. Возникли небольшие сложности с доменными компонентами. Но в итоге работы в этом направлении решили свернуть из-за требований по лицензированию СУБД при использовании CDC механизма. Многие наши заказчики не готовы к покупке Enterprise редакций СУБД.

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

В качестве основного направления мы выбрали для своей реализации – триггеры на уровне СУБД.

Требования

Сформировали достаточно много требований, приведу только некоторые из них:

  • Поставка
    1. Модуль для XAF работающий с доменными компонентами и XPO объектами
  • Быстродействие
    1. Включенный модуль аудита должен замедлять работу системы не более чем на 15%
  • Функционал
    1. Работа на доменных компонентах (все возможные случаи наследования и агрегации)
    2. Аудит изменения сущностей
    3. Аудит изменений полей сущностей
    4. Аудит изменения агрегированных сущностей (если изменился агрегированный объект в родительском объекте должна быть запись об изменении спецификации)
    5. Аудит входа/выхода пользователя
    6. Аудит действий (печать документа)
    7. Аудит бизнес-операций
    8. API для расширения и подписки
    9. Сервис очистки старых записей
    10. Автоматическая генерация триггеров в БД по модели XAF
    11. Поддержка MS-SQL и Oracle
    12. Откат изменений
    13. Поддержка критериев для аудита объектов
  • Администрирование
    1. Включение аудитов входа/выхода, действий, операций
    2. Настройка режима аудита для отдельного типа Full или Lite (включая агрегированные)
    3. Настройка аудируемых полей (какие поля требуется аудировать)
    4. Чистка журнала аудита
  • Пользовательский интерфейс
    1. Формы настройки
    2. Просмотр истории изменений для объекта – вызов из детальной формы
    3. Просмотр изменений для типа
    4. Просмотр общего журнала

Выпуск компонента аудита в рамках Xafari

Данный функционал войдет в следующую версию Xafari и станет доступным для всех разработчиков использующих Devexpress XAF.

Планируем, что в сентябре 2014 года уже станет доступна версия вместе с документацией и примерами использования.

Ограничения реализации

Не будет критерия для аудита типа, т.к. это существенно усложнит настройку и разработку при реализации через триггеры. Может добавим в последние при необходимости. (критерий необходимо транслировать в T-SQL и PL/SQL)

Сервис подписки на события аудита и извещения тоже отложили. Будет реализован вместе со службой извещений.

Откат будет разработан на следующем этапе после апробации в реальных условиях эксплуатации.

Как только выпустим опубликуем подробную информацию.