問題タブ [document-database]

読み取り/書き込みが集中するアプリケーション向けに、フェイルオーバー クラスタリングを使用したドキュメント データベース ストレージ ソリューションを検討しています。

1 秒あたり平均 40K の同時書き込みがデータベースに書き込まれます (ピーク時には 70,000 に達する可能性があります)。ほぼ同様の数の読み取りが発生する可能性があります。

また、データベースが新しく書き込まれたレコードについて通知するためのメカニズムも必要です (データベース レベルでの何らかのトリガー)。

ドキュメント データベースの適切な選択と関連するキャパシティ プランニングに関して、どのオプションが適切でしょうか?

更新しました

期待の詳細。

• 平均して、3 ～ 4 のデータベース/ドキュメント コレクション全体で 1 秒あたり 40,000 (40K) の挿入 (新しいドキュメント) の数が予想されます。
• ピークは 120,000 (120K) の挿入に達する可能性があります
• インサートはすぐに読めるようになるはずです - ほぼリアルタイム
• これに加えて、1 秒あたり約 5000 の更新または削除が予想されます
• これに加えて、データにアクセスする 500 ～ 600 の同時クエリも予想されます。これらのクエリと実行計画はある程度わかっていますが、たとえば週に 1 回程度更新する必要があるかもしれません。
• システムは、ストレージ側でフェールオーバー クラスタリングをサポートする必要があります

Usersとの間の多対多の関係の動作を模倣しUserGroups、ユーザーが属する UserGroup の ID を配列内のユーザー ドキュメントに格納するとします。UserGroup を削除すると、その UserGroup の ID はユーザー ドキュメントの配列に残ります。配列に古くて役に立たない値が保持されているということは、どの時点でもパフォーマンスに影響しますか?

保存したいアイテムのリストを保存しようとすると、カウントが 30 を超えているというエラーが表示されます

このセッションで許可されているリクエストの最大数 (30) に達しました。Raven は、早期警告システムとして、セッションで許可されるリモート呼び出しの数を制限します。セッションは短命であることが予想され、Raven は Load(string[] keys) のような機能を提供して、複数のドキュメントを一度にロードし、バッチ保存します。

これを回避するにはどうすればよいですか? このエラーの問題は、ロードしていないことです。ドキュメントを保存しようとしています。どんなアイデアでも大歓迎です。ありがとうございました

http://ravendb.net/tutorials/hello-worldにあるコードに基づいて、RavenDBの簡単なテストを正常に実行できました。

次に、Embedded Mannerで実行しようとしましたが、次のエラーが発生し続けます。

設定：

ターゲットフレームワークは.NETFramework4です。

プロジェクトに次の参照を追加しました。

1. \ RavenDB-Build-309 \ EmbeddedClient \ Raven.Client.Embedded.dll
2. \ RavenDB-Build-309 \ Client \ Raven.Client.Lightweight.dll
3. \ RavenDB-Build-309 \ EmbeddedClient \ Raven.Storage.Esent.dll
4. \ RavenDB-Build-309 \ EmbeddedClient \ Raven.Storage.Managed.dll

コードは次のとおりです。

私はこれを数日間検索してみましたが、いくつかの異なるバリエーションも試しました。何が起こっているのかわかりません。

ドキュメント データベースに関して私が理解していないことが 1 つあります。それは、共有オブジェクトの処理方法です。この 2 つの異なるオブジェクト/ドキュメントを取り上げます。

ユーザーは、両方のドキュメントで同じユーザーです。

• ドキュメントに保存されている実際のユーザーまたは何らかの参照 (RDBMS など)
• ユーザーの変更はどのように処理されますか (新しい名前など)?

RDMBS を使用してマルチテナント アプリケーションを実行する場合tenantId、各テーブルの列を使用して、行が属するテナントを示します。

DocumentDatabase でそれを行うにはどうすればよいですか? mongodb を例にとってみましょう。DBRef行く方法はありますか？それとも、私は関係的思考にとらわれていますか? それとも、documentdb 以外のものを使用しますか?

（私はnosqlにかなり慣れていません）

パフォーマンス上の理由から、複雑なsqlserverビューをmongoDBのようなdocumentDBに取り込むことを検討しています。2つを一緒に同期することは可能ですか？またはビューからdocumentDBに各レコード/ドキュメントを取得するための最良のアプローチは何ですか。

