← nanocached docs

nanocached容量プランナー

ワークロードとクラスタ構成からキャッシュヒット率を見積もり、目標に必要なメモリと TTL を逆算します。メモリを削ればヒット率が下がり、TTL を短くしても下がる — その釣り合いを数字で見るための道具です。

ワークロード
B
B
req/s

偏り = Zipf 分布の指数。Web 系アクセスは 0.9 前後が定番です。

鮮度

0 や空欄は不可。無期限にしたい場合は大きな値(例: 86400)を。

クラスタ
MiB
目標
%
予測ヒット率
実効容量
TTL上限ヒット率
メモリ無限でもここまで
容量上限ヒット率
TTL無限でもここまで

ヒット率 × ノードメモリ(現在の TTL で固定)

ヒット率 × TTL(現在のメモリで固定)

目標 90% への推奨

前提と近似について
  • アクセスは Zipf 分布(指数 α)+ポアソン到着、キャッシュは cache-aside(ミス時にアプリが再投入し TTL リセット)を仮定。
  • ヒット率はキー i ごとに hi = λiτ / (1 + λiτ)、τ = min(LRU 特性時間, TTL) の近似(Che 近似の TTL 拡張)。±数%の目安であり保証値ではありません。
  • エントリのメモリはキー長+値長+管理オーバーヘッド 112 B で概算。nanocached の会計(キー+値のみ)より実態寄りです。
  • 実効容量 = ノード数 × ノードメモリ ÷ R(複製コピーも同じメモリを消費するため)。分布は均等(HRW は偏差 2% 未満)とみなします。
  • ノード障害・rebalance 中の一時的なヒット率低下、書き込み比率の影響は含みません。