Tokyo Cabinet の1億件時のランダムアクセスベンチマーク
他にはあんまり見当たらない1億件時のベンチマーク。
・・・よく見たらmikioさん自身が公開していた。
SSD との比較ということでの公開だけど、参考になる。
数万 qps の数字が出ることが多い 100 万件時に比べ、
100万件 → 数万 qps
1000万件 → 6500 qps
1億件 → 700 qps
という性能の低下がはっきり見て取れる。
結局、データがファイルシステムのキャッシュに乗るか乗らないか、それ次第ということ。
もちろんキャッシュ無しで 700 qps は論理限界値というか、これ以上は出ない数字ではあるだろう。おそらくインデックスは全部メモリに乗ってて、データだけが物理ディスクにある状態なんだと思う。
でまあ、今お客さんに「500 qps で最終的に1億件・・・」と言われて困っている私が居るわけなんだけども。
当初の件数は少ないんで、楽天技研の ROMA みたいなスケールアウトが楽ちんなものを使うのが順当なのかなあ。TC をエンジンに使うことも出来るし。
でも、こういう製品を Ruby で組む必然性というか、合理性というか、が理解出来なくていまいち使う気になれない・・・。
SSD は無理っす。さすがにまだ使える土壌が・・・。
当初は件数少ないことが分かっているので、とりあえずこのままやってもらって、足りなくなってきてから 64bit OS 使って無理やりメモリに納めてもらう、もしくは、ROMA みたいなので分散、という方向かなと思っている。(なので、プロトコルは memcached プロトコルがいいんだろう)
足りなくなることなんて、もし実際発生したとしても数年後の話だと私は思っているので、今から先回りで高いハードを買うなんて、たとえそれが数十万円の話であっても、アホらしい・・・。
