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

Question

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

Некоторая информация о БД:

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Подсказка: используйте Codesmith для создания своих триггеров.