tugela cacheをとある所(本番)で使い始めた。
格納するデータ量は数百万レコード程度、数十プロセスに
分散してWWWサーバー上に起動し、一日あたり数百万リクエストに応えてる。
今のところ問題なし。
BerkeleyDBのサイズが結構大きくなりがちなようなので(※)、
大量にデータを格納する人はあらかじめ多めに分散させておくと良。
しかし、tugelaってググってもあんまり「使ってます」的な記事がないなぁ。
用途にもよるけど、単純なプロダクトなのでちょっとお勧め。
もっとも、最近はgreeの中の人が
![Flared (Yet Another Memcached) - GREE Labs http://labs.gree.jp/Top/OpenSource/Flared.html](http://kwout.com/cutout/6/yy/yj/bqs_bor_rou_sha.jpg)
のようなプロダクトを開発されているようなので、そちらを試してみても
良いかもしれない。tugelaはバージョンとまってるしなー。笑
memcachedのプロトコル(の、単純なget/setのみ)でやり取りしているので、
バックエンドのプロダクトを切り替えたとしても既存のコードを修正する
必要が無いし、ほんと楽。
(※):1レコードの平均サイズ×レコード数から算出したサイズより20%くらい大きい。
ちなみに今は1プロセス分でDBサイズが500M~600Mくらい。
■追記:
なにやらmixiの中の人も同じようなことをやってる...
![mixi Engineers’ Blog http://alpha.mixi.co.jp/blog](http://kwout.com/cutout/f/ki/5a/z8p_bor_rou_sha.jpg)
![mixi Engineers’ Blog http://alpha.mixi.co.jp/blog](http://kwout.com/cutout/7/tv/qs/2uk_bor_rou_sha.jpg)
大体考えることはみんな一緒ですな。
格納するデータ量は数百万レコード程度、数十プロセスに
分散してWWWサーバー上に起動し、一日あたり数百万リクエストに応えてる。
今のところ問題なし。
BerkeleyDBのサイズが結構大きくなりがちなようなので(※)、
大量にデータを格納する人はあらかじめ多めに分散させておくと良。
しかし、tugelaってググってもあんまり「使ってます」的な記事がないなぁ。
用途にもよるけど、単純なプロダクトなのでちょっとお勧め。
もっとも、最近はgreeの中の人が
![Flared (Yet Another Memcached) - GREE Labs http://labs.gree.jp/Top/OpenSource/Flared.html](http://kwout.com/cutout/6/yy/yj/bqs_bor_rou_sha.jpg)
のようなプロダクトを開発されているようなので、そちらを試してみても
良いかもしれない。tugelaはバージョンとまってるしなー。笑
memcachedのプロトコル(の、単純なget/setのみ)でやり取りしているので、
バックエンドのプロダクトを切り替えたとしても既存のコードを修正する
必要が無いし、ほんと楽。
(※):1レコードの平均サイズ×レコード数から算出したサイズより20%くらい大きい。
ちなみに今は1プロセス分でDBサイズが500M~600Mくらい。
■追記:
なにやらmixiの中の人も同じようなことをやってる...
![mixi Engineers’ Blog http://alpha.mixi.co.jp/blog](http://kwout.com/cutout/f/ki/5a/z8p_bor_rou_sha.jpg)
![mixi Engineers’ Blog http://alpha.mixi.co.jp/blog](http://kwout.com/cutout/7/tv/qs/2uk_bor_rou_sha.jpg)
大体考えることはみんな一緒ですな。