実例をもとに、もう少し具体的に考えてみよう。第1章では、Twitterっぽいメッセージングサービスを実装するとしたら...ということを考えた。読み込み操作の中でいちばん多いのが、いわゆる「ホームタイムライン」の表示リクエストだろう。自分がフォローしているすべてのユーザーの最近のツイート(と、ユーザー名やアイコン画像)を表示するものだ(図1-17参照)。そんな場合に使うSQLクエリを図1-18で見たが、あんなのを毎回実行するのでは速度が遅くなってしまうという結論だった。事前にホームタイムラインの内容を算出して取得しておけば、ユーザーからのリクエストにすぐに答えられるようになる。なんとなくマテリアライズドビューっぽく聞こえないだろうか?Twitter並みの規模でマテリアライズドビューを作れるデータベースは存在しない。ストリームプロセッシングツールを使えば、マテリアライズドタイムラインを実装できる*1。その概要を図5-20に示す*2。ストリームプロセッシングツールを用いたTwitterタイムラインの実装まずはすべてのデータソースをイベントストリームとして扱えるようにしなければいけない。そのためには、第3章でとりあげたCDCを用いるか、あるいは第2章で考えたようにイベントを直接ログに書き出せばいい。今回の例では、これら三つのデータソースからのイベントストリームを利用する。Tweets個々のツイートやリツイートがイベントとなる。ふつうに考えれば、これらはストリームとして扱えるものだ。profilesユーザーが表示名やプロフィール画像を変更するたびに、更新イベントが発生する。このストリームはログ圧縮しておく必要がある。すれば、すべてのユーザーの最新のプロファイルをストリームから再構築できるようになる。graph誰かが他のユーザーをフォローしたりフォロー解除したりしたときにイベントが発生する。このストリームの履歴をたどれば、ある時点で誰が誰をフォローしているかを判断できる。これらのストリームをKafkaに入れれば、マテリアライズドビューを作れる。StreamsあるいはSamzaを使って、ストリームプロセッシングジョブを書けばいい。count"を作れる。ストリームをjoinすることもできる。profilesをjoinした結果は、一連のツイートに非正規化されたプロファイル情報(ユーザー名やプロファイル画像など)がぶらさがったストリームになる。(まあ過去にさかのぼってすべて更新するのは非効率的だろうけど、そのへんはなんとでもなるでしょう)。次に、ツイートとフォロワーをjoinしてみよう。イベントをとりまとめれば、あるユーザーXをフォローしているユーザーのリストを作ることができる。(Twitterではこれを"fan-out"*3と呼んでいる)。「ホーム」タイムラインはいわばメイルボックスのようなもの。次にログインしたときにユーザーが見るべきすべてのツイートが、そこに含まれている。ここでは、図1-18のSQLに相当するマテリアライズドビューを効率的に作った。注目すべきは、SQLのふたつのjoinが図5-20におけるストリームのjoinに対応していること。ストリームプロセッシングシステムは、いわばクエリを継続的に実行し続けているようなもの。サーバー調整のため長時間アクセスできない状況が続き、ご迷惑をおかけして申し訳ありませんでした。現在は復旧しております。問題がありましたら、不具合報告までご連絡をお願いします。