データベースのバックエンドとしてのgitリポジトリの使用
私は構造化文書データベースを扱うプロジェクトをやっています。カテゴリのツリー（〜1000カテゴリ、各レベルで最大〜50カテゴリ）があり、各カテゴリには数千（たとえば、最大〜10000）の構造化ドキュメントが含まれています。各ドキュメントは、いくつかの構造化された形式で数キロバイトのデータです（私はYAMLを好みますが、JSONまたはXMLでもかまいません）。 このシステムのユーザーは、いくつかのタイプの操作を行います。 IDによるこれらのドキュメントの取得 内部のいくつかの構造化属性でドキュメントを検索する ドキュメントの編集（つまり、追加/削除/名前変更/マージ）; 各編集操作は、コメント付きのトランザクションとして記録する必要があります 特定のドキュメントの記録された変更の履歴を表示する（誰が、いつ、なぜドキュメントを変更したか、以前のバージョンを取得したり、要求に応じてこのバージョンに戻したりすることを含む） もちろん、従来の解決策は、この問題にある種のドキュメントデータベース（CouchDBやMongoなど）を使用することでしgitた。このアプリケーションのデータベースバックエンド？ 一見すると、次のように解決できます。 カテゴリ=ディレクトリ、ドキュメント=ファイル IDによるドキュメントの取得=>ディレクトリの変更+作業コピーのファイルの読み取り コメントを編集してドキュメントを編集する=>さまざまなユーザーによるコミット+コミットメッセージの保存 履歴=>通常のgitログと古いトランザクションの取得 search =>これは少しトリッキーな部分です。検索を許可する列のインデックス付けを使用して、カテゴリをリレーショナルデータベースに定期的にエクスポートする必要があると思います このソリューションには他によくある落とし穴はありますか？そのようなバックエンドを実装しようとした人はいますか（つまり、一般的なフレームワーク-RoR、node.js、Django、CakePHP）。このソリューションは、パフォーマンスや信頼性に影響を与える可能性がありますか？つまり、gitが従来のデータベースソリューションよりもはるかに遅くなるか、スケーラビリティ/信頼性の落とし穴があることが証明されていますか？お互いのリポジトリをプッシュ/プルするそのようなサーバーのクラスターは、かなり堅牢で信頼できるはずだと思います。 基本的に、私に言うならば、このソリューションが動作すると、なぜそうなるか、しないだろうか？