【テクニカル・上級編】 Hash型：基本操作 – Redis

Redis Hashの深淵：メモリ最適化と内部表現の冷徹な現実

Redisの `Hash` 型を単なる「キー・バリューの入れ物」だと思っているなら、今すぐその認識を改めるべきだ。

大規模な分散システムを設計する際、メモリ消費量とアクセスのレイテンシは死活問題となる。特にHash型は、オブジェクトをシリアライズして文字列として保存するアンチパターンと、Redisの内部構造を理解した上での運用で、パフォーマンスに数倍から数十倍の差がつく。

今日は、Redisの心臓部である `ziplist` と `hashtable` の挙動、そしてそれが実務のメモリ効率にどう直結するかを、徹底的に解剖する。

—

1. 内部構造の二面性：ziplist vs hashtable

RedisのHashは、要素数と各値のサイズに応じて、内部で表現形式を劇的に変化させる。この「動的な切り替え」こそが、Redisのメモリ効率の秘密だ。

ziplist (圧縮リスト)

要素数が少なく、各フィールドや値が短い場合、Redisは `ziplist` という連続したメモリ領域を使用する。

特徴: ポインタオーバーヘッドを極限まで排除し、メモリを極めてコンパクトに詰め込む。
代償: 要素数が増えると検索時間が $O(N)$ になる。

hashtable (辞書構造)

`hash-max-ziplist-entries` や `hash-max-ziplist-value` の閾値を超えると、Redisは即座に `hashtable` へと昇格させる。

特徴: $O(1)$ の高速検索を実現する。
代償: ポインタやハッシュテーブルのバケット維持のため、メモリ消費量は跳ね上がる。

アーキテクトの視点:
この切り替え閾値をデフォルトから安易に変更してはならない。メモリに余裕があるからといって `hashtable` を強制すれば、CPUキャッシュミスが増大し、かえって低レイテンシ環境を破壊する。

—

2. オブジェクト保存の極意：JSON文字列か、Hashか？

多くのエンジニアが犯すミスは、「JSONを文字列化してSETする」ことだ。これには以下の弊害がある。
1. 部分更新不可: 1フィールド変えるために、巨大なオブジェクト全体を読み込み、デシリアライズし、更新して書き戻す必要がある（RMWサイクル）。
2. メモリ効率: Redisのオブジェクト圧縮アルゴリズム（特に `ziplist` へのパッキング）の恩恵を一切受けられない。

推奨されるアプローチ：HSETの活用

フィールドごとに属性を分解して格納せよ。

悪い例: JSON文字列として保存
SET user:1001 ‘{“name”:”Alice”,”age”:30,”email”:”alice@example.com”}’

良い例: Hash型でフィールドごとに管理
内部的にziplistとして最適化されやすく、特定フィールドのみの更新が可能
HSET user:1001 name “Alice” age 30 email “alice@example.com”

特定フィールドのみの更新（ネットワーク帯域とCPU負荷を最小化）
HSET user:1001 age 31

—

3. 実務での悲劇を防ぐためのメモリ設計

`HMSET` (現在では `HSET` に統合) や `HMGET` を使う際、考慮すべきは「アトミック性」と「ネットワーク・ラウンドトリップ」だ。

メモリのパッキングを意識した運用

`HDEL` でフィールドを削除しても、`ziplist` がすぐに圧縮・縮小されるわけではない。メモリのフラグメンテーション（断片化）は、長期間運用する大規模システムにおいて確実に攻撃的な挙動を見せる。

複数のフィールドを一度に更新することで、コマンドのオーバーヘッドを減らす
ただし、パイプライン化とどちらが適切かは、キーの局所性を見て判断すべき
HSET user:1001 name “Alice” age 31 email “alice@example.com”

全フィールドの取得
HGETALL user:1001
注意: フィールド数が数千に及ぶとHGETALLはブロッキングを引き起こす
巨大なHashはHSCANでカーソルを用いてイテレーションするのが鉄則

—

4. 伝説のアーキテクトからの提言

Hash型を扱う上で、以下の3点を常に脳裏に焼き付けておいてほしい。

1. メモリの断片化を恐れろ: `ziplist` から `hashtable` への変換は不可逆である。一度巨大なハッシュを作ると、要素を減らしてもメモリはすぐには解放されない。キーの寿命と要素数を設計段階で厳密に定義せよ。
2. キーの命名規則: `user:{id}:profile` のように階層化することで、Redisのキー空間を論理的に整理し、将来的なクラスタリング（ハッシュスロットの分散）に対応しやすくする。
3. 監視の徹底: `MEMORY USAGE` コマンドを使い、特定のHashがどの程度のメモリを食っているか、定常的にモニタリングしろ。`encoding` が `ziplist` か `hashtable` かを把握していない運用は、盲目で高速道路を走るようなものだ。

Redisは単なるKVSではない。メモリを操作するための高機能な演算エンジンだ。そのメカニズムを理解し、データ構造を設計する。それこそが、大規模トラフィックを捌くエンジニアの最低条件である。

極限のパフォーマンスを求めるなら、まずは `DEBUG OBJECT` コマンドで内部のエンコーディングを覗くことから始めよ。そこには、君が想像もしなかった「Redisの真実」が眠っているはずだ。