【テクニカル・上級編】 String型：数値演算 – Redis

Redisの数値演算：アトミック性の裏側と、メモリ効率を極限まで高める設計哲学

Redisにおける `INCR` 系のコマンドは、単なる「カウンタ」としての便利ツールではない。これは、Redisがシングルスレッドのイベントループモデルを採用しているからこそ実現できる、メモリ上の極めて軽量なアトミック・オペレーションである。

多くのエンジニアが「便利だ」という理由だけでこれらを使っているが、真のアーキテクトであれば、その背後で何が起きているか、そしてどうすればメモリとCPUのコストを極限まで削ぎ落とせるかを理解しておく必要がある。

—

1. アトミック性の真実：なぜロックが不要なのか

RDBMSにおいて `UPDATE table SET count = count + 1` を実行する際、行ロック（Row Lock）やMVCCのオーバーヘッドが避けられない。一方、Redisの `INCR` は、Redisがシングルスレッド（正確にはメインのコマンド処理スレッド）で動作するという特性を逆手に取っている。

コマンドが実行される瞬間、Redisは他のあらゆる操作を遮断し、単一のメモリ書き換えを実行する。

競合なし： ネットワークスタックからコマンドがデコードされた時点で、結果は確定する。
ゼロ・ロック： ロック待ちによるコンテキストスイッチが発生しない。これが、Redisが極めて高いスループットを維持できる理由だ。

2. 内部表現の「動的最適化」：数値か、文字列か

ここからが本題だ。Redisの `String` 型は、実は数値型ではない。内部的には `robj` (Redis Object) 構造体として保持されており、値が数値として解釈可能な場合、Redisは内部的に `long` 型のバイナリ値として最適化する。

// Redisソースコードの断片的な概念イメージ
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4; // ここが重要
unsigned lru:LRU_BITS;
int refcount;
void ptr;
} robj;

もしあなたが `SET counter “100”` と送った場合、Redisはこれを文字列として保存するが、`INCR` を呼び出した瞬間に `encoding` が `OBJ_ENCODING_INT` に切り替わり、メモリ上では整数値として直接演算される。

アーキテクトへの教訓：
無駄に文字列型で数値を保持し、変換を繰り返す必要はない。Redisは自動的に最適な `encoding` を選択する。特に、小さな整数（`OBJ_ENCODING_INT`）であれば、ポインタの参照すら不要な「共有整数」として管理され、メモリ使用量はほぼゼロに近い状態まで圧縮される。

3. INCRBYFLOATの落とし穴と精度

`INCRBYFLOAT` は便利だが、浮動小数点演算特有の「精度問題」には注意が必要だ。Redisは内部で `long double` を使用して計算を行う。

0.1を足し続けると、いずれ精度誤差が顕在化する
INCRBYFLOAT balance 0.1
数万回繰り返すと、期待値と浮動小数点のビット表現に乖離が生じる可能性がある

金融系や厳密なカウンタを構築する場合、「固定小数点数」として扱うのが鉄則だ。金額なら `1.23` ではなく `123`（セント単位）で保存し、全て `INCRBY` で整数演算を行うこと。これだけで、浮動小数点の再変換コストと精度の不安から完全に解放される。

4. パフォーマンスの境界：パイプライニングの活用

`INCR` は1回あたりのコストは極小だが、ネットワーク・ラウンドトリップ（RTT）は無視できない。もし1万回のインクリメントをループで送っているなら、それは設計の敗北だ。

アンチパターン：RTTを1万回発生させている
for _ in range(10000):
r.incr(“counter”)

改善案：パイプラインで一括送信し、RTTを1回に集約する
pipe = r.pipeline()
for _ in range(10000):
pipe.incr(“counter”)
pipe.execute()

パイプラインを使用することで、Redis側の処理能力を最大化し、ネットワーク帯域の無駄を排除できる。

結論：Redisを「超高速な計算機」として使いこなせ

`INCR` 系のコマンドは、Redisというデータベースの「本質」を体現している。
1. 可能な限り整数で扱うこと（メモリ効率の最大化）。
2. アトミック性を信じてロックを実装しないこと（複雑性の排除）。
3. 浮動小数点は避けること（精度とパフォーマンスの担保）。

RedisはただのKVSではない。適切に使えば、それは極めて強力で、かつ並列処理の悪夢からエンジニアを解放してくれる「計算エンジン」となる。

あなたが次に `INCR` を打つとき、その裏側にある `robj` が華麗に `OBJ_ENCODING_INT` へと切り替わる様子を想像してほしい。それこそが、アーキテクトが持つべき視座だ。