最近、バイトでSpiderという面白いMySQL用ストレージエンジンをこねこねすることがあったので、特徴と感想を簡単に紹介します。
Spiderは少し特殊なストレージエンジンで、データを行単位で別のMySQLサーバへ飛ばして保存することができます。何が嬉しいかというと、比較的簡単にテーブルをSharding、つまり細切れにして負荷分散ができるということです。
Spider for MySQL
現在、MySQL 5.1以上で利用可能です。配布元はこちら：
Spider for MySQL in Launchpad
リリース状況などを掲載されている作者ブログはこちら：
Wild Growth 日本語
設定の流れ
- MySQLサーバ4つ（A, B, C, D)を用意する
- うちB, C, Dの3つにデータ保存用テーブルを作成する（InnoDBなどで）
- Aに、B, C, Dと同じスキーマでエンジンがSpiderなテーブルを作成する。データ保存先としてさっき作った3つのテーブルを指定する。
具体的な設定方法については公式ドキュメントや最後尾の参考リンクでどうぞ。
利用の流れ
ふつうにAのMySQLサーバにアクセスしてクエリを投げるだけです。クライアント（アプリ）側には一切変更の必要がありません。ここがSpiderの魅力です。
中で何が起こっているか
たとえばINSERT INTO users VALUES ('someone@domain.com', 'Bobby');というクエリをAに投げると、テーブル作成時に指定した条件に従ってSpiderがB, C, Dから保存先ノードを選び、そこへINSERTを投げ直してくれます。つまりSpiderテーブル自体はデータを一切持ちません。
同じくSELECTの場合もAへ投げたものがB, C, Dに飛び、Spiderが結果をまとめて返してくれます。
クライアント（アプリ）側からはあたかも普通にクエリを出して返って来ているように見えるんですが、実際には三つの保存先ノードへクエリが飛んでいるわけです。JOINなども同じように透過的に扱ってくれます。
リクエスト処理の負荷は分散出来ていませんが、データベースサーバの負荷のほとんどはIOだというウワサがありますので、そのIO負荷が分散できるというのはステキなことかも知れません。
実はぬるMySQLユーザな僕は全く知らなかったのですが、もともとパーティショニングという機能がMySQL 5.1以降で実装されています。これはテーブル内のデータを指定したカラムの値に基づいてローカルのファイルシステム内で分割して保存する機能です。Spiderはこのパーティショニングに乗っかって設計されていて、ここではB, C, DのテーブルをAのパーティションとして使っていることになります。
使用感
看板に偽りなしというか、できると言っただけのことはやってくれています。なにより本当にアプリ側を全く変えなくていいのが嬉しい。急にスケールしたくなったときなんかは採用しやすいソリューションかもという気がします。
ただ、パーティショニング機能自体の制限を受けるのがけっこう厄介です。これについてはまた別の記事に書きたいと思います。
あとは、オンラインに情報が少ないのが気になります。おそらくまだあまりユーザ数が多くないんだと思います。コンセプトは良いし実際に問題なく使えるんですが、現状では既知のバグや制限事項などが少ないので、どんな落とし穴が潜んでいるか分からない怖さがあります。
今後、いろんな人に試されて叩かれて強くなっていくことを密かに期待しておきます。
参考リンク
ウノウラボ Unoh Labs: 国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く
http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
作者によるMySQL Conferenceでのプレゼン資料(zipped pdf)。
The Data Charmer: Test driving the Spider storage engine – sharding for the masses
使ってみた系の記事。設定方法を紹介、どんなクエリが飛んでるかとかも見てます。
Sharding for the masses: Introducing the SPIDER storage engine (OpenSQLCamp @ FrOSCon) | Colin Charles Agenda
使ってみた系の記事。独自の説明プレゼンつき。
