25

ソーシャルネットワーキングウェブサイトは、おそらくユーザー、友達、イベントのためのテーブルを維持しています...

これらのテーブルをどのように使用して、効率的かつスケーラブルな方法でフレンドイベントを計算しますか?

4

4 に答える 4

40

Twitter などのソーシャル ネットワーキング サイトの多くは、RDBMS をまったく使用せず、Message Queue アプリケーションを使用しています。それらの多くは、RabbitMQ のような既存のアプリケーションから始めます。それらのいくつかは、大幅にカスタマイズしたり、独自のものを構築したりする必要があるほど大きくなります。Twitter はこれを行うのは 2 回目です。

メッセージ キュー アプリケーションは、1 つのサービスからのメッセージを 1 つ以上の他のサービスに保持することによって機能します。たとえば、サービス Frank がキュー foo にメッセージを公開しているとします。Joe と Jill は、Franks の foo キューを購読しています。アプリケーションは、Joe または Jill がメッセージを受信したかどうかを追跡し、キューのすべてのサブスクライバーがメッセージを受信すると、そのメッセージを破棄します。フランクはメッセージを送信し、それを忘れます。Joe と Jill は foo からのメッセージを要求し、まだ受け取っていないメッセージを受け取ります。ジョーとジルは、メッセージに対して必要なことは何でもします。おそらくそれを維持することはおそらくないでしょう。

メッセージ キュー アプリケーションは、メッセージを受け取るはずのすべての人が、メッセージを要求したときにメッセージを受け取ることができることを保証します。パブリッシャーは、サブスクライバーが最終的にメッセージを取得できるという確信を持ってメッセージを送信できます。これには、完全に非同期であり、コストのかかる結合を必要としないという利点があります。

編集:通常、これらの種類のものを大規模に格納するストレージは、大幅に非正規化されていることにも言及する必要があります。したがって、Joe と Jill はまったく同じメッセージのコピーを保存している可能性があります。これは、アプリケーションを数十億のユーザーにスケーリングするのに役立つため、問題ないと見なされます。

他の読書:

  1. http://www.rabbitmq.com/
  2. http://qpid.apache.org/
于 2009-04-18T00:26:53.897 に答える
8

ソーシャル ネットワーキング サイトの主要なデータ構造はグラフです。Facebook では、グラフは無向です (あなたが誰かの友達である場合、その人もあなたが友達です)。Twitter では、グラフは方向性があります (あなたは誰かをフォローしていますが、彼らは必ずしもあなたをフォローしているとは限りません)。

グラフを表す 2 つの一般的な方法は、隣接リスト隣接行列です。

隣接リストは、グラフ上のエッジの単なるリストです。整数のユーザー ID を持つユーザーを考えてみましょう。

User1, User2
  1      2
  1      3
  2      3

これらのレコードの無向解釈は、ユーザー 1 はユーザー 2 および 3 とフレンドであり、ユーザー 2 はユーザー 3 ともフレンドであるというものです。

これをデータベース テーブルで表すのは簡単です。よく知られているのは、多対多の関係結合テーブルです。特定のユーザーの友達を見つけるための SQL クエリは、非常に簡単に作成できます。

特定のユーザーの友達がわかったので、これらの結果を更新テーブルに結合する必要があります。このテーブルには、ユーザー ID によって索引付けされたすべてのユーザーの更新が含まれています。

これらすべてのテーブルが適切にインデックス化されている限り、関心のある質問に答える効率的なクエリを簡単に設計できます。

于 2009-04-17T23:17:10.337 に答える
2

Travis はこれについて素晴らしい記事を書きました。

Rails と pfeed のアクティビティ ログとフレンド フィード

于 2009-08-21T07:02:50.253 に答える
0

小規模の場合、users.friends と users.events で結合を行い、クエリ キャッシングを行うことはおそらく問題ありませんが、友人やイベントが大きくなるとすぐに速度が低下します。ユーザーがイベントを作成するたびに、結合テーブル (おそらく「friends_events」と呼ばれる) にエントリが作成されるイベント ベースのモデルを試すこともできます。したがって、ユーザーが友達が作成したイベントを見たいときはいつでも、自分の ID と friends_events テーブルを結合して見つけることができます。このようにして、友人を持つすべてのユーザーを取得してから、その友人をイベント テーブルに参加させることを回避できます。

于 2009-04-17T23:05:50.160 に答える