ユーザーが作成したドキュメントをバージョン管理する方法

8

本質的にXML文字列としてデータベースに保存されるオンラインドキュメントがあります。

ユーザーのためにドキュメントのバージョン管理を実装する方法を考えています。そのユーザーはドキュメントの以前のバージョンに戻ることができます。

更新私の場合、何十万ものユーザーがいるWebアプリケーションです。ユーザーは無制限のドキュメントを保存できます。ドキュメントのXMLは、MySQLのBlobフィールドに格納されるため、小さくはありません。結局、私はどういうわけか限界を制限する必要がありますが、それはすべて一緒に異なるトピックです。

これにアプローチする標準的な方法はありますか？バージョン間の違いのみを保存する必要がありますか？他に考慮すべきことは何ですか？

design architecture versioning

— dev.e.loper
ソース

1

ここで興味深い質問は次のとおりです。データを統合する必要がある既存のMYSQL DBインフラストラクチャがありますか（特に、多くのユーザーに合わせて拡張されたシステム）？Crazy EddieのRCS提案は、そのようなシステムに統合するのは簡単ではないようです。

— ドクターブラウン

セキュリティモデルとは何ですか？各ユーザーのドキュメントはプライベートだと思いますか？

— マイケル

各ユーザーのドキュメントはい@Michaelプライベートです

— dev.e.loper

@DocBrownはい私はこれらのxmlドキュメントが現在格納されている既存のMysql dbテーブルを持っています。

— dev.e.loper

@ dev.e.loper：プライバシーはDBサーバーによって強制されていないと思いますよね？言及したユーザーの数は、スケーリングされたWebサーバーソリューションについて話していることを示しています。ここでの質問は次のとおりです。XMLデータをデータベースに保持する必要があるか、または保持する必要がありますか、それともデータのその部分に別のテクノロジーを自由に選択できますか？

— Doc Brown、

13

ソース管理リポジトリを使用しないのはなぜですか？必要なストレージスペースが少なくなり、現在必要なすべてのことを実行でき、RCSから取得するすべてのものをブランチ、タグなどにさらに簡単に拡張できます。なぜ車輪を再発明するのですか？

— エドワード・ストレンジ
ソース

どういう意味ですか？私のサーバーにSVNをインストールし、それらのファイルを保存するためにapiを使用しますか？

— dev.e.loper

このアプローチのどこかにボトルネックがありますか？たとえば、50,000人のユーザーが作業内容を保存/バージョン管理しているとします。ソース管理リポジトリは、50,000の正しいバージョン管理を処理する必要がありますか？

— dev.e.loper

OPはデータベースのことです（おそらく、既存のデータベースです）。既存のデータベーススキーマに簡単に統合できるソース管理システムは知りません。

— Doc Brown

@ dev.e.loper-SVNを含むまともなRCSは、その多くのユーザーを処理できるはずです。

— エドワード・ストレンジ

5

これをデータベースで実行しているので、XML文字列をバージョン管理する最も簡単な方法は、次の列を持つ新しい履歴テーブルを作成することです。

履歴ID
新しいXML文字列（オプションの列）
古いXML文字列
タイムスタンプを挿入

XML文字列テーブルの行を更新する前に、この履歴テーブルに行を挿入します。

— ギルバートルブラン
ソース

XML文字列テーブルの行を更新する場合、以前のバージョンを取得する方法はありません。できることは、変更日の履歴を表示することだけです。更新ではなく挿入を行う必要があります...できればdiffを使用します。

— エドワード・ストレンジ

@CrazyEddie：以前のバージョン（古いバージョン）は履歴テーブルにあります。1つのドキュメントに差分は必要ありません。

— Gilbert Le Blanc