これは、Web上でのみデータを直接表示するためのものです。更新、削除、挿入はありません。

* documentDBについて学びたいので、これは実装のための単純なプロジェクトになります。

プロジェクトの開始時に、会社のコレクションを保存し、各会社内に従業員のコレクションを保存したいとします。

ドキュメント データベース (MongoDB など) を使用しているため、構造は次のようになります。

将来的に、一部の従業員が複数の会社で働くという新しい要件が追加された場合はどうなりますか?

文書データベースでこの種の変更をどのように管理するのでしょうか?

ドキュメント データベースの単純さは、簡単に変更できない壊れやすいデータ構造を作成するため、最悪の敵になりませんか?

上記の例では、変更スクリプトを実行して新しい「Employees」コレクションを作成し、すべての従業員をそのコレクションに移動する必要がありますが、何らかの関係キー (各従業員の CompanyID など) を維持します。

上記を徹底的に行った場合、多くのコレクションがあり、階層がほとんどなく、ドキュメントがキーによって結合されることになります。

その場合、ドキュメント データベースをそのまま使用できますか?

リレーショナル データベースのようになっていませんか。

ドキュメント指向のデータベース (特に RavenDB) には非常に興味をそそられており、少し試してみたいと思っています。しかし、リレーショナル マッピングに慣れている私は、ドキュメント データベースでデータを正しくモデル化する方法を考えていました。

C# アプリケーションに次のエンティティを含む CRM があるとします (不要なプロパティを除外します)。

Company連絡先とタスクには会社以外の目的がなく、ほとんどの場合、タスクまたは連絡先のクエリには関連する会社に関する情報も表示されるため、 これをすべてドキュメントに入れることを考えていました。

問題はTaskエンティティに付属しています。ビジネスでは、タスクが常に会社に関連付けられている必要がありますが、必要に応じてタスクにも関連付けられているとします。

リレーショナル モデルでは、特定のタスクのタスクのみを表示し ながら、TasksテーブルがありCompany.Tasks、会社のすべてのタスクに関連付けられているため、これは簡単です。Contact.Tasks

これをドキュメント データベースでモデル化するために、次の 3 つのアイデアを考えました。

1. タスクを別のドキュメントとしてモデル化します。ほとんどの場合、会社や連絡先を見ると、タスクのリストを見たいと思うので、これは一種のアンチドキュメントデータベースのように思えます。

2. 連絡先に関連付けられていないタスクをリストに保持し、連絡先に関連付けられたCompany.Tasksタスクを個々の連絡先のリストに入れます。これは残念なことに、会社のすべてのタスクを表示したい場合 (おそらく大量になるでしょう)、会社のすべてのタスクと個々の連絡先のすべてのタスクを結合する必要があることを意味します。また、連絡先からタスクを会社に移動する必要があるため、連絡先からタスクの関連付けを解除したい場合、これは複雑だと思います

3. すべてのタスクをCompany.Tasksリストに保持します。各連絡先には、関連付けられているタスクの ID 値のリストがあります。Taskこれは、id 値を手動で取得する必要があり、連絡先のエンティティのサブリストを作成する必要があることを除けば、良いアプローチのようです。

ドキュメント指向データベースでこのデータをモデル化するための推奨される方法は何ですか?

私は、ルックアップがいくつかのオブジェクト プロパティ (published = TRUE または user_id = X) によって行われ、どこにも結合がない(1:1 キャッシュ レイヤーのため) SQL の世界から来ました。私のデータには文書データベースが適しているようです。

1 つ (または複数) のオブジェクト プロパティをCouchDB の map/reduce 関数に渡して、ドキュメント タイプごとに多数のビューを作成することなく、データベース内の一致するドキュメントを検索する方法があるかどうかを調べようとしています。

実行時に一致する目的のドキュメント プロパティ キーを CouchDB に渡して、一致するオブジェクト (またはページネーションに一致するオブジェクトの数) を返すことは可能ですか?

たとえば、あるページでdoc.user_id、 Xの が であるすべての投稿が必要ですdoc.published。doc.tags[]別のページでは、「スポーツ」というタグが付いたすべてのドキュメントが必要になる場合があります。