問題タブ [document-store]

ドキュメント ストアではリレーションが実際には必要ないことは理解していますが、いくつかの場合にはリレーションが役立つ場合があります。それとも私は間違っていますか（RDBMSに雪が降った）？

例えば：

たくさんのファイルとそのリビジョン履歴があるとしましょう:

CreatedByファイルとすべてのリビジョンにUser オブジェクトを追加する必要がありますか?それとも、ユーザー ドキュメントを参照する ID にする必要がありますか? 一般的な慣行は何ですか？

RavenDB Webサイトでバックアップと復元のドキュメントを読み、コードで試しました。

ドキュメントには次のものがあります。

バックアップの開始

埋め込みモードで実行する場合、必要なのはメソッドDocumentDatabase.StartBackup（）を呼び出すことだけです。

上記のコード行は、エラーでコンパイルされません。

だから私はこれをテストするためだけに試しました：

コードはコンパイルされますが、アプリの起動時に次のエラーが発生します。

オンラインの埋め込みドキュメントストアの完全バックアップを実行する方法について、誰かが実用的なコードを共有できますか？RavenDBサーバーを使用せずにそれも可能ですか？

私の唯一のオプションは、データベースフォルダの手動バックアップを行うことですか？

（主に）AndroidとiOS用のサーバーレス組み込みnoSQLドキュメントストアデータベースを探しています。
簡単にするために、ドキュメントベースのSQLite：Pが必要です

MongoDBは素晴らしく、多くのドライバーがありますが、サーバーが必要です...
たぶんそれの簡略化されたバージョンで問題ないかもしれません...

非技術的な名前付けの質問:

別のドキュメントへの参照を含むドキュメントがあります。アクセスするほとんどの場合、参照されたドキュメントからいくつかのフィールドが必要になるため、参照を回避するためにそれらを参照と一緒に保存します。

モンゴの例:

自動

メーカー

そのため、auto.maker.name はプライマリ ソースではありません。コストがかかるが非常にまれなメーカー名の変更の結果を除き、決して変更しないでください。

このフィールドを何と呼びますか? 私が見た中で最高のものは「キャッシュ」ですが、特にデータストレージについて話すときは、かなり過負荷です. より良い用語はありますか？

Web ショップの典型的な製品カタログには、どのテクノロジが適しているかを考えています。私はエンタープライズ環境での nosql に関する修士論文を書いており、長い間ドキュメント ストアに焦点を当てていたと思います。何千もの異なる製品をモデル化するために必要な柔軟性のために、ドキュメント ストアを推奨する記事をたくさん読んでください。しかし、私が今知る限り、Cassandra のようなカラム ファミリー ストアは同じ柔軟性を提供します。

私がcassandraを使用するアイデアの中で最も気に入っているのは、nosql-database.orgがそれについて述べていることです（最も興味深い機能をマークしています）：

大規模なスケーラビリティ、パーティション化された行ストア、マスターレス アーキテクチャ、リニア スケールのパフォーマンス、単一障害点なし、複数のデータ センターとクラウド アベイラビリティ ゾーンにわたる読み取り/書き込みサポート。API / クエリ方法: CQL および Thrift、レプリケーション: ピアツーピア、記述言語: Java、並行性:調整可能な一貫性、その他: 組み込みデータ圧縮、MapReduce サポート、プライマリ/セカンダリ インデックス、セキュリティ機能。

最後に、セッション用の K/V ストア、製品カタログ用のドキュメント ストアまたは列ファミリ ストア、および在庫/価格設定用の RDBMS など、ポリグロットの永続性を利用する、可用性が高くスケーラブルなマルチショップ システムのプロトタイプの構築に焦点を当てます。 Sadalage と Fowler は、著書「NoSQL Destilled」で言及しています。

可能であれば、科学論文またはその他の信頼できる情報源を回答に提供してください。

ありがとう！

RavenDB をデータストアとして使用する MVC4 アプリケーションがあります。アプリケーションには、MVC/Web、ドメイン、データ、およびセキュリティ レイヤーがあります。

データベースを初期化し、DocumentStore にアクセスする必要があるカスタム メンバーシップとロール プロバイダーを作成しています。セキュリティ層からこれらのクラスを作成しており、シングルトン DocumentStore (アプリケーションで設定) を使用したいのですが、アクセス方法がわかりません。

