blog.katsuma.tv
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real
redisを最速で導入するワンライナー - M_Ishikawa
memcachedとredisを比較したくて、まっさらサーバに入れてみる。redis編。 redisはキャッシュ保存をメモリとストレージとをハイブリッドでうまいことやってくれるKVS（Key Value Store）。 memcached並に高速（ちょいと遅い）で、memcachedのデメリットである揮発性（リブートでデータが消える）をなんとなく解決しています。 （なんとなくというのは、非同期でメモリからストレージへデータ整合処理を行なっているため、タイミングや設定によっては保証されない範囲がある。） YAPCで誰だったか忘れたけど登壇者がトラブル解決手段としての技の話をしているときに、ふと「今だったらredis使うだろうなー」と言ったのがずっと印象に残っていて、気になっていたのでした。 さて、本題の導入ワンライナー。 sudo yum -y install redis && servic
開発メモ: memcachedとKyoto Tycoonの空間効率
Kyoto CabinetおよびKyoto Tycoonに新たに導入された「StashDB」を使うとmemcachedよりも空間効率を向上させられるという話。 StashDBとは 前回の記事で説明したように、Kyoto CabinetではローカルMapReduceのキャッシュとしてTinyHashMapというクラスを実装して省メモリ化を図っている。丁寧にシリアライズしてデータを詰めていくとかなりメモリを節約できるものなのだ。 同じ構造をDBMのインターフェイスで実装したのがStashDBである。ProtoHashDB, ProtoTreeDB, CacheDB, GrassDB, HashDB, TreeDB, DirDB, ForestDBに続く第9番目のDBMということになる。もちろん、マルチスレッドセーフにして、レコード単位の粒度でロックを施して一貫性を確保し、VisitorやCur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
phpcassa get_range is too slow
