大規模SNS実現のためのGREEのアプローチ:大規模サイトの舞台裏(3/5 ページ)
大規模なサイトでは、どのようにWebアプリケーションをスケーラブルに構築しているのか。GREEのアプローチを、グリー取締役CTOにして、PHPフレームワークEthna(えすな)の開発者でもある藤本真樹氏が解説する。Webアプリケーション開発者必見だ。
テーブルの分散
テキストデータの分離だけではデータ量の増加に耐え切れない場合、次の手としてはテーブルの分散があります。これは概念としては非常に単純で、結合していないテーブルを別のサーバへ切り出すだけです。例えばmainというデータベースにリスト3のようなテーブルがあるケースでは、blogやphoto、mailといったテーブルを別のデータベースサーバへ分散させることが可能です(リスト4)。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ただし、例えばuserテーブルとblogテーブルをJOIN*させるようなクエリがあった場合には、アプリケーション側でこれを行うように変更する必要があります。つまり、
SELECT user.user_name, blog.title FROM user LEFT JOIN blog ON user.user_id=blog.blog_id WHERE user.user_id=1
というクエリは、
- SELECT title FROM blog WHERE user_id=1
- SELECT user_name FROM user WHERE user_id=1
という2つのクエリに分割して発行することになります。
重要なのは、いかにこれをアプリケーション側で煩雑にせずに処理するか、ということになりますが、GREEの場合はこうしたJOINはユーザー情報テーブルに関係するものがほとんどなので、ユーザーIDを含む配列に、必要なユーザー情報の追加メソッドを利用することで問題を解決しています。
例えばリスト6のようなコードでリスト7のような配列を取得できるので、リスト8などとして配列にユーザー情報を付加します。appendUserInfo()メソッドでは、配列を走査して必要なユーザー情報を取得します。この結果、リスト9のような配列が得られ、JOINと同様の結果を比較的シンプルに取得できます。また、場合によってはデータアクセスレイヤーでこれを吸収するのもよいかもしれません。
こういった対策によって、メモリを数Gバイト積んでいる最近のサーバでしたらパフォーマンスを維持できると思います(相当な規模にならない限りは)。ただし、この手法はJOINを多岐にわたって利用している場合や、現在はJOINをしていなくても将来的にJOINをしたくなった場合に高コストとなる点に注意が必要です。従ってGREEでは、アプリケーション構築時にある程度テーブル分割(後述)を想定し、データアクセス部分を設計しています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このページで出てきた専門用語
JOIN
データベースにおいて、複数のテーブルで共通するフィールドに同じ値があった場合に、レコードを結合するSQL構文。
Copyright © ITmedia, Inc. All Rights Reserved.