Redis Hashの深淵：データ構造の変遷と「走査」のコストを読み解く
RedisのHash型を単なる「連想配列」として捉えているのであれば、それはまだ入り口に過ぎない。大規模分散システムにおいて、我々が扱うのは単なるデータ構造ではなく、メモリ空間とCPUサイクルを極限まで削り出すための「戦場」だ。
今日は、Hashのフィールド操作（`HEXISTS`, `HKEYS`, `HVALS`, `HGETALL`, `HSCAN`）を切り口に、Redis内部で何が起きているのか、その「極限の知見」を紐解こう。
—
1. 内部表現の二面性：ziplistからlistpack、そしてhashtableへ
RedisのHashは、要素数と各要素のサイズに応じて、そのメモリレイアウトを劇的に変化させる。
- ziplist / listpack (メモリ効率の極致): 要素数が少なく、各値が小さい場合、Redisは連続したメモリ領域にデータを詰め込む。これはキャッシュラインの局所性を最大限に活かすためだ。しかし、この構造では`HEXISTS`や`HGETALL`は「線形探索」になる。O(N)だ。
- hashtable (スケーラビリティの確保): 閾値を超えると、Redisはdict（ハッシュテーブル）へ昇格させる。これで`HEXISTS`はO(1)になる。
アーキテクトの視点:
開発者は「HashはO(1)で動作する」と信じがちだが、データがziplist/listpackにある間は、全探索が発生していることを忘れてはならない。巨大なHashをziplistのまま運用するのは、CPUを焼き尽くす行為に他ならない。
—
2. `HGETALL`という「諸刃の剣」
`HGETALL`は、Hash内の全フィールドと値を一括で返す。これほど強力で、かつ危険なコマンドはない。
典型的なアンチパターン
100万フィールドあるHashに対してHGETALLを実行する
HGETALL user:session:12345
このコマンドは、Redisのシングルスレッド（正確にはメインスレッド）を完全にブロックする。データが転送される間、Redisは他のリクエストを一切処理できない。
極限の知見:
プロダクション環境で「要素数が予測できないHash」に対して`HGETALL`を叩くのは自殺行為だ。もし使用するのであれば、必ず`h-max-ziplist-entries`と`h-max-ziplist-value`の設定値を確認し、メモリ上でのレイアウトを把握した上で、データ量を制限する制約を設けるべきだ。
—
3. `HSCAN`：O(N)の地獄からの脱出
`HGETALL`の代わりとして用意されているのが`HSCAN`だ。これはカーソルベースの反復処理であり、Redisのメインスレッドを停止させずに走査を行うための唯一の正解である。
カーソル0から開始し、マッチング条件を絞る
COUNTを指定することで、1回のイテレーションで返す要素数を制御する
HSCAN user:session:12345 0 MATCH “user:” COUNT 100
なぜ `HSCAN` が必要なのか？
ハッシュテーブルがリハッシュ（拡張）されている最中であっても、`HSCAN`は一貫性のある（かつ重複を含む可能性がある）スナップショットを提供する。`HGETALL`が「全てか無か」のブロッキングを行うのに対し、`HSCAN`は「対話的」にデータを引き出す。
設計指針:
大規模なHashを扱う際、バッチ処理やデータ同期には必ず`HSCAN`を使用せよ。ただし、`COUNT`の値を大きくしすぎると、単一のコマンドが長時間実行され、結果としてブロッキングに近い遅延を生む。`COUNT`は10〜100程度から始め、レイテンシへの影響を計測してチューニングするのが定石だ。
—
4. `HEXISTS`：存在確認のコスト
`HEXISTS`はHashの特定のフィールドの有無を判定する。これは非常に優秀なコマンドだが、前述の通り内部構造がziplist/listpackである場合、データ量が増えると性能は低下する。
もし、高頻度で存在確認が必要かつ、データ量が数万件を超えるのであれば、Hashに固執せず、`SET`のキー構成や`Bloom Filter`（RedisBloomモジュール）の導入を検討すべきだ。
—
5. まとめ：アーキテクトとしてのアドバイス
1. 「要素数」を監視せよ: `MEMORY USAGE`コマンドや`OBJECT ENCODING`を用いて、現在Hashがどのような構造でメモリに展開されているかを常に可視化せよ。
2. `HGETALL`は禁じ手: ユーザーの入力や動的なデータ量に依存する箇所で`HGETALL`を使うな。必ず`HSCAN`でページングせよ。
3. データ構造の寿命を設計せよ: RedisのHashは「全フィールドを更新する」ようなユースケースには向かない。フィールドが肥大化しすぎたHashは、メモリの断片化（Fragmentation）を招き、パフォーマンスの低下を引き起こす。
Redisは単純なキーバリューストアではない。メモリの配置、CPUのキャッシュヒット率、そしてシングルスレッドモデルの限界を理解した者だけが、その真のポテンシャルを解放できるのだ。
さあ、コードを書き、ベンチマークをとり、そしてシステムが「限界」を超えた時に何が起きるかを肌で感じろ。それがエンジニアの到達点だ。
コメント