CouchDB のバージョン管理戦略

Question

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

type フィールドの名前が example_original である元のドキュメントが 1 つあります。

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

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

特定のバージョンを見つけるには、example_original ドキュメントを取得し、必要な変更を適用します (ほとんどの場合、特定のタイムスタンプまでですが、多数の変更が適用される場合もあります)。

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

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

Answer 1

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

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

全体として、これは複雑な戦略のように見えます。CouchDB について聞いたことはありますが、使用したことはないことに注意してください。私は、より単純なアプローチを使用します。

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

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

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

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

Answer 2

シンプルなドキュメントのバージョン管理CouchDBのを持つ

添付ファイルは、この資料に記載アプローチとしてバージョニングは、バージョン管理のためにほとんどの人々の要件に適合しなければならない。

Answer 3

これらの文書のビジネスの状況は、特に法的な何ですか？私は理由V.3として提示した文書が本当にドキュメントのバージョン3であることを証明する必要があるため、あなたの提案がビジネスpersepctiveから適切ではない状況で働いています。動的にデルタを適用することで、コンプライアンスのマスタードをカットしないでしょう。

もし、あなたが言うように、ドキュメントへの変更は、あなたではなく、文書全体のデルタを格納することによって、多くのディスクスペースを節約するつもりされていない、まれAE。全体の文書を格納することも、任意のドキュメントの検索時間の信頼性の高い予測が可能になります。また、検索処理の複雑さを軽減します。

Answer 4

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

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

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

次に、CouchDB の将来の可能性について説明します。

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