ITmediaに「大規模サイトの舞台裏：大規模SNSのボトルネックとソリューション 」という記事が出ていました。
GREEの事例が載せられており、DBアクセスのボトルネックをどのように解決しているか紹介されています。
これは非常に勉強になりました。
DBサーバを分散しているわけですが、いくつかのテーブルごとにデータベースを別々のサーバに分けてるのには驚きました。
理由は、分散ファイルシステムのように、DBのデータが別々のサーバにあっても使う側から見ると1つのデータベースとして見えるような仕組みがあるからだと思ったからです。
調べてみると、パーティショニング（DBを分散させて使う側が1つのDBとしてみる方法）はOracleとかDB2とかSQL Server(Enterprise)等のエンタープライズに特化したDBしか機能が搭載されていないようです。
ということは、この記事ででてたOSSのMySQLはそのような機能はないようです。（と思ってましたが、最新のMySQL5.1(今年リリース?)ではパーティショニングが搭載されたようです。)
テーブルごとに別々のサーバに分けてるということはSQL文で JOIN が使えないということです。
1年で数千万レコードのテーブルということですが、SNSはすごいデータ量なんですね。
さらに、ソートというのはインデックスの意味がないため、これだけのレコード数になると非常にボトルネックになるようです。
(これはSQL Server2005の実行プランという面白い機能でも確認済みです。ただ単にソートするだけでも80%近くのコストがかかってます)
これらの対策として、GREEではアクセスがきてSQLを発行しデータ取得するのではなく、あらかじめデータが更新された時点で表示するためのページの部品を構築しておくという手法つまり、「フックを利用したイベント通知機構」とものらしいです。
ざっとしか見てないので、実装面は深く理解できてませんが、なかなかユニークなアプローチだと思いました。
確かにレスポンスを早くするための工夫は技術者としての力が求められる部分です。
この分野での力をつけていかないとプログラマとしての人生も短いなと実感しました。
余談ですが、今作ってるプロジェクトもSNSのマイページ的なものがあって新着情報をいろいろ出すのですが、いかんせんいくつものテーブルを見て結合しているため非常に表示が遅いです。(しかもまだデータが数百件レベルで。。)
仕方なしにNowLoadingとかいう画面を一枚はさんでる状態です。
まあ納期の問題とか担当が違うって点もあるんですが。。。
