導入

こんにちはhagurereです。
今回はtwitterを設計してみました。

要件

今回の要件は以下です。

以上の要件と考慮事項をもとに設計をしていきますがまず最初RDBだけで設計してみようと思います。
以下がざっと書いてみたE-R図です。

シンプルでわかりやすいDB設計ですね

このDB設計ですとタイムラインの一覧表示は以下のようなクエリで行うことができます。

SELECT * 
FROM tweets
WHERE user_id 
IN (SELECT followed_id 
    FROM follows
    WHERE follower_id = ?)
ORDER BY created_at DESC

スレッドの表示だと以下

SELECT *
FROM replies
WHERE tweet_id = ?
ORDER BY created_at DESC

一見簡潔でよく見えますがこのDB設計、クエリですと以下のような問題点が出てきます。

上の問題点を改善したDB設計にしてみました。

Tweetが作成されるたびにフォロワーの数Timelineテーブルにレコードを作成します
このようにすることでリツイート、引用リツイートに簡単に対応できますし以下のような軽いクエリでタイムライン一覧を取り出すことができます。

SLECT * 
FROM timelines 
INNER JOIN tweets
ON tweets.id = timelines.tweet_id
WHERE user_id = ?
ORDER BY created_at DESC

ただこちらにもデメリットはあります。
tweetの作成時フォロワーの数だけレコードを作成する。
つまり1000フォロワーなら1000レコード, 10000フォロワーなら10000レコード作成されてしまうということです。

RDBに一気に何千, 何万レコードの作成はかなりのコストがかかりますが大量のデータを扱うように作られたNoSQLならそこまでのコストにせずに可能です。
twitterではmemcachedを使っている（使っていた？）ようですが今回はDynamoDBを使います

DynamoDBを使って最適化させたDB構成が以下です

PKがパーティションキー, SKがソートキーです。
NoSQLにはリレーションがないので取り出したTimeline一覧にアプリケーション内でTweetをアタッチしてあげる必要がありますが最大30件程度ならそこまでコストにならないと思います。

実際のtwitterが今どのような構造で動いているかはわかりませんが10年前はこんな感じの構造で動いていたみたいです。
今はこんな感じじゃないのかとかここはこうしたらもっとよくないかとかのご指摘、ご質問があったらぜひ送ってください！