チャット メッセージ用に大規模なサイト データベース アーキテクチャを構築する方法を理解したい (例 facebook.com または gmail.com)
すべてのメッセージを 1 つのテーブルに格納することは不可能であるため、メッセージは別のテーブルに再分散されていると思います。その理由は、膨大な量ですよね? （そして、ここではパーティショニングはできないと思います）
では、異なるテーブルにメッセージを再配布するために使用されるロジックは何ですか? いくつかのバリアントがありますが、どれも最適なバリアントではないと思います。一般的に、これについてあなたがどう思うか興味がありますか? また、これに関する良い記事を知っている場合は、リンクを投稿してください。
OK、問題はデータセットをどのように分割するかです。これについて考える最も簡単な（そして多くの場合最良の）方法は、アクセスパターンを検討することです。どのメッセージがすぐに必要か、どのメッセージが遅くなる可能性があるか、そしてそれぞれをどのように管理するか。
一般に、古いメッセージは、低ネットワーク速度/低メモリ/非常に大きなストレージノード（マルチテラバイト）で保持できます。
新しいメッセージは、高帯域幅ネットワーク/高メモリ/低ストレージノードにある必要があります（ギガバイトで十分です）。
トラフィックが増加するにつれて、低速ノードにストレージを追加し、高速ノードにノードを追加する必要があります（水平方向にスケーリング）。
毎晩（またはより頻繁に）、古いメッセージを履歴データベースにコピーし、現在のデータベースからメッセージを削除できます。クエリは2つのデータベースをアドレス指定する必要があるかもしれませんが、これはそれほど問題ではありません。
スケールアウトするとき、データはおそらくシャーディングする必要があります。つまり、データ値で分割する必要があります。ユーザーIDの分割は理にかなっています。生活を楽にするために、会話のすべての側面を各ユーザーと一緒に保存することができます。これにはタイムバケットテキストを使用することをお勧めします（ディスクアクセスは通常4k境界にあります）が、これは最初は複雑すぎるかもしれません。
クエリは、正しいデータベースに対してクエリを実行できるように、ユーザーを認識する必要があります。簡単なルックアップテーブルが役に立ちます。
もう1つの方法は、メッセージを途中で圧縮し、途中で解凍することです。テキストは簡単に圧縮され、CPUを少し増やすだけでスループットが2倍になる可能性があります。
多くのNoSQLデータベースは、このような大変な作業の多くを実行しますが、現在のシステムの容量がなくなるまで、知っているテクノロジに固執することをお勧めします。
幸運を！
少し前に、reddit が小さなものから大きなものまでどのように行ったかという記事がありました。彼らにはユーザーメッセージシステムがありませんが、これは膨大な量のデータを含む多くのシナリオでうまくいくと思います http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building -reddit-to-270-million-page.html
編集：データベースに関する「興味深い」部分は＃3です-スキーマについて心配しないでください..すべてに2つのテーブルを使用します。モノとデータ。
Facebook は、一部のストレージ (ドキュメント データベース) にApache Cassandraを使用し、 memcachedを多用して拡張性を高めています。
FBのナットとボルトについてはこちら。また、 FB 開発者ニュースで宝石を見つけることもできます。