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

Question

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

Я понимаю, что есть разные способы сделать это, такие как: стороны

1. .NET кода, с помощью Reflection
сторона
2. SQL Server запускает
3. SQL Server CDC (Change Data Capture)

Метод, основанный на .NET Reflection, может занять немного больше времени, чтобы быть написанным, но если правильно сделано, он будет достаточно умным, чтобы включать новые свойства, добавленные в будущем без изменения кода, и i t также может расширять и сравнивать все дочерние объекты (например, коллекции других сущностей, добавленных в наш основной объект .NET).

На самом деле у нас есть устаревшее приложение, использующее такое построение аудита аудита .NET. Мы сохраняем весь контрольный журнал в виде XML-поля в базе данных SQL, и за эти годы таблица аудита теперь составляет примерно 35 ГБ данных.

Я имею в виду, насколько легко это может быть решение на основе триггера с точки зрения:

• первой реализации
• каждое изменение требуется в будущем модификации объекта аудита (добавить/изменить/удалить поле и т. д.)
• Насколько читаемыми являются данные аудита? мы можем просто задать запрос, показывающий старые и новые значения для конкретной операции сохранения?

... а как насчет спектаклей?

Есть ли у кого-нибудь опыт работы с обоими подходами и может предложить или указать некоторые плюсы и минусы?

Answer 1

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

Объем был существенным .. несколько дней более 50GB текстовых файлов, а на других в среднем 10-15GB.

1-решение, которое мы использовали упорствовать его в SQL

• Производительность медленных
• Запросы медленного
• решение Архивирование одинаково медленно
• Поддержка запросов DB записей

Около 2 лет назад

• Мы переместились в текстовый файл. Открыть и добавить
• Ежедневный базис мы gzip текстовый файл, чтобы сократить пространство.
• Быстрая запись
• медленно читает (читать с gzip'нутыми потока и запроса записей)

В прошлом году

• Ограничить размер файла 4Gb и пролонгировать использовать новый файл (улучшенная производительность GZIP , снижение ОЫЕ)
• GZIP любых файлов каждое утро
• быстро написать
• могут, экс ecute parallel читает так лучше, читает (читает gzip-поток и записи запросов)

Что вы выбираете, исходя из ваших потребностей.

Answer 2

Если вы сопоставляете объекты бизнеса с представлениями, вы можете использовать триггер INSTEAD OF для генерации ваших журналов аудита.

Answer 3

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

По существу, вы должны сделать изменение гражданина первого класса модели, указав событие, которое срабатывает при внесении изменений в бизнес-объекты. Эти события также могут быть хорошим способом захвата бизнес-целей, а не просто изменений на полевом уровне. Например, бизнес-событие с именем OrderRefunded обычно является лучшим контрольным пунктом, чем OrderTotal field changed from 45.00 to 0.00.

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

Еще одно преимущество в том, сколько данных необходимо сохранить. Такой подход дает вам преимущество, заключающееся в том, что абоненту «Аудит» нужно будет только сохранить объем данных, которые он намеревается использовать. Правила о том, сколько данных для сохранения или архивирования также локализованы для службы, обрабатывающей аудит. Поэтому вы можете быть уверены, что не будете хранить данные без необходимости.

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