第2回 MariaDB/MySQL コミュニティ イベント in Tokyo に行ってきました
2014/02/18に 第2回 MariaDB/MySQL コミュニティ イベント in Tokyo に行ってきました。
懇親会ではMontyさんと写真を撮ったり、色々なプラグインの開発者の方とお会いしたりでとても有意義な会でした。
MariaDBカンファレンスの感想
Montyさんがお見えになっていたこともあり、主題はMariaDBの紹介でした。簡単に言うと「MySQL5.6は出来が悪いよ。」「MariaDB10.0は品質、機能ともにMySQL5.6よりいいよ!」という感じでした。具体的には、
- MySQL5.6のGTIDは設計がダメなので使えない。MariaDB10では設計を変更し完全に書き直している。
- MariaDBは10.0より前からオプティマイザを改良していて、MySQLより5~ 20%位は速い、場合によっては10倍といったこともある。
- バグが少なく、コミュニティからのフィードバックを積極的に受け入れサポート熱心。
一方の主張だけなので話半分くらいに聞いたとしても、MariaDBの方がいいのかな?といった印象を受けました。あと、多くの大口ユーザーやLinuxディストリビューションがMariaDBに移行したり、移行の予定を宣言している事例があげられました。ただ、その多くは実際の移行はまだこれからという感じでした。
MariaDB FEEDBACK PLUGIN
今まで知らなかったのですが、MariaDBの動作環境や構成をMariaDB Foundationに送信するための「MariaDB FEEDBACK PLUGIN」というプラグインがあり、集まった統計情報はWebで誰でも見られるようになっているそうです。
すべてのMariaDBインスタンスでこのプラグインが有効になっているわけではないですが、興味深い情報が見られます。
HandlerSocketの樋口さんとお話ししてきました!
いろいろな話をさせていただいたのですが、「SQLは得意ではない」は面白かったです。自分も樋口さんと同様、SQLは苦手で、「オプティマイザに依存すると検索パフォーマンスが読みづらい」という点で全く同じ意見でした。
HandlerSocket 2.0 と Transactd 狙いの違い
樋口さんは、HandlerSocketの検索条件の指定内容の強化とJoinを進められるとのことでした。
対してTransactdはと言いますと、1つのテーブルに対する検索条件はほぼ完全なのでこのままです。サーバー側でJoinする予定はいまのところありません(クライアント側でします)。
サーバー側でJoinをしてしまうと、テーブル単位でのシンプルなサーバー分割ができなくなってしまいます。ではなぜ樋口さんはJoinの実装を進められるかというと、NoSQLのメリットよりも、高速なSQL代替を狙っておられるようです。実際、ユニークインデックスでのJoinはSQLよりもかなり高速にできるようです。NoSQLのメリットを重視しているTransactdとは狙っているものがやや異なっていますが、Transactdでもやれば同じように出来るな、と思いました。
MroongaやSpiderの斯波さんと少しだけお話ししてきました
SpiderがHandler Interfaceに対応されたとのことで、Transactdも大丈夫かな?と思いお聞きしたとことろ、主にHandler Interfaceの下で動作しているので「たぶん大丈夫ですよ」とのこと。thdからの情報もかなり利用されるとのことで、うまくいかない場合はTransactdからthdへの情報提供を確認すれば良さそうです。今後確認していきたいと思います。
オプティマイザの神話
いろいろな方とお話しする中で、「テーブルアクセスは検索対象(範囲)のインデックスがあるか、無いかしかない。無い場合は、フルスキャンまたは範囲スキャンしかない」ということはあまり知られていないと感じました。ISAMライクなテーブルにインデックスを使ってナビゲートするプログラムを開発した経験のない方は、SQLしか使ったことが無い場合が多いでしょうから、やむを得ないのかも知れません。
中には「オプティマイザは想像を絶するミラクルなアクセスをしてくれる!」「まさかフルスキャンなんてしないだろう」と考えている方もいらっしゃるようです。
また、「少し複雑なSQL文になると、NoSQLだけでは自分(のプログラムコード)で同じ結果を得ることはできない」とも思われているようで(できないものは無いのですが)、TransactdなどNoSQLの利用の「カベ」はそのような誤解にあるとも思いました。
そしてTransactdは
今回のイベントの参加で、Transactdの今後の方向性もより明確に出来たように思っています。
アプリケーションの多くは テーブルの1レコード ≒ オブジェクトの1インスタンス という関連を持たせています。ところがテーブルをJoinすると、そのデータは「どのオブジェクトなのか」?どれでもない中途半端なものになります。このため、Transactdが提供する「テーブル単位のみのアクセス」は、O/Rマッピングとはとても相性の良いものになります。
また、Transactdを使うにあたり多くの方にとって障害になるのは、JoinやOrderByといった処理をどうするかということです。そのような点を踏まえて今後は、
といったことを中心に進めていきたいと思います。
これだけでは抽象的なので、C++の一例をあげます。
まずはパフォーマンスを読めるようなAPI。「idが10000から10100且つstatusが1のユーザー」をusersオブジェクトに読み取ります。usersはuserのコレクションです。
std::vector<user> users; query.where("id", "<", 10100).and("status", "=", 1).reject(0); userTable.index(key_id).keyValue(10000).read(users, query);
次はJoin相当の例です。userクラスにはそのユーザーが属するグループのオブジェクトを包含しています。user::grp()
でグループオブジェクトが返るとします。例ではグループオブジェクトのデータを全ては読み取らず、nameのみ読み取っています。
query.select(_T("id"), _T("name")) groupTable.index(key_id).readEach(users, &user::grp, query);
これでuser情報と所属するgroup名を読み取りました。
こんな感じのAPIを、C++だけでなくPHPなどにも用意していきたいと思います。
あ、それと、MariaDB-10.0.8用Trnasactdバイナリをダウンロードできるようにしておきました。
皆さんも是非mariaDB-10.0.8でTransactd 1.2を試してみてください。