私は数日前にRavenDBを使い始めました。私はこれまでのところそれが好きですが、私はNoSQLの世界全体ではかなり新しいです。従来のRDBMSに比べて、パターン（または他のDocumentDBや他のNoSQLのデータストアなど）をいつ利用するかを考えようとしています。私は、「文書や構造化されていない/動的に構造化されたデータを格納する必要があるときにはDocumentDBを選択する」と理解していますが、それはあまりにも一般的なものです。インスタントメッセージを格納するためのリレーショナルデータベースまたはドキュメントデータベース多分何か？
なぜですか？私が読んだことで、人々は電子商取引アプリケーションの注文詳細などの「ドキュメント」の例を書いており、ワークフロー管理アプリケーションの詳細を書いていました。しかし、これは、数量、総価格、割引などの注文の詳細が完全に構造化されているなど、あまり問題のない年月のRDBMSで開発されています。
ここには重複があると思います。しかし今、私は一般何を使うべきかのアドバイスを求めていません。なぜなら、私にとって最高のものは、実験を通して自分自身でそれを理解することだと思うからです。だから私は懸念と一緒に具体的な事例について尋ねるつもりだ。
Facebookのメッセージングシステムのように、年齢を重ねてメッセージを保存するインスタントメッセンジャーアプリケーションを開発しようとします。ここではRDBMSを使うのは適切ではないと思います。これに対する私の理由は、ほとんどのpoepleは、このようなインスタント・メッセージング・システムを使用することである：
- A：こんにちは
- B：ちょっと
- A：どのようにU rは？
- B：いいですか？
- A：私の2
- ...
注意する事はとてもこのような構造を持つ単一の行にそれぞれ格納し、ほとんどのメッセージは非常に短いということである。
Messages(fromUserId, toUserId, sent, content)
感じます「実際の有用な情報（コンテンツ）」は非常に小さいのに対し、テーブルには大量の行が含まれているためインデックスが膨大になるため、非常に効果がありません。これにメッセージが頻繁に送信されるという事実を加味すると、インデックスのサイズはパフォーマンスに大きな影響を与えます。したがって、非常に大量の行を管理して格納する必要がありますが、すべての行には最小限の実際の情報が含まれていなければなりません。 RavenDBで
、私はこのような構造を使用します。ユーザーAとユーザーの間で1：このような構成で
// a Conversation object
{
"FirstUserId": "users/19395",
"SecondUserId": "users/19396",
"Messages": [
{
"Order": 0,
"Sender": "Second",
"Sent": "2016-04-02T19:27:35.8140061",
"Content": "lijhuttj t bdjiqzu "
},
{
"Order": 1,
"Sender": "Second",
"Sent": "2016-04-02T19:27:35.8200960",
"Content": "pekuon eul co"
}
]
}
を、私は私が探していた会話を見つける必要がありますB。 ユーザとユーザB間の任意のメッセージは関係なくユーザーかどう又はユーザBが送信者であった、このオブジェクトに格納されています。だから私はそれらの間の会話を見つけると - 実際のメッセージよりもはるかに少ない会合がある - 私はそれに関連するすべてのメッセージをつかむことができます。
しかし、2人の参加者が多く話すと（メッセージが3年と言われていると仮定すると）、1つの会話に数万のメッセージがあり、オブジェクトが非常に大きくなる可能性があります。
しかし、それがRavenDBでどのように（特に）動作するかわからないことが1つあります。内部のストレージとクエリのメカニズムは、オブジェクト全体を読み取らずに（例えば、クライアントではなくDBエンジンが）最新の50個のメッセージを取得できるだけですか？ Afterallは、オブジェクトのプロパティにインデックスを使用していますが、オブジェクトの部分の読み取りがDB側で可能かどうかについての情報は見つかりませんでした。 （つまり、DBエンジンがディスクからオブジェクト全体を読み取ることなく、それを解析し、必要な部分だけをクライアントに送り返すことなしに）。
可能であれば、このシナリオではRavenを使うのが良い選択肢だと思いますが、そうでない場合はわかりません。ですから、この特定のシナリオに最も適したDBモデルについてのアドバイスとともに、前の段落で述べた問題に答えることで、クリーンアップを手伝ってください。 RDBMS？ DocDB？多分何か？
ありがとうございました。
私は主要な区別がされると言うでしょう
他のIMアプリケーションを見ると、私にとってはこれのための最良のストレージがイベントストアのようなものだと結論づけることができます。エンドポイント接続イベント・ストリーム・チェックポイントを持つと、簡単に同期が可能になります。 –
@AlexeyZimarev氏によると、イベントストアはおそらく良いだろう。ドキュメントモデルを使用すると、会話の両方の参加者が常に同じドキュメントに書き込むため、並行性の問題が発生する可能性があります。また、処理されない場合、長い会話では文書が制御不能になる可能性があります –