Эффективная стратегия ведения журнала аудита / истории изменений для приложений БД?

Question

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

Немного информации о базе данных:

• Должен иметь возможность увеличиваться на тысячи записей в неделю
• 50-60 Столов
• Основные пересмотренные таблицы могут содержать несколько миллионов записей в каждой
• Разумное количество установленных внешних ключей и индексов
• Использование PostgreSQL 8.x

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Если вы используете режим гибернации, взгляните на Джбосс Энверс.С домашней страницы проекта:

Проект Envers направлен на обеспечение простого управления версиями постоянных классов JPA.Все, что вам нужно сделать, это прокомментировать ваш постоянный класс или некоторые его свойства, которые вы хотите изменить, с помощью @Versioned .Для каждой версионной сущности будет создана таблица, в которой будет храниться история изменений, внесенных в сущность.Затем вы можете извлекать и запрашивать исторические данные без особых усилий.

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Я использую SQL Server, а не PostgreSQL, поэтому я не уверен, сработает ли это для вас или нет, но у Pop Rivett была отличная статья о создании журнала аудита здесь:Часто задаваемые вопросы по SQL Server от Pop rivett №5:Всплывающее окно в журнале аудита

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

Подсказка:использование Кодировщик чтобы создать свои триггеры.