memcached vs TokyoCabinet vs TokyoTyrant vs Redis

NoSQLの話題が周りで盛り上がっているので、有名どころのライブラリのset/getのベンチマークを取ってみることにしました。対象はmemcached, TokyoCabinet, TokyoTyrant, Redisの４種類。gemで入れたruby用のバインディングを利用して1000件のデータをset, getしています。結果はこんなかんじ。

	user	system	total	real
memcached:set	0.120000	0.030000	0.150000	( 0.213069)
memcached:get	0.150000	0.030000	0.180000	( 0.238989)
TokyoCabinet:set	0.000000	0.000000	0.000000	( 0.002802)
TokyoCabinet:get	0.000000	0.000000	0.000000	( 0.001759)
TokyoTyrant:set	0.010000	0.000000	0.010000	( 0.005384)
TokyoTyrant:get	0.030000	0.000000	0.030000	( 0.038285)
Redis:set	0.040000	0.030000	0.070000	( 0.147060)
Redis:get	0.040000	0.020000	0.060000	( 0.151168)

当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。

これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。

	user	system	total	real
memcache:set	0.120000	0.040000	0.160000	( 0.189803)
memcache:get	0.150000	0.030000	0.180000	( 0.240141)
TokyoTyrant:set	0.130000	0.030000	0.160000	( 0.238009)
TokyoTyrant:get	0.130000	0.020000	0.150000	( 0.271598)

TokyoTyrantのアクセス速度は一気に遅くなりました。やっぱりRuby実装に引きづられているみたいですね。。

ちなみに、Redisもsetに限るとmemcacheプロトコルと同じプロトコルを利用できるので、そのベンチをとってみると

	user	system	total	real
Redis:set	0.040000	0.010000	0.050000	( 0.091300)

と、なってmemcacheクライアントを利用したときのmemcached, TokyoTyrantと比較しても圧倒的に高速だということがわかりました（おもしろい！）

まとめ

• オンメモリだからmemcachedが高速、とは限らない
• memcache-clientは遅いので注意
• 各ライブラリのオリジナルのバインディングを利用した場合、高速順に並び替えるとTokyoCabinet, TokyoTyrant, Redis, memcachedになる

と、いうわけで、memcachedが高速なことを確認するためにベンチマーク取ってみたのですが、実装によってはまったく異なる結果になることが分かって、なかなかおもしろかったです。なお、今回利用したコードはgistに掲載しています。