問題タブ [document-database]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
nosql - 大規模なキー値ストアは、ドキュメント データベースよりも水平方向のスケーリングが優れているのは誰ですか?
このプレゼンテーションでは、データが大きくなるにつれて、次の水平スケーラビリティの上限を示すグラフがありました。
キー値 > 列ファミリー > ドキュメント データベース > グラフ データベース
http://youtu.be/UodTzseLh04?t=13m36s
言い換えれば、データがより接続される (つまり、複雑になる) ほど、データベースを拡張できる限界が低くなります。
キー値ストアと比較して、ドキュメント データベースのデータ サイズがスケーラブルでないのはなぜですか? 「データを接続する自由度が高いほど、データの分割が難しくなる」と言って、私自身の質問に答えたことがありますか?
（誰もが通常尋ねる「私がやろうとしていること」の部分：私はほとんどツリーのようなスキーマを持つデータベースを持っていますが、時々2つの親を持つノードがあります.私はプロトタイプでNeo4jを使用しましたが、生産規模のためにアプリ パーティショニングについてもっと考える必要があります. グラフ データベースは簡単にパーティショニングできないため、Mongo DB を使用する必要があり、Mongo DB で「複数の親」関係のコードを記述するのは難しくなります.さらに一歩進んでキー値ストア (または少なくとも列ファミリー ストア) を使用する価値があるかどうか疑問に思っています)。
database - git リポジトリをデータベース バックエンドとして使用する
構造化文書データベースを扱うプロジェクトを行っています。カテゴリのツリー (最大 1000 カテゴリ、各レベルで最大 50 カテゴリ) があり、各カテゴリには数千 (たとえば、最大 10000) の構造化ドキュメントが含まれています。各ドキュメントは、何らかの構造化された形式の数キロバイトのデータです (私は YAML を好みますが、JSON や XML でもかまいません)。
このシステムのユーザーは、いくつかのタイプの操作を行います。
- これらのドキュメントを ID で取得する
- ドキュメント内の構造化属性のいくつかによるドキュメントの検索
- ドキュメントの編集 (つまり、追加/削除/名前変更/マージ); 各編集操作は、コメント付きのトランザクションとして記録する必要があります
- 特定のドキュメントの記録された変更の履歴を表示する (誰が、いつ、なぜドキュメントを変更したかを表示する、以前のバージョンを取得する、要求があればこのバージョンに戻すなど)
もちろん、従来のソリューションでは、この問題に対して何らかのドキュメント データベース (CouchDB や Mongo など) を使用gitしていました。このアプリケーションのデータベース バックエンド?
一見すると、次のように解決できます。
- カテゴリ = ディレクトリ、ドキュメント = ファイル
- ID によるドキュメントの取得 => ディレクトリの変更 + 作業コピー内のファイルの読み取り
- 編集コメントでドキュメントを編集 => さまざまなユーザーによるコミット + コミット メッセージの保存
- history => 通常の git ログと古いトランザクションの取得
- 検索 => 少しトリッキーな部分です。検索を許可する列のインデックスを使用して、カテゴリをリレーショナル データベースに定期的にエクスポートする必要があると思います。
このソリューションに他によくある落とし穴はありますか? そのようなバックエンドをすでに実装しようとした人はいますか (つまり、一般的なフレームワーク - RoR、node.js、Django、CakePHP など)? このソリューションは、パフォーマンスや信頼性に何らかの影響を与える可能性がありますか? つまり、git が従来のデータベース ソリューションよりもはるかに遅くなることが証明されているか、またはスケーラビリティ/信頼性の落とし穴があることが証明されていますか? 互いのリポジトリをプッシュ/プルするこのようなサーバーのクラスターは、かなり堅牢で信頼性が高いはずです。
基本的に、この解決策が機能するかどうか、また機能する、または機能しない理由を教えてください。
mongodb - datetime で日付を取得、操作、保存する
注：投稿を小さくても直感的に保つために、出力にいくつかのドキュメントのみを提供しました
ソース コレクション:
Step-1 : PostDate によるグループ化
クエリ:
出力:
ステップ-2:これを達成しようとしています:
私が試みたクエリ：
出力 (エラー) :
Step-2 を達成するにはどうすればよいですか?
mongodb - ドキュメント データベースのリンクと参照
ドキュメントを接続するための「リンク」という用語と混同しています
OrientDB のページhttp://www.orientechnologies.com/orientdb-vs-mongodb/では、リンクを使用してドキュメントを接続し、MongoDB ではドキュメントが埋め込まれていると述べています。
MongoDB http://docs.mongodb.org/manual/core/data-modeling-introduction/ではドキュメントも参照できるので、ドキュメントのリンクと参照の違いがわかりません。
couchdb - 一意のキーを含むフィールドを設定する方法
データを CouchDB ドキュメントに保存したいのですが、RDBMS での操作に慣れています。データベース内で一意の値のみを含むフィールドを作成したいと考えています。ドキュメントを保存し、一意のキーを持つドキュメントが既に存在する場合、CouchDB からのエラーが予想されます。
ドキュメント ID を使用して、自動生成されたドキュメント ID を自分の値に置き換えることができると思いますが、他のフィールドを一意のキー ホルダーとして設定する方法はありますか。一意のキーに関するベスト プラクティスはありますか?