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

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

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

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

Ответ 1

В прошлом я использовал триггеры для создания db update/insert/delete logging.

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

Я использую SQL Server, а не PostgreSQL, поэтому я не уверен, что это сработает для вас или нет, но у Pop Rivett была отличная статья о создании аудита: Pop rivett SQL Server Часто задаваемые вопросы No.5: Поп-аут аудита

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

Подсказка: используйте Codesmith, чтобы создать триггеры.