Windows Azureを使用して、モバイルソーシャルネットワーク用のサーバーバックエンドを構築しています。
私はこれらの3つのエンティティを持っています：
スレッドIDでパーティション化されたAzureテーブルにメッセージを格納するので、チャット（スレッドとの間でメッセージを送受信する）で優れたパフォーマンスが期待されます。
ただし、最新のスレッドのリストをユーザーに提供できるようにする必要もあります（recent =最新のメッセージが含まれています）。つまり、表示時に最後のメッセージ日付でスレッドを並べ替える必要があります。
多くの異なるテーブルパーティションをスキャンしてメッセージを探すことは明らかにパフォーマンスを低下させるため、最新のスレッドを効率的にフェッチできるようにするには、データを他のテーブルパーティションに非正規化する必要があります。
あなたの経験に基づいて、最良の戦略は何ですか？
編集：さらに考えた後、これがより良い提案です（私は思います）：
メッセージ ATS テーブルを 1 つ用意します。このテーブルには、送信メッセージと受信メッセージの 2 種類のメッセージが格納されます。ユーザーがメッセージを送信するたびに、それを「送信済み」として、次に「受信済み」(またはそれらのタイプと呼びたいもの) としてテーブルに保存します。
メッセージ テーブル内のすべてのメッセージを次のように分割します。
(UserId) - PartitionKey、(long.Max - Timestamp.Ticks) - RowKey
追加のプロパティとして、ThreadId、送信/受信の区別などを保存できます。
メッセージが問題なく 2 回挿入されることを保証したい場合は、Queue と Worker ロールを使用します。
このスキームは、ユーザーごとにすべてを分割します。そのユーザーとの間のすべてのメッセージを、ある時間範囲内で常に降順で表示できます。
バッチ プロセス ソリューションの選択は常に回避策であり、メインフレームのような古いコンピューティングを思い起こさせます。オンライン・リアルタイムシステムに代わるものはありません。
バッチ ソリューションを選択すると、起動時にシステムが時代遅れになり、将来の技術革新が妨げられます。
Azure データベースが大きくなりすぎてクエリを実行できない場合、Microsoft はフェデレーションを使用することをお勧めします。基本的には、データを複数のデータベースに分割し、互換性のあるアクセス ロジックをコードで利用することを意味します。
このデモ アプリを見て開始します: SQL Azure フェデレーション チュートリアル -- エンティティ フレームワーク