オブジェクトの変更履歴を保存するための良い解決策は何でしょうか?

データベース内のオブジェクトに対する変更を追跡する必要があります。

重要な実装は、データベース内またはアプリケーション内のトリガーによってレコードが挿入されるミラーテーブルを持つことですが、パフォーマンスに影響を与え、時間の経過とともにミラーデータベースは元のテーブルを変更する必要がある場合、メンテナンス時間が大幅に2倍になりますその変化を反映する必要がある)。

ここでの最大の要件は、データベースとアプリケーションのパフォーマンスに最小限の影響を与えることです。私の現在の優先順位は、変更をsyslog-ng over udpにダンプし、プレーンテキストファイルに保存することです。

すべての変更ログは頻繁にアクセスされるものではないので、時間の経過と共にアーカイブされても大丈夫です。しかし明らかにそのような設定で実際にデータにアクセスするのは非常に難しいです。

だから、私の質問は、少なくとも私のニーズに少なくとも部分的に合ったシステムがすでに存在していると思いますか?完全に適合するのは、データに自動的にアーカイブする(または最小限の設定を行うために必要な)UDP/ACCESSスキーマレスの追加専用データベースシステムです。 MongoDB? CouchDB? YourDB?

5
おそらく現在のマージされた変更を見るためにマージを配列することができるシリアライズされたオブジェクトまたはjsonとして保存された変更の配列(増分更新)。
追加された 著者 Melvin Protacio,
質問がストレージの場合は、ファイル、データベースのフィールド、または永続キャッシュのいずれかに格納できます。君に電話だ。
追加された 著者 Melvin Protacio,
ええ、それは私がやろうとしていることなので、どのストレージを使うべきか疑問に思うので、それを維持してタイムスライスするのは簡単です。
追加された 著者 keymone,

6 答え

さて、これにアプローチする方法はたくさんあります。私はMongoDBをよく知っているので、その方向に傾いています。一般的に私はそれがパフォーマンスのニーズを満たし、複製セットを使用して、奴隷から出る読書を取るアプローチになるだろうと思う。ただし、バージョン管理は組み込まれていません。Mongoid :: Versioningを使用したバージョン管理のアプローチは、

モンゴイイ::バージョン管理 - 以前のバージョンの確認方法

あなたが言及した他の解決策はより良いネイティブサポートを持つかもしれませんが、私はそれについて話すことはできません。うまくいけば、これは少なくともMongoDB側のいくつかのことを指摘してくれるはずです。

3
追加された
ここでアーカイブの問題を解決するにはどうすればいいですか?あるコレクションから別のコレクションにデータを移動して書き込み(挿入)をブロックしませんか?また、私はより多くのログのようなソリューションを探しています、そして、mongodbは、私がこの場合に必要でないたくさんの機能を提供するようです。
追加された 著者 keymone,

モンゴイの歴史をご覧ください。

それは、バージョンと一緒に、いつ、誰によって、何のような変更の履歴を追跡します。また、設定オプションも提供されています

1
追加された

簡単な目的のために(MySQL!)、記録したいテーブルに対してAFTER UPDATEトリガーを実行するだけです。

たとえば、フィールドを持つテーブルカー

carId(主キー) 色 メーカー モデル

フィールドを持つテーブル 'cars_history'(または同等の名前)を作成します。 carId フィールド old_value new_value

次のようにAFTER UPDATEトリガを追加します。

delimiter //

CREATE TRIGGER trigger_changes
AFTER UPDATE ON cars
FOR EACH ROW
BEGIN
IF OLD.manufacturer <> NEW.manufacturer THEN
  INSERT INTO cars_history
  ( carId, field, old_value, new_value)
  VALUES
  (OLD.carId, 'manufacturer', OLD.manufacturer, NEW.manufacturer);
ELSE IF OLD.color <> NEW.color THEN
  ...
END IF;
END;//
delimiter ;

テストされていないので、構文エラーが含まれている可能性があります:)

1
追加された

RavenDBはこの機能をネイティブにしています(ただし、生産ニーズに応じてNoSQL dbとしては若すぎるかもしれません - もちろんこれまで)

http://ravendb.net/docs/server/bundles/versioning

http: //www.slideshare.net/jwoglamott/battle-of-nosql-stars-amazons-sdb-vs-mongodb-vs-couchdb-vs-ravendb

If you want to go for MongoDB, two implementation strategies are suggested in this thread

Strategy 1: embed history will not impact your write performances and read if you tweak your code to avoid returning the history when not necessary, however you have the 16Mb limitation for one documents (might be blocker for you or not). Strategy 2: write history to separate collection requires (plainly) two operations. I agree as said there that these (or a combination) are the strategies available in MongoDB.

CouchDBは内部的にMVCCのアプローチを使用しています(ここ)、しかしこのようなアプローチは、議論されたこのトピックに関する質問があり、提案された解決策は上記のMongoDBの埋め込み戦略(あなたが好むものを選ぶ必要があります)。

1
追加された

SQLiteはどうですか?各DBは、アーカイブ時に簡単に名前を変更して移動できる独立したファイルです。ファイルの名前が変更された場合、または自動的に移動された場合は、次の挿入時にotherが作成されます。

SQLiteについての唯一の問題は、書き込みのためにファイルをブロックする必要がある同時書き込みです。 1秒間に約60件のトランザクションを処理できますが、1回のトランザクションで何千もの挿入を行うことができます( doc )。

0
追加された
残念ながら、sqliteはスキーマレスではありません。モデルの変更と私はあまりにも多くの時間をバージョン管理/変更ログシステムを維持するために費やしたくありません。
追加された 著者 keymone,

I wonder if this is the type of solution you're looking for: http://www.tonymarston.net/php-mysql/auditlog.html

小さなデータフットプリントで非常にシンプルで洗練されたソリューションに見えますが、挿入時間に与える影響も最小限に抑えられます。

0
追加された