Эффективный способ аудита - PullRequest
Новая
       80

Эффективный способ аудита

2 голосов
/ 21 апреля 2020

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

1) Создана 1 таблица аудита с полями user_name, table_name, column_name, old_value, new_value, uuid , event_type.

всякий раз, когда сохраняются какие-либо изменения, заполняйте объект аудита и сохраняйте его тоже.

Преимущества:

  • quick

  • прост в управлении, так как только 1 таблица аудита

Падения:

  • иногда это связано с слишком большим количеством сопоставлений из бизнеса объект для объекта аудита

  • старое значение должно быть выбрано из базы данных для заполнения объекта аудита

  • ручное создание объекта аудита
  • поиск может быть трудным

2) Используемые Javers для аудита

Преимущества:

  • автоматизация c создание и обновление аудиторской организации

  • минус количество таблиц для управления

  • old v поиск не требуется

Falls:

  • Слишком много времени заняло, так как размер транзакции велик

Контрольный показатель

Работа с 10 строками таблицы (сущности) с 20 столбцами (полями),

время, затраченное с использованием подхода 1: 24328 мс => 24 с

время, затраченное с использованием подхода 2: 311292 мс => 311 с (почти 12 раз)

3) Не было go с конвертерами Hibernate, поскольку число создаваемых таблиц было бы большим

Может кто-нибудь предложить лучшую идею для одитинга с перечисленными выше плюсами и минусами. Мы стремимся к

  • меньшему количеству таблиц для управления

  • меньшему времени отклика

  • модульным слой аудита, который более автоматизирован, чем ручной

с количеством столбцов в каждой таблице от 10 до 25.

Ответы [ 3 ]

1 голос
/ 21 апреля 2020

Как вы сказали, общий подход к созданию журналов аудита - это библиотеки на стороне приложения, такие как envers или Javers. Эти файлы подключаются в постоянную библиотеку, они будут поддерживать определенные c столбцы в таблицах данных ("createBy", "lastUpdated" и c.) И / или копировать более ранние версии записей в какую-либо форму. таблиц истории.

Однако есть некоторые недостатки:

  • запись записей в таблицы истории в рамках транзакций OLTP увеличивает число выполняемых операторов в транзакции -> может привести к увеличению времени ответа приложения

  • поддержка массовых обновлений и удаление

  • изменения, сделанные непосредственно в базе данных, не могут быть отслежены

Изменение захвата данных за 3 шага

  1. Изменение данных захвата
  2. Преобразование данных изменений в формат, поддерживаемый вашей целевой базой данных для загрузки
  3. Загрузка данных в базу данных назначения.

Изменение сбора данных с помощью триггеров базы данных

Другой метод - триггеры базы данных. Они не пропустят никаких операций, независимо от того, были ли они выпущены из приложения или из самой базы данных. Массовая выписка тоже будет обработана. Еще одно преимущество CD C на основе триггера состоит в том, что приложение не знает о том, что вы добавили весь уровень аудита. С другой стороны, существует проблема увеличения задержки при выполнении триггеров в рамках транзакций OLTP.

Альтернативное решение для триггеров (Postgresql здесь): используйте логическую репликацию для потоковой передачи изменений базы данных (декодированные сообщения WAL) с MASTER-сервера на SLAVE-сервер с использованием WAL и включения триггера Audit для захвата изменений в реплицированных таблицах на подчиненный сервер.

Изменение сбора данных с помощью подхода на основе журнала

Вышеупомянутых проблем не существует при использовании transaction log в качестве источника для аудита и использовании сбора данных изменений для получение информации об изменениях и отправка ее в брокер сообщений или постоянный журнал, например, Apache Kafka. Обычно считается лучшим подходом к изменению сбора данных, но не самым простым решением для установки.

При асинхронном запуске процесс CD C может извлекать данные изменений, не влияя на транзакции OLTP.

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

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

Остается вопрос о том, как CD C может получить доступ к метаданным, как пользователь приложения, который выполнил изменение данных, свой IP-адрес, идентификатор диапазона трассировки или любой вид correlationID.

Один из подходов - создать отдельную таблицу, в которой хранятся эти метаданные. Приложение может хранить для каждой транзакции запись внутри этой таблицы с указанием c transactionId. События изменения данных будут содержать идентификатор транзакции, связанный с изменением, поэтому события изменения данных и записи метаданных могут быть соотнесены.

1 голос
/ 21 апреля 2020

Я бы принял этот подход:

1) аудит в фоновом потоке с низким приоритетом

2) использование пружинного AOP с аннотацией для отделения BU от AUDITING

3) Записывать полный jsonized объект в документ базы данных NO SQL с UID каждый раз, когда объект вставляется или обновляется; старое значение также бесполезно, так как вы можете отследить изменения в сущности, выполняющей простые запросы

0 голосов
/ 21 апреля 2020

Очевидно, что вы неправильно используете Javers, ваши цифры не надежны. Может быть, вы создаете новый экземпляр Javers для каждого коммита?

Javers так же быстр, как инструмент аудита. Javers просто создает снимки для измененных объектов и вставляет их в БД. Одна запись / документ БД на один снимок.

Таким образом, если вы меняете один объект, обычно Javers выполняет одно чтение БД, чтобы получить свой предыдущий снимок, и одну вставку БД для записи нового снимка.

...