大規模SNS実現のためのGREEのアプローチ：大規模サイトの舞台裏（4/5 ページ）

[藤本真樹，ITmedia]

テーブルの分割（パーティーショニング）

図2　テーブルの分割（分割キー）

　ここまでに挙げた手法は、比較的低コストで十分な効果を得ることができますが、リニアにデータが増大していくようなテーブルが存在する場合には、当然ながらある時点でスケーラビリティが失われてしまいます。

　そういった場合、例えばblogテーブルがどうしようもなく肥大化していった場合には、テーブル自体を分割していくことになります（図2）。テーブルを分割する際には分割キーと分割メソッドという2点について考える必要があります。

分割キー

　分割キーは、単純に「テーブルを何で分割するか？」ということです。例えばブログのエントリを格納しているテーブルでは、ユーザーIDをキーにするか、ブログのエントリIDをキーにするか、という2つの選択肢が考えられます（実際、ブログではユーザーIDで分割していくのが一般的なようです。つまり、同じスキーマを持つテーブルAにはユーザーIDが1〜10000のデータが、テーブルBにはユーザーIDが10001〜20000のデータが、といった感じです）。

　当然ですが、この手法はテーブルが分割され、そのテーブルを格納するデータベースサーバ自体も分散していくので、分割されたテーブルをまたがるような処理は非常にコストが掛かってきますし、トランザクションを張ることもできません。こういった制限とリスクを考えて、何をキーにしてテーブルを分割していくかを決定する必要があります。

分割メソッド

図3　テーブルの分割（分割メソッド）

　分割メソッドは、「テーブルをどう分割するか？」ということです。例えばブログテーブルをユーザーIDで分割していく場合には「どのユーザーIDはどのテーブルに置くのか」を決定するルールを決めなければなりません。これは大きく分けて、アルゴリズムを利用するか、マッピングデータを利用するか、という2つの方法があります（図3）。

　アルゴリズムを利用する場合は、最も単純な方法だと「ユーザーIDをN（＝分割数）で割りその剰余でマッピング」という形になります。アルゴリズムベースだと、マッピングのコストは非常に低くなりますが、逆に「あるテーブルのサイズが大きくなってしまったので、このユーザーIDのデータを別のテーブルに」といった運用処理のコストが非常に高くなります。

　逆に、データベースに図3のAのようなテーブルを用意し、「あるユーザーIDのブログのデータがどのテーブルにあるか」というルールをデータとして持つと、マッピングのコストは多少高くなりますが、テーブル間のデータの移動などの運用処理は楽になります。

　これら2つの手法にはそれぞれメリットとデメリットがありますので、分割するデータの性質によって適したものを選択していくとよいでしょう（とはいえ、GREEではいまのところアルゴリズムベースのマッピングを行っていません）。

　GREEでは以上のような形でのアプローチを取っていますが*、もちろんこれだけが唯一の方法ではありませんし、テーブル結合ができなくなったり、トランザクションを張れないというようにアプリケーションへの負担やリスクが発生してきます。このようなリスクを避けるため、データを分散しつつ、アプリケーションから透過的に扱えるとベスト*なのですが、これは結構難しいです。*

　さて、データ分割の手法を解説してきましたが、資金に余裕があるならば、性能の高いサーバを導入するのも有効です。2008年8月現在、32Gバイト程度のメモリを持つサーバが数十万円で購入できるので、これらを利用すればテーブルの分割をかなり抑えることができます。また、アプリケーション側ではなくRDBMSのクラスタリング機能を利用するのも当然有効な手段です（ここしばらくでオープンソースのRDBMSでも、クラスタリングの機構がだいぶ成熟してきたように感じます）。

　以上に加えて最も重要なのは、やみくもに問題を解決しようとするのではなく、現象をしっかりと見据えて「何が問題なのか」をしっかりと把握することです。もしかするとアプリケーションの仕様を少し変更するだけで多くの作業が不要になるかもしれませんし、まったく違うアプローチが可能かもしれません。

このページで出てきた専門用語

GREEでは以上のような形でのアプローチを取っていますが

すべてのアイデアがオリジナルなわけでもなく、国内外で公開されている事例や、米国の大きなサービスの状況などをヒアリングした上での1つの解（海の向こう側でも割と似たようなことをしている模様だ）。

データを分散しつつ……、アプリケーションから透過的に扱えるとベスト

この部分は、実はまだGREEでも整備が進んでいない……。