その他、RavenDB のカスタム プロバイダーを作成する例として、Provider.Initialize() メソッド内で新しい DocumentStore インスタンスを作成していますが、これはサーバーごとに 1 つの DocumentStore を持つという規則に違反しているようです。

現在、Application_Start() で RavenDB DocumentStore のインスタンスを 1 つ作成しています。DocumentStore.Session(s) を処理する MVC/Web レイヤーに基本コントローラーがあります。

これを達成する方法はありますか？単純化するために、セキュリティ ロジックを MVC/Web レイヤーに移動する必要がありますか?

私が行った調査に基づいて、キー値ストアは適していないと思われますが、より直接的な入力を取得したかったのです。

1. キー値ストアが私の使用法にとって実行可能なソリューションであるかどうかを判断してください。
2. 代わりにドキュメント ストアを好む理由を明確に説明できるようにします。

私のユースケースを説明するには

多くの「ドキュメント」で構成されるアプリケーションがあります。これらは現在、一種の CMIS リポジトリに保存されています。ただし、アプリケーションは、elasticsearch にインデックスが作成された後にのみ、これらのドキュメントと対話します。これは、すべての読み取り操作がelasticsearchにヒットし、すべての書き込み操作がelasticsearchとリポジトリの両方を更新することを意味します.

リクエストされた機能により、現在のリポジトリが厳しすぎることが明らかになり、そのレベルでモデル スキーマを強制する理由はまったくありません。もちろん、これは NoSQL オプションの調査につながりました。

これらの「ドキュメント」をelasticsearchインデックスに入力するには、それらがどこかに存在する必要があり、インデックスに読み込まれるときにすべてを取得してページ分割できる必要があります（データを入力するために、このステップで発生する集計もあります）既存のフィールドから構築されたフィールド)。

現在、すべての取得は実際にはドキュメントのタイプに基づいて段階的に行われていますが、この要件は交渉可能であり、代わりにすべてのタイプの単純なすべての取得で十分かもしれませんが、理想的ではありません.

キー値ストアに関する私の理解では、ストアは格納する値について何も認識しておらず、キーによってのみ参照できます。これにより、キーの完全なリストをどこにも維持する予定がない場合に、 get allを実行できるかどうか疑問に思います。辞書をキー (redis) として使用することをサポートするキー値ストアがあることを確認しました。これが型でクエリできることを意味するのか (辞書のエントリの場合)、または値をフェッチできるようにするために完全な辞書を知る必要があるのか​​どうかはわかりません。

インデックスの作成は、elasticsearch に障害が発生した場合にのみ発生する必要があるため、パフォーマンスは最優先事項ではありません (ただし、パフォーマンスが損なわれることはありません)。私にとって、MongoDB はほぼ完璧にフィットするように思えます。ドキュメントを保存し、タイプ別に簡単にクエリを実行できます。

• 私の使用例を考えると、ドキュメント ストアは適切な決定のように思えますか?
• これもキー値ストアによって合理的に解決できますか?
• 1 つを別のものよりも使用する利点は他にありますか?

念のため、ドキュメント ストアについては、CouchDB、Couchbase、および MongoDB を比較してきました。キー値ストアについては、Redis と BerkeleyDB を検討してきました。

次のケースがあります。ユーザーは、Web サイトに連絡先 (他のユーザー) を追加できます。必要に応じて、ユーザーは自分の連絡先をグループで整理することもできます。ユーザーは、多くの電子メール、住所、電話番号を持つことができます。

以下のスキーマ設計（ドキュメントストア/mongodb）を考えました。これを改善する方法はありますか？私の主な懸念は、プロフィール写真がドキュメント内に埋め込まれていることです。これは良い方法ではないことはわかっていますが、この特定の目的 (割り当て) のために、ここにも画像 (blob/gridfs) を埋め込む必要があります。しかし、このスキーマをどのように改善できるか疑問に思っています。

この図を考えてみましょう:

この本によると、ドキュメント ストア データベースは、高度に接続されたドメインと格闘します。その理由は、 「集約間の関係はデータ モデルの第一級市民ではなく、ほとんどの集約ストアは、ネストされたマップの形式で構造を持つ集約の内部のみを提供するためです。」 .

さらに、「代わりに、データベースを使用するアプリケーションは、これらのフラットで切断されたデータ構造から関係を構築する必要があります。」

すみません、意味がわかりません。高度な関係に基づくコンテキストで、ドキュメント ストア データベースが苦労するのはなぜですか?