DB アプリケーションの監査証跡/変更履歴を残すための効果的な戦略は?
-
09-06-2019 - |
質問
かなり複雑なデータベース内のデータの変更履歴を維持するために成功した戦略は何ですか。私が頻繁に使用および開発しているアプリケーションの 1 つは、時間の経過とともにレコードがどのように変化したかを追跡するためのより包括的な方法から実際に恩恵を受ける可能性があります。たとえば、現在、レコードには多数のタイムスタンプと変更されたユーザー フィールドを含めることができますが、操作がロールバックされた場合など、複数の変更をログに記録するためのスキームが現時点ではありません。完璧な世界では、保存するたびに記録をそのまま再構築することが可能になります。
DB に関するいくつかの情報:
- 1 週間に数千件のレコードが増加する容量が必要
- 50~60 テーブル
- 主要なリビジョンテーブルにはそれぞれ数百万のレコードが含まれる場合があります
- 適切な量の外部キーとインデックスのセット
- PostgreSQL 8.x の使用
解決
以前、私はトリガーを使用してデータベースの更新/挿入/削除のログを作成しました。
特定のテーブルで上記のアクションのいずれかが実行されるたびに、アクション、実行した DB ユーザー、タイムスタンプ、実行されたテーブル、および前の値を追跡するログ テーブルにレコードを挿入できます。
ただし、実際の削除または更新が実行される前に値をキャッシュする必要があるため、おそらくより良い答えがあると思います。ただし、これを使用してロールバックを行うことはできます。
他のヒント
使用できる戦略の 1 つは、MVCC (Multi-Value Concurrency Control) です。このスキームでは、テーブルの更新は一切行わず、挿入だけを行い、各レコードのバージョン番号を維持します。これには、任意の時点からの正確なスナップショットを提供できるという利点があり、また、多くのデータベースを悩ませる更新ロックの問題も完全に回避できます。
ただし、データベースが巨大になり、すべてを選択するには、レコードの現在のバージョンを選択するための追加の句が必要になります。
Hibernate を使用している場合は、こちらをご覧ください。 JBoss エンバース. 。プロジェクトのホームページから:
Envers プロジェクトは、永続的な JPA クラスの簡単なバージョン管理を可能にすることを目的としています。必要なのは、バージョン管理する永続クラスまたはその一部のプロパティに @Versioned のアノテーションを付けることだけです。バージョン管理されたエンティティごとに、エンティティに加えられた変更の履歴を保持するテーブルが作成されます。これにより、手間をかけずに履歴データを取得してクエリを実行できるようになります。
これは少し似ています エリックのアプローチ, しかし、おそらく労力ははるかに少なくなります。ただし、データベースへのアクセスにどのような言語/テクノロジを使用しているかはわかりません。
トリガーを使用する場合の唯一の問題は、挿入/更新/削除のパフォーマンスのオーバーヘッドが増加することです。スケーラビリティとパフォーマンスを高めるには、データベース トランザクションを最小限に抑える必要があります。トリガーを介した監査では、トランザクションの実行に必要な時間が増加し、ボリュームによってはパフォーマンスの問題が発生する可能性があります。
もう 1 つの方法は、Oracle の場合と同様に、データベースが「Redo」ログをマイニングする何らかの方法を提供しているかどうかを調査することです。REDO ログは、データベースに障害が発生して回復する必要がある場合にデータを再作成するために使用されます。
トリガーと同様に (またはトリガーを使用して)、すべてのトランザクションでロギング イベントを非同期に起動し、別のプロセス (または単なるスレッド) で実際にロギングを処理させることができます。これを実装するには、アプリケーションに応じてさまざまな方法があります。最初のトランザクションで不必要な負荷が発生しないように、アプリケーションでイベントを発生させることをお勧めします (監査ログのカスケードによるロックが発生する場合があります)。
さらに、監査データベースを別の場所に保持することで、プライマリ データベースのパフォーマンスを向上できる場合があります。
私は PostgreSQL ではなく SQL Server を使用しているので、これがうまくいくかどうかはわかりませんが、Pop Rivett が監査証跡の作成に関する素晴らしい記事をここに掲載しています。Pop rivett の SQL Server FAQ No.5:監査証跡を確認する
監査テーブルを構築し、監査するテーブルごとにトリガーを作成します。
ヒント:使用 コードスミス トリガーを構築します。