Twitterの仕組みです。
といっても、6年前の記事になるため、現在とは大きく異なっているかもしれませんが、以下の記事の内容についての質問です。
http://www.atmarkit.co.jp/news/201004/19/twitter.html
初めの方にパーティショニングの話があります。
そのメリットは「分割すればするほどレスポンスが上がり、1つ1つのDBのサイズも抑えられる。」です。
そして、この記事ではTwitterは最終的に月ごとに分割する方法を採用しているそうです。
つまり、4月のツイート、5月のツイート、6月のツイート、、
のようにツイートごとにデータベースを用意しているらしいのですが、実質的には、時間的に近い月のツイートを保持するデータベースにクエリは集中するらしいです。
今が10月なら、10月のツイートを保持するデータベースにクエリが集中するのは自然なことのように思えます。
しかし、これって先ほど述べたメリットを満たしてないような気がするのですが、どうでしょうか?
つまり、「分割すればするほどレスポンスが上がる」と考えられるのですが、ほとんど全てのユーザーから発行されるクエリが単一のデータベースに対して発行されるなら、レスポンスは上がらないように思えるのです。
また、
「もう1つの工夫は、フォローと被フォローの関係をそれぞれ別にデータに持つこと。論理的には片方向のグラフだけ持っておけば十分だが、あえて「誰をフォローしているか」「誰にフォローされているか」に分けてデータ化しておく。データの整合性に気を付ける必要はあるものの、こうしておけばクエリは特定パーティションへのアクセスで完結するため、メモリに乗り切らないという問題も解消するのだという。
こうした仕組みにより、書き込み側のデッドロック(すべてのつぶやきは巨大な単一のデータセットに放り込まれる)を解消しつつソーシャル・グラフがメモリに乗り切らないという課題を乗り越えて、リアルタイム性の高いサービスを実現できている。」
タイムラインの話で、フォローと非フォローの関係をデータとして保持する、という話がありました。
このようにすることでメモリが乗り切らなくなる、とあるのですが、このようにしても、従来のSQLと変わらないのではないでしょうか?
従来のSQLですと、友達が増えすぎると、メモリに乗らなくなるわけですが、フォローしているユーザーをデータとして保持したところで、結局それをメモリに載せることになるのではないでしょうか?
そうすると、このようにフォローと被フォローの関係をデータとして保持したところで、フォローしている人が多いなら、結局メモリに乗らなくなってしまうのではないでしょうか?
また、「書き込み側のデッドロックを解消」とありますが、これもフォローと被フォローの関係をデータとして保持するから得られるのでしょうか?
その相関がよくわかりませんでした。
どなたか、回答(解説といった方が適切かもしれません)お願いします。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。