23

バージョン管理を実装するための実行可能な戦略は次のとおりです (サンプル ドキュメント タイプとして「例」を使用)。

type フィールドが example_original という名前の元のドキュメントを 1 つ用意します。

ドキュメントに対するその後の変更はすべて、タイプ example_change と example_original ドキュメントの ID をキーとして持ちます。変更にはタイムスタンプも含まれます。

すべての example_change が「適用」された example_original の結果であるタイプ example_current の 1 つのドキュメントを保持します。新しい example_change ドキュメントは、このドキュメントに自動的に適用されます。

特定のバージョンを見つけるには、example_original doc を取得し、必要な変更を適用します (ほとんどの場合、特定のタイムスタンプまでですが、いくつかの変更を行うこともできます)。

私のユースケースには、オリジナルへの限られた数の変更が含まれることに言及する必要があります。ほとんどの更新は、新しいオリジナル ドキュメントで構成されます。これは私の現在のユースケースですが、多くの変更が関係する場合に生じる問題にも興味があります。

このアプローチには、どのような長所と短所がありますか?

4

4 に答える 4

20

CouchDB によるシンプルなドキュメントのバージョン管理

この記事で説明する添付ファイルとしてのバージョン管理アプローチは、ほとんどのユーザーのバージョン管理要件に適合するはずです。

于 2010-05-26T12:33:04.863 に答える
10

私の最初の心配は、特定のバージョンを「取得」するときに、データベースを変更せずに元のバージョンに変更を適用できるかということです。

履歴から何かを削除する必要はありますか? 本当によろしいですか？本当に、本当にそうですか？枝はどうですか？

全体として、これは複雑な戦略のように見えます。CouchDB について聞いたことはありますが、使用したことはありません。私はもっ​​と単純なアプローチに行きます：

  1. ドキュメントを作成するときに、UUID を割り当てます。この名前は使用しないでください。名前の変更操作中に問題が発生します。「1」を読み取るバージョン フィールドを追加します。同じ UUID を持つドキュメントのリストを含む 2 番目のドキュメントを作成するか、最初のドキュメントに「親」ポインタを追加します。

    ドキュメントごとに「履歴ドキュメント」があると、履歴のナビゲーションが高速になりますが、親ポインターはより「安全」です (それらを使用して不正な構造を簡単に作成できないため)。

  2. 新しいリビジョンを作成するときは、UUID を再利用して、新しい一意のバージョンを割り当てます。履歴ドキュメントまたは親ポインターを更新します。

この戦略は実装が非常に簡単で、後であらゆる種類の柔軟性を実現できます。履歴の一部を簡単に消去したり、名前を変更したり、ブランチを作成したりできます。

于 2009-08-26T11:20:28.830 に答える
1

これらの文書のビジネスステータス、特に合法的なものは何ですか？私は、v.3として提示されたドキュメントが実際にドキュメントのバージョン3であることを証明する必要があるため、ビジネスの観点からあなたの提案が適切でない状況で作業しました。デルタを動的に適用しても、コンプライアンスマスタードは削減されません。

あなたが言うように、ドキュメントへの変更が頻繁ではない場合、ドキュメント全体ではなくデルタを保存することによって、多くのディスクスペースを節約することはできません。ドキュメント全体を保存することで、任意のドキュメントの取得時間を確実に予測することもできます。また、検索プロセスの複雑さも軽減されます。

于 2009-08-26T11:45:26.843 に答える
1

CouchDB でのバージョン管理の戦略は、完全な履歴を保持する必要があるドキュメントを含むデータベースを圧縮しないことです。他のデータベースを圧縮することもできます。この単純な戦略は、編集競合解決戦略を使用してすぐに使用できます。

ドキュメントの削除は、コンテンツはなくプロパティ セットが削除された新しいバージョンを作成することで実行できます。

バージョン管理メカニズムはリビジョンの単一スレッドを提供するため、この方法で分岐を行うことはできません。

CouchDB の将来の可能性については、次のとおりです。

  • 現在、各リビジョンにはドキュメントの完全なコピーが保持されていますが、CouchDB エンジンの最適化により、いずれデルタを保存できるようになると考えられます。
  • また、将来、CouchDB が特定のドキュメント タイプの圧縮を防止する API を提供する可能性もあります。これにより、すべてのドキュメントを同じデータベースに保持できます。これは、CouchDB への簡単なパッチになります。
  • この戦略はドキュメント ブランチの管理を可能にしますが、ドキュメント データベースとしての CouchDB の性質を考えると、これは合理的ではありますが、長期的な可能性です。
于 2010-04-16T09:33:59.663 に答える