ndbmtdのmtとはズバリ、マルチスレッドである。つまりndbmtdとはマルチスレッド版ndbdなのだ。
えっ?!ndbdってシングルスレッドプログラムだったの??って思ったね、そこの貴方!!実はそうなんです。シングルスレッドだったんです。
例えが適切かどうかは微妙であるが、memcachedも以前はシングルスレッドプログラムであり、それでもかなりの性能を出してきたという実績がある。ndbdも同じで、シングルスレッドであるにも係わらず高速に動作してきたのだ。メインのボトルネックはネットワークI/Oであり、CPUが問題になることはあまりなかったし、負荷が増えた場合にはノード(ホスト)を増やせば良かった。だがしかし、昨今のCPUの動向を見ると、マルチコア化が激しく進んでいる。1台のホストに4コア以上載ってて当たり前!の時代になったのである。なのにシングルスレッドなデーモンではあまりにも勿体ないではないか。(そしてMySQL Clusterのライセンスは、シングルスレッドなのにCPU単位の課金というお茶目ぶりである。)
というわけでndbdmtdが誕生したのである。
Jonasのブログによると、彼らが実施したベンチマークにおいてndbmtdはなんとndbdの3.7倍ものスループットを叩きだしたということである。
これは驚きではないか?!
しかしなぜ3.7倍なのだろうか。これにはワケがある。(キーワードはロックフリーだ。)
ndbdは元々がシングルスレッドプログラムだったので、マルチスレッドといえども極端にマルチスレッドで並列処理ができるようになるわけではない。ndbmtdのマルチスレッド化のストラテジは、機能ごとにスレッドを分けて、その中でもさらに並列化出来るところはマルチスレッド化するというものである。その結果、以下のようなスレッド構成になったのである。
- トランスポーター(TR)x1
- トランザクション・コーディネーター(TC)x1
- ローカル・クエリ・ハンドラー(LQH)x4
そう。つまり3.7倍というのは、LQHが4つあるからというのが根拠なのである。LQHスレッドが4つというのは、LQHが扱うデータ構造によるもので、データが4つに分かれているからである。各LQHスレッドは、自身のデータセットだけを扱う。LQH、TC、TRの各スレッドはそれぞれメッセージングにより通信をするので、ロックをかける必要がない。なのでロックによるオーバーヘッドが生じない。おそらくこれがLQHスレッドの数にほぼ比例してndbmtdの性能がスケールした理由だろう。ロックフリーの方が効率が良いのである。
というわけで、3.7倍のスループットをたたき出すMySQL Cluster 6.4に乞うご期待!!
0 件のコメント:
コメントを投稿