SNSのフォロー機能のテーブル構成を考えてみる

DB設計の楽しさに気付いていろんなWebサービスのDB構成を考えています。

今回は、SNSのフォロー機能または、友達機能についてを考えてみます。

スポンサーリンク

フォロー機能を使うパターン

フォロー機能とは、自分が気になった相手をフォローする機能です。

フォローすると相手の投稿が自分のタイムラインに表示されるので相手のページに進まなくてもよくなります。

ツイッターやFacebook、インスタグラムなどSNSにはほぼこの機能が備わっています。

フォロー機能を使うパターンを考えてみます。

・自分をフォローしているユーザー一覧

・自分がフォローしているユーザー一覧

 

スポンサーリンク

RDBテーブル構成

テーブル一個でできました。

followers
- id
-user_id (フォローをするユーザーのID)
-follower_id (フォローされたユーザーのID)

このテーブルがあれば上記の機能をすべて実現できます。

follower_idに自分のID、follow_user_idにフォローする相手のIDを格納します。

 

自分のフォロワーを取得

SELECT FROM followers 
  JOIN INNER users
  ON followers.user_id = user.id
  WHERE follower_id = "自分のID"

 

自分がフォローしているユーザーを取得

SELECT FROM followers
  JOIN INNER users
  ON follow.follower_id = user.id
  WHERE user_id = “自分のID”

 

ツイッターはフォローと被フォローのテーブルを分けている

フォローと被フォローの関係をそれぞれ別にデータに持つこと。論理的には片方向のグラフだけ持っておけば十分だが、あえて「誰をフォローしているか」「誰にフォローされているか」に分けてデータ化しておく。データの整合性に気を付ける必要はあるものの、こうしておけばクエリは特定パーティションへのアクセスで完結するため、メモリに乗り切らないという問題も解消するのだという。

http://www.atmarkit.co.jp/news/201004/19/twitter.html

ツイッター並の規模になるならこういった構成に変えないといけませんね。

 

スポンサーリンク

RDBは関係データの扱いに向いていないのでグラフDBを使う

RDBはフォロー関係のようなグラフデータ構造の扱いが不得意なので、それに適したデータベースを使いましょう。

グラフDBは関係データを保存するのが得意なデータベースです。

グラフDBを使えば「フォローしている人がフォローしているユーザー」などSQLでは難しいものも簡単に取得できます。

Neo4jというデータベースは比較的使いやすく、Cypherクエリも直感的にかけるのでおすすめです。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です