Redisはメモリが溢れた時に仮想メモリを使用するようだ。 単純なIn Memoryデータベースだと思っていたので、用途が限られると思っていた。 データが全てメモリに載りきらない応用にも使えるんじゃないかなぁ。

以下は、redis-serverを少ないメモリ容量のサーバで動かした時の様子。

PID   USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  739 kiyoka    18   0  146m  98m 3672 S    0  2.4   0:34.84 sekka-server
  497 kiyoka    15   0  814m  46m  624 R    0  1.1   3:18.34 redis-server

memcachedと“正反対”、Redisが仮想メモリをサポート RedisはCで各種データ構造を実装したものをデーモンとしたようなソフトウェ アで、リード・ライトともに非常に高速なのが特徴。ただ、実メモリに乗り 切らないデータセットは扱えないことから利用局面が限定的だった。バージョ ン2.0では、新たに独自に仮想メモリ機構を実装。実メモリに乗り切らないデー タをディスクへ書き出す仕組みを取り入れた。

これはOSのスワップの仕組みそのものだが、Redisでは、あえて独自で実装し たという（実装にはLinuxカーネルを参考にしたという）。理由の1つは、デー タ構造が分かっている分、シリアライゼーションによる圧縮効果が高く（最 大で10倍程度）、OSに依存するよりもはるかに効率がよくなること。もう1つ の理由は、キー・バリューのうち、キーだけはすべてメモリ上に保持すると いう設計が可能なため。キーがすべてメモリに乗っていることから、Redisの 高速性は保たれるというわけだ。また実際のバリューのほうがいくら大きく なっても、メモリ消費量はキーの数にだけ依存することになり、100万キー当 たり160MBのメモリ消費で済むという。

なるほど、キーだけメモリ上に置くというのは工夫だなぁ。独自で実装する意味あり。

こちらは詳細に仕様が書かれている。やはり効率良く仮想メモリを管理できるように独自に実装された仕様のようだ。 仮想メモリ技術仕様 — redis v2.0.3 documentation もうひとつの重要な仮想メモリの属性として、 vm_max_memory があります。 このパラメータはスワップのトリガーを設定するために重要となります。 Redisは、このメモリの設定値を超えた メモリを使用した場合にのみ、スワップを行おうとします。この値に到達しな い場合は、スワップの必要はないものとして動作します。

同じ実メモリ容量を使った状態でも体感速度は、Tokyo CabinetよりもRedisのほうが軽く感じる。(Tokyo Cabinetが64MByteでRedisが上記の46MByteを消費した状態の場合) [Sekka]は最後に確定した変換候補を記憶するために辞書ストレージに頻繁に書き込みにいくが、Tokyo Cabinetのほうは即座にDiskにsyncしようするのに対して、Redisのほうは遅延させているのだろうと推測している。 [Sekka]の場合、最悪学習データがDiskに書き込まれずにサーバが落ちても致命的な問題にならない程度の重要度なのでRedisは[Sekka]向きだ。

実際に使ってみればいろいろ工夫が見えて勉強になる。何事も実践あるのみだね。