web-dev-qa-db-ja.com

CouchDBとドキュメントのバージョン管理

私は現在、CouchDBを使用してwiki風のアプリケーションに取り組んでおり、ドキュメントのバージョン管理スキームを実装しようとしています。私の見方では、これを行うには2つの方法があります。

  1. 各バージョンを個別のドキュメントとして保存する
  2. 古いバージョンを単一のドキュメントへの添付ファイルとして保存します。

今、私は＃1の形で働いています。ユーザーがドキュメントを編集して保存すると、バックエンドは最初に以前のリビジョンを新しいドキュメントにコピーしてから、新しいバージョンを保存します。各ドキュメントには、各バージョンのデータを含む「履歴」配列があります（古いバージョンのドキュメント_id、タイムスタンプ、エディターなど）。

頻繁に更新されるドキュメントの場合、この履歴配列はかなり長くなる可能性があるため、通常の読み取り中に履歴のないドキュメントをフェッチするビュー（および履歴をフェッチするための別のビュー）があります。

私の質問は次のとおりです。現在のアプローチに不安を感じており、「アタッチメント」メソッドへの変更を考えています。確信はないけど。私よりもCouchDBをよく知っている人（私はこれに数週間しか触れていません-これはCouchDB ...とNoSQLを使用した私の最初のプロジェクトです）がそれぞれの長所と短所を教えてくれることを願っていますアプローチ。それとも、私が見落としている他のバージョン管理スキームがあるのでしょうか？

database-designcouchdb
12
James Adam

古いドキュメントを個別のドキュメントとして保存するか、データベースの最終リビジョンへの添付ファイルとして保存すると、データベースサーバーにオーバーヘッドが発生するため、変更のみを保存することをお勧めします。

ドキュメントのキー値を変更する場合は常に、_h_i_s_<key_name>という名前の新しいキーを追加します。新しく作成された（または最後の更新中に作成された）で、編集/更新のたびに以下のようなオブジェクトを追加します。

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

または

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

このアプローチは、長期的には多くのディスク容量とレプリケーション帯域幅を節約します。

2
Ravinder Payal

年後;-)

couchDBが代わりに行うので、変更を保存する必要はありません。ドキュメントが変更されると、新しいリビジョンが作成されます。これは物理的には同じ_idであるが、新しい_rev（改訂版）の別のドキュメントであり、ディスク上のスペースを消費することに注意してください。

確かに、すべてのリビジョンを維持する必要があります。つまり、非常に大きなディスクが必要です。

0
awenkhh

CouchDBの知識なし。すべてのバージョンを保存することは、前バージョンとわずかに異なるだけかもしれませんが、ストレージの無駄です。変更のみを保存することをお勧めします。

here を確認するか、データのバージョン管理を検索してください。

0
xuma202