「差分は必要ありません」-ドキュメントの大きさ、変更の頻度、OPが「ユーザーごとに1つのドキュメント」を意味していない場合はわかりません。したがって、「diffは必要ありません」は、単なるワイルドな推測です。それにもかかわらず、あなたの答えは正しい方向を指していると思うので、私はあなたに+1を与えました。しかし、「新しいバージョン」と「古いバージョン」の列に何が含まれるか（XML文字列、以前の履歴IDへの参照、または何か他のもの？）を説明することで、それを改善できます

— Doc Brown

@Doc Brown：そして、古いバージョンのXML文字列が必要になる頻度はわかりません。もちろん、差分エンジンを作成する時間と労力も必要です。データベースがテキスト文字列の圧縮を行うかどうかさえわかりません。列参照を修正しました。

— Gilbert Le Blanc

@GilbertLeBlanc：（OPが質問の最初のバージョンを書いたとき）私たちはどちらもそれを知りませんでした-そのため、ここでは「差分が必要」または「差分は不要」とは書いていませんでした。単純な非差分ソリューションで十分な場合は、より複雑な差分ソリューションから始めないことをお勧めします。それがあなたの意図したことだと思います。

— ドクターブラウン

3

これにアプローチする標準的な方法はありますか？

標準ベースのアプローチについては、WebDAVの Delta-V拡張機能（それ自体がHTTPに対して広くサポートされている拡張機能）を見てください。Delta-VはWebDAVにバージョン管理を追加し、RFC 3253で説明されています。

— カレブ
ソース

1

比較的簡単な方法は、保存するたびにリビジョンIDを増分し、新しいXMLドキュメントをその新しいリビジョンIDで保存することです。

表：ドキュメント

doc_id | name          | current_revision
   1   | Shopping List |       5

テーブル：doc_revisions

doc_id | revision | timestamp | xml_blob
  1    |    1     | 2012...   |
  1    |    2     | 2012...   |
  1    |    3     | 2012...   |
  1    |    4     | 2012...   |
  1    |    5     | 2012...   |

また、xmlファイルをファイルシステムに個別に保存することも検討してください。blobではなく、ファイルへのURL /パスを使用してdoc_revisionsテーブルを変更できます。これにより、データベースは物理的に大きくならず（ドキュメントを別のサーバーに移動できます）、データベースサーバーからドキュメントの取得の負荷を軽減できるため、単一のサーバーではるかに大きなボリュームをdbで処理できるようになります。

個人的には、ファイルの違いは保存しません。むしろ、毎回ファイルの完全な新しいリビジョンを保存します。ストレージは安価であり、物事を複雑にする必要はありません。「diff」機能は、最終的に本当に必要になった場合に後で実装できます。差分を保存する場合は、たとえばドキュメントのテキストを検索する必要がある場合など、予期しない複雑さをもたらす可能性があることに注意してください。

— グランドマスターB
ソース

ファイルの差分を保存する限り、diff-match-patchライブラリcode.google.com/p/google-diff-match-patch

— dev.e.loper

1

データベースログを模倣しないのはなぜですか？

基本的に、変更はトランザクションとして年代順にマークされます。ドキュメントDBの場合、トランザクションはテーブル行エントリではなく、差分BLOB +タイムスタンプで構成されますが、概念は同じです。バージョン管理システムの動作とほとんど同じです。

物事をスムーズに保つために、現在のバージョンのキャッシュされたコピーを保管してください。誰かが時間をさかのぼる必要がある場合は、必要な履歴に達するまでトランザクションをロールバック（つまり、取り消す）できます。キャッシュされたコピーは、保存操作が実行されるまで変更されないという考えです。

一貫性を維持するには、ロールバックも考慮する必要があります。すでに説明したとおり、ユーザーが5つのバージョンに戻ったとします。5つのトランザクションは、時系列の逆順で現在のバージョンに逆に適用されますが、その状態が保存されると、トランザクションは現在のバージョンと比較してその状態との差分として保存されます。

基本的に、履歴は書き直されることはなく、新しいバージョンを作成するために再利用されるだけです。

— エヴァン・プレイス
ソース