SNSのアルゴリズム、ロジックに関する質問です。

自分のFriendの更新情報が一覧できるページ(Home Page, Mypage的な)を効率的に表示するロジックについて言及されたページ、または書籍などを教えてください。


何も考えずに作ると以下のようになると思いますが、これだとユーザー数の増加に比例して、かなり負荷が高くなることが想像できます。

(1)自分のFriendのIDを全て取得
(2)取得した全IDで、日記などのレコードを検索
(3)更新日付が降順になるようソート
(4)表示


ある程度はバッチなどで回避できると思いますが、mixiなどは体感的に半リアルに近い更新速度のような気がします。このように高速でなおかつ負荷の低いロジックを教えてください。

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2009/02/24 19:25:02
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答3件)

id:hijk05 No.1

回答回数1307ベストアンサー獲得回数23

id:munyaX

ありがとうございます。

なつかしいですね、この記事はリアルタイムで見ていました。


良い記事ではあるのですが、いかんせんサイト全体のインフラの話に重点がおかれて、質問事項のロジックの話まで到達していないです。引き続きよろしくお願いします。

2009/02/17 20:16:41
id:rutta888 No.2

回答回数8ベストアンサー獲得回数2

ポイント32pt

SNSということで、相互に繋がっていることを認識できるという前提の下でしたら

閲覧側が更新を取るのではなく、更新側が教えてあげればよいかなと思います。

日記を例にすると。

1. Aが日記を更新。

2. Aのフレンドリストのユーザーを取得

3. 取得したユーザーに更新を通達

4-a. 更新通達を受けた時点でユーザーのページを更新

4-b. 更新通達を受けたユーザーがログインしたら更新

こうすることで、最低限必要な場所のみが参照されるようになると思います。

裏づけが書籍やwebでほしいということでしたらごめんなさい。

id:munyaX

ありがとうございます。

#裏付けはあればよし、無ければ処理フローを教えていただければ全く問題ないです。


>閲覧側が更新を取るのではなく、更新側が教えてあげればよいかなと思います。

確かに。

掲示板などでもそうですが、更新者よりも閲覧者が多い環境下では、この方法は確かに有効な気がします。更新者が最低でも1回は見ますものね。

ありがとうございます!

他にもあればよろしくお願いします。

2009/02/17 20:57:41
id:australiagc No.3

回答回数467ベストアンサー獲得回数90

ポイント32pt

これって、単に自動作成型のダイナミックRSSフィードを使ってるんじゃないですか・・・?

(1)Friendが日記などを更新 > friendのRSSがアップデートされる

(2)自分がログイン > 自分のFriendのIDを全て取得

(2)取得した全IDに該当するRSSフィードを取得

(3)フィードリーダーが順序、表示件数の設定に基づいて取得したRSSフィードを組み直す

(4)表示


参考文献で良いのがなかったのですが・・・こんな感じ?

http://www.tarosite.net/2005/06/snsrss.html

id:munyaX

これはクライアント側(JavaScriptなど)で処理する前提でしょうか?

であれば、ある程度の規模まで絞り込んだデータを送信して、後はクライアントまかせという考え方は、サーバ側の負荷の軽減にはなりそうですね。


> (1)Friendが日記などを更新 > friendのRSSがアップデートされる

> (2)自分がログイン > 自分のFriendのIDを全て取得

この仕様だと1,000人Friendがいた時、1RSS1人分の更新情報だと1回アクセスしただけで1,000回分のリクエストが走ることになりますから、サーバには優しくないというか、結構厳しいかもしれません。現実的には自分のIDを渡すと、Friend全員の更新情報が一定量返却されるとか、そんな仕様になるかもしれませんね。


面白い提案ありがとうございます!

イマジネーションが膨らみました。

2009/02/17 21:40:02
  • id:tsukasa57
    単純に考えると、「ユーザID,最後に日記を更新した日時」を含むテーブルAを用意しておいて、ユーザが日記を更新するとテーブルAも書き換わるようにしておけば、良いんじゃないでしょうか。そうすれば「(2)取得した全IDで、日記などのレコードを検索」で日記を調べなくても良くなると思うのですが...

    つまらない解答なのでコメント欄にて。

  • id:munyaX
    >tsukasa57さん
    ありがとうございます。

    テーブルAが、ユーザーのHomepageで表示するのに必要な情報が格納されているテーブル的なイメージですね。1ユーザー、1レコード的な。100人Friendがいたら100回INSERT(UPDATE)が発生するのですが、閲覧の方が多いであろうことを考えたら、そういった方法もありですね。

    これはちょっと盲点でしたw
    ありがとうございます!
  • id:australiagc
    あ、ちょっと裏付けっぽい(?)情報がありました〜。英文ですけど・・・facebookで自分のステータスのRSSを取得する方法だそうな↓
    http://www.techlifeweb.com/2008/12/16/how-to-find-your-facebook-status-rss-feed/
    facebookはアプリの更新情報なんかもあるので、RSSでできてるみたいなやつですから。
    ステータスに限らず、色んなRSSが取得できますね。

    ようは各ユーザーが更新情報を読む時にその都度検索するんじゃなくて、書き込みがされた時にはじめっから検索結果を作成しておいて、読む時にそれを引っ張って来てまとめるってなカンジでしょうか。
  • id:munyaX
    >australiagcさん
    ありがとうございます。

    これはFriendFeedなどの外部サービス向けのAPIとして公開されているものですよね。もしくは個人がRSSリーダーなどで購読するためのもののような気がします。
    http://friendfeed.com/

    今回の質問の意図は、あくまで低負荷、高速なSNSの構築ですので、主題と若干はずれてきてるかなぁという感じです。


    というのも、

    > ようは各ユーザーが更新情報を読む時にその都度検索するんじゃなくて、書き込み
    > がされた時にはじめっから検索結果を作成しておいて、読む時にそれを引っ張って
    > 来てまとめるってなカンジでしょうか。

    RSSとこの部分は関連してないかなぁという気もします。
    回答いただいた文中に「自動作成型のダイナミックRSSフィード」とあるように、RSSはDBから都度検索した結果を動的に出力することもできますので、出力するまでの過程においてはRSS=負荷軽減という結論には達しないかもです。

    つまり、

    (1)出力するデータを作成
    (2)
      a)HTMLで普通に出力するのと、
      b)RSSで出力

    2aと2bの違いを設けても、1の負荷は両方同じであるという意図です。

  • id:australiagc
    ああ、そりゃそうですね。
    すみません、正直サーバーの管理したこと無いんで頭回ってませんでした!

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません