日々常々

ふつうのプログラマがあたりまえにしたいこと。

MySQL勉強会in大阪 MySQL+memcached のメモまとめ

2010/12/07に行われた、MySQL勉強会in大阪 http://atnd.org/events/10210 に行ってきました。会場は日本オラクル株式会社西日本支社。「夜な夜な!なにわオラクル塾」で行った事があるので、今回は迷子時間を考えずに行きました。初めて行く場所は普通に迷子になるので、いつもは三十分前くらいにつくようにしてたりします。お題は「MySQL + memcached」です。memcachedは「メムキャッシュディ」と発音するようで、最後のdはデーモンのdだとか。

私の前提知識

私のMySQL知識は殆どありません。業務でも趣味でも殆ど使ったことがありません。なもんで、何で行くのかと聞かれても何となく出しかありません。SunがMySQLを買収したときは「今後Java案件でMySQL使うこと増えるのかなー」とか思って勉強しようと思ったりもしたのですが、その直後にORACLEのSun買収で私の中では有耶無耶になりました。でもMySQLの採用率はどんどん上がっているようで、日本では日本語ドキュメントの充実度とかからPostgreSQLのほうが多かったようですが、2009年の調査からひっくり返っているようです。でもMySQLGUIクライアントがいまひとつなのがにんともかんとも。

MySQLについて

脱線した。「MySQL勉強会」と題している通り、メインはMySQLです。開始時間前の雑談の内容が濃くて、なかなかに面白かったです。殆ど着いていけませんでしたが。MySQLについては、ORACLEも色々宣言や発表をしているように今後も開発は続けられていくようなので、一応は安心していいと思います。ORACLEになってからテストが厳しくなったようですが、その分品質も上がってるとか何とか。ただ、SunやORACLEによる買収はあったものの、開発チーム自体は殆ど無関係に独立して動いているらしいです。そんな中でもMySQL次期バージョン5.5がリリースを間近に控え、今後もCommunty版(無料なやつ)も提供は続けられていくとの事でとりあえず安心(?)してよさそうです。

memcacedについて

話はmemcachedに移ります。ざっくりした説明になりますが、私はmemcachedって言葉自体をこの勉強会の案内で初めてみたくらいなので。

  • memcachedMySQLの機能ではなく単独の独立したシステム
  • 非常にシンプルで、バイナリを入れて起動するだけ
  • メモリがあればどこでも動く*1
  • サーバはキャッシュするだけなのでクライアントでがんばる必要がある*2
  • 出来ない事を把握する必要がある*3

また、複数構成による分散も出来るのだけれども、サーバは相互に何もしないからクライアントが頑張る必要があるようです。本当にmemcached自体はキーに対するデータをメモリ上にキャッシュするだけの仕組みのようです。これだと素直にKVSを使ったほうがいい気もしたり。memcachedクライアントの実装についても分散の実現方法だとかの説明がありましたが、この辺りは説明も駆け足でしたし省略させてもらいます。*4

MySQL + memcached のやりかた

単純なものとして、アプリケーション側で対処するリードパススルーと呼ばれるものがあります。Wikipediaのサンプルコードがこれにあたるのかな。アクセスがあった場合、とりあえずmemcachedにアクセスして、あたらそれを使う。なかったらDB検索して結果をmemcachedに格納する。この方式だと二回目以降のアクセスが高速になるのは判りやすい。しかしながら欠点もあって、アプリケーション側のSQLを発行している部分を同様に実装しないといけない事や、DB側の更新を検知し辛い事などが挙げられます。
この点を解決する案として、MySQLにはUDF(ユーザ定義関数)と言うものがあります。UDFは外部のC言語で書かれたプログラムをFUNCTIONとして扱えるもので、そのまま CREATE FUNCTION 文で作成できます。このFUNCTIONをTRIGGERにセットすれば、テーブルの更新契機でmemcachedにコマンドを発行する事が出来ます。deleteして次回アクセス時にaddさせてもよいでしょうし、replaceしても良いでしょう。この方法を使うためには libmemcached というライブラリがあるので、それを利用すればいいとか。

他にはmemcachedに手を加える方法。こちらは全てのDBアクセスをmemcached経由で行い、変更したmemcached側でDBアクセスするかキャッシュから返すかなどの振り分けを行います。ただ、memcachedサーバに負荷がかかり、キャッシュサーバなのにこいつが落ちたら動かないーなんてこともあるかも知れません。memcachedからDBを更新させるとか中々にアクロバティックな気もします。

究極系と言われていたのが、MySQLのストレージエンジン自体に手を入れる方法。MySQLからmemcachedを操作させる感じですね。memcachedはAPとDBの間に入るものかなーと聞いていただけに乱暴な事をするもんだ、なんて思いました。この方法だと秒間1,300万クエリを処理出来ているとかぶっ飛んだ話をされていました気がします。それでも特殊な例でもなく、結構多くの所でこの方法は使われていて、memcachedに手を入れるのとMySQLに手を入れるのでは、大体半々くらいの感じのようです。

MySQL Cluster

ここまでがmemcached。番外としてMySQL Clusterのお話もされていました。MySQL ClusterはMySQLを2台1組として、複数組をまとめて1つのDataBaseとして扱うものであり、HDDに例えるならば RAID 1+0 にあたるような構成。NDB APIと言うのを使うと、KVSのような使い方が出来るらしいです。
今後どうなるかは私には見えていませんが、もしKVSが主流になったとして、MySQLはこの辺りで生き残るのかもしれません。

感想

MySQLとかよく判らんしーとか思いながら行きましたけど、思った以上に面白かったです。業務で使うかと言われると、今のところ予定はありませんし、趣味でも使うかと言われると中々難しいところです。ですけれど、話として単純に面白かったので大満足です。知的好奇心とかそっちのほうが満たされた「何かわかった気になった」で終わる気がしないでもないですが、なんとか使えそうな場面を見つけたら検討してみようと思います。検討する選択肢を増やすことが出来ただけでもプラスとしておきましょうかね。

*1:WebサーバでもDBサーバでも単独サーバでも。Wikipediaだとかfacebookだとかは単独サーバ大量構成らしい。

*2:私の感覚ではDBよりはAPに近く感じました。

*3:キャッシュなんでダンプとかとれない。フェイルオーバーとかもない。ユーザ認証もないのでファイアウォールの内側にあるのが前提、とか。

*4:この辺りはJCMKでの分散KVS"okuyama"のお話と被ってたりして、理解がおっつきました。岩瀬さんの丁寧な説明に感謝感謝。