テキストデータの分離だけではデータ量の増加に耐え切れない場合、次の手としてはテーブルの分散があります。これは概念としては非常に単純で、結合していないテーブルを別のサーバへ切り出すだけです。例えばmainというデータベースにリスト3のようなテーブルがあるケースでは、blogやphoto、mailといったテーブルを別のデータベースサーバへ分散させることが可能です(リスト4)。
mainデータベース:
+----------------+
| Tables_in_main |
+----------------+
| user |
| profile |
| preference |
| blog |
| photo |
| mail |
+----------------+
mainデータベース : blogデータベース : photoデータベース: mailデータベース:
+----------------+ +----------------+ +----------------+ +----------------+
| Tables_in_main | | Tables_in_blog | | Tables_in_photo| | Tables_in_mail |
+----------------+ +----------------+ +----------------+ +----------------+
| user | | blog | | photo | | mail |
| profile | +----------------+ +----------------+ +----------------+
| preference |
+----------------+
ただし、例えば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
というクエリは、
という2つのクエリに分割して発行することになります。
重要なのは、いかにこれをアプリケーション側で煩雑にせずに処理するか、ということになりますが、GREEの場合はこうしたJOINはユーザー情報テーブルに関係するものがほとんどなので、ユーザーIDを含む配列に、必要なユーザー情報の追加メソッドを利用することで問題を解決しています。
例えばリスト6のようなコードでリスト7のような配列を取得できるので、リスト8などとして配列にユーザー情報を付加します。appendUserInfo()メソッドでは、配列を走査して必要なユーザー情報を取得します。この結果、リスト9のような配列が得られ、JOINと同様の結果を比較的シンプルに取得できます。また、場合によってはデータアクセスレイヤーでこれを吸収するのもよいかもしれません。
こういった対策によって、メモリを数Gバイト積んでいる最近のサーバでしたらパフォーマンスを維持できると思います(相当な規模にならない限りは)。ただし、この手法はJOINを多岐にわたって利用している場合や、現在はJOINをしていなくても将来的にJOINをしたくなった場合に高コストとなる点に注意が必要です。従ってGREEでは、アプリケーション構築時にある程度テーブル分割(後述)を想定し、データアクセス部分を設計しています。
データベースにおいて、複数のテーブルで共通するフィールドに同じ値があった場合に、レコードを結合するSQL構文。
Copyright © ITmedia, Inc. All Rights Reserved.