タグ付けされた質問 「document-database」

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

119 database  git  database-performance  database-replication  document-database 

私はnode.jsでMongoDBにアクセスするためにMongooseライブラリを使用しています ドキュメントからキーを削除する方法はありますか？つまり、値をnullに設定するだけでなく、それを削除しますか？ User.findOne({}, function(err, user){ //correctly sets the key to null... but it's still present in the document user.key_to_delete = null; // doesn't seem to have any effect delete user.key_to_delete; user.save(); });

102 mongodb  node.js  mongoose  document-database