こんにちは！ Redisの奥深い世界へようこそ。
今日は、Redisのデータ構造の中でも、実務で本当によく使われる「ハッシュ型（Hash）」のメモリ最適化について、徹底的に噛み砕いてお話ししますね。
「Redisはメモリが命」と言われます。サーバーのメモリコストを抑えつつ、パフォーマンスを限界まで引き出すための秘訣は、実はこのハッシュ型の内部構造をどう理解し、どう設定するかにあるんです。
難しそうに聞こえるかもしれませんが、心配いりません。日常の例えを交えながら、優しく、そして本質的なところまで案内していきますね。ここをクリアすれば、あなたのRedisの使いこなしレベルは間違いなく一皮剥けますよ！
—
1. Redisのハッシュ型って、現実世界で言うと何？
まず、Redisのハッシュ型がどんなものかイメージしてみましょう。
プログラムの世界では「連想配列」とか「辞書（Dictionary）」なんて呼ばれますが、もっと身近な例えで考えてみます。
例えば、会社の「社員名簿のカード」をイメージしてください。
1枚のカード（これがRedisの「キー」にあたります）の中に、次のような項目が書き込まれています。
- `name`: 田中太郎
- `age`: 28
- `department`: 開発部
Redisのハッシュ型は、まさにこの「1つのキーの中に、複数の『フィールド（項目名）』と『値（データ）』のペアを保存できる箱」なんです。
普通に作ると、メモリはどう使われる？
通常、ユーザーごとに別々のキー（例: `user:100:name`、`user:100:age`……）を作ると、キー名自体の管理コストが重くのしかかり、メモリが無駄に消費されてしまいます。
しかし、ハッシュ型を使えば `user:100` という1つのキーの中にデータをまとめられるため、メモリ効率がぐっと良くなります。……が、実はRedisの内部では、「データの持ち方」によってメモリ消費量が天と地ほど変わるという秘密があるんです。
—
2. 知られざる変身能力：「ziplist（ジップリスト）」の魔法
ここからが本題です。Redisは、メモリを極限まで節約するために、データ量が少ないうちは「ziplist（圧縮リスト）」という超コンパクトな特殊フォーマットに変身します。
これまた日常の例えで説明しましょう。
- 通常のデータ構造（お弁当箱）：
大きなお弁当箱に、ご飯エリア、おかずエリア、デザートエリアがしっかり分かれていて、それぞれスペースが固定されている状態。すき間が多いと無駄が出ますよね。
- ziplist（巻き寿司）：
具材を海苔でギュッとひと巻きにして、隙間なく一体化させてコンパクトに持ち運ぶ状態。
Redisのハッシュも、データが少ないうちは、この「巻き寿司」スタイル（ziplist）でメモリ上に連続してペタッと配置されます。ポインタ（データの場所を示す目印）のオーバーヘッドがないため、メモリを劇的に節約できるのです。
しかし、データが大きくなりすぎると、この巻き寿司をほどいて、通常のお弁当箱スタイル（ハッシュテーブル）に衣替えします。
—
3. 運命の分かれ道：`hash-max-ziplist-entries` の正体
ここで登場するのが、今回のテーマの核心である設定パラメータ、`hash-max-ziplist-entries` です。
これは日本語に訳すと、「ziplist（圧縮リスト）のままでいられる、フィールド数の限界値」という意味になります。
デフォルトでは、大抵このように設定されています（redis.confより）。
hash-max-ziplist-entries 512
hash-max-ziplist-entries 64 # 古いバージョンや環境によってはこっちの場合も
「ひとつのハッシュの中に、フィールドがいくつまでなら、コンパクトなziplist形式を維持していいか」という境界線です。
なぜこの設定がメモリに影響するのか？
もし、あなたのアプリケーションが「1つのハッシュに、常に100個のフィールドを入れる」という仕様だったとします。
もし設定がデフォルトの `512` なら、ずっとコンパクトな「巻き寿司」状態でメモリに優しく鎮座します。
しかし、もし何かの拍子にこの制限を優に超えるような巨大なハッシュ（例えば、1つのハッシュに1万個のフィールド）を作ってしまうとどうなるでしょう？
Redisは慌ててそれを通常のお弁当箱（ハッシュテーブル）に変換します。その瞬間、メモリの消費量がパッと跳ね上がります。
逆に、「うちのデータはせいぜい5〜10個のフィールドしか持たないよ」という場合は、この設定を少し見直すことで、無駄なメモリ確保を防ぎ、CPUのキャッシュ効率も高めることができるのです。
—
4. 実務で活かす！ フィールド名と値の「ケチケチ」最適化術
さて、ハッシュの仕組みがわかったところで、さらに実務で使える「メモリを極限まで削るテクニック」を伝授しましょう。
Redisのハッシュ型でメモリを無駄遣いしないための鉄則は、次の2つです。
1. フィールド名はできる限り短くする
2. 値（Value）の型に気をつける
① フィールド名の短縮化
Redisのハッシュは、フィールド名もメモリ上に保持します。
例えば、データベースの設計書に合わせて、フィールド名をこんな風にしていませんか？
- `user_profile_first_name`: “Taro” (長すぎる！)
これでは、フィールド名だけで無駄なメモリを食いつぶしてしまいます。次のように割り切りましょう。
- `fn`: “Taro”
「えっ、可読性が落ちるって？」
大丈夫です。バックエンドのプログラム側で定数としてマッピングしておけば、Redis内部では極限までメモリを節約できます。特に数百万件、数千万件のハッシュを扱う大規模システムでは、この数バイトの削り合いがサーバー代の数万円、数百万円の差になって跳ね返ってきます。
② 数値は数値として保存される恩恵
Redisのハッシュの値に数字（例: 年齢やスコア）を入れる場合、Redisは内部でうまいこと整数としてコンパクトに保持してくれます。
「”28″」という文字列として入れるよりも、そのまま数値として扱われるため、ここでもziplistの圧縮効率が最大限に活かされます。
—
5. 設定を確認・変更してみよう
実際に、現在のあなたのRedisの設定を確認してみましょう。
redis-cliから次のように打ち込んでみてください。
現在の「ziplistのエントリー数の上限」を確認する
CONFIG GET hash-max-ziplist-entries
もし、扱うデータ構造の特性に合わせてチューニングしたい場合は、`redis.conf` ファイルを書き換えるか、動的に次のように変更できます（※本番環境で変更する際は影響範囲に十分注意してくださいね）。
動的に上限を128に変更する場合の例
CONFIG SET hash-max-ziplist-entries 128
—
おわりに：基本をマスターすれば、Redisは最強の相棒になる
いかがでしたでしょうか？
「ハッシュ型」という一見シンプルなデータ構造の裏側にも、メモリを1バイトでも削ろうとするRedisの熱いエンジニア魂（ziplistの仕組み）が隠されていることが伝わったなら嬉しいです。
- ハッシュ型は関連データをまとめてメモリ効率を上げる優れた仕組み。
- データが少ないうちは「ziplist（圧縮リスト）」というコンパクトな状態で守られている。
- その境界線を決めるのが `hash-max-ziplist-entries` であり、アプリのデータ構造に合わせて意識することが大切。
ここをクリアできれば、あなたの扱うRedisは、無駄なメモリを一切食わない、軽やかで高速なモンスターマシンに変貌します。
日々の開発で、「このデータ、本当にこの持ち方でメモリ効率大丈夫かな？」と立ち止まれるエンジニアは本当に素敵です。ぜひ、あなたのプロジェクトでもこの知見を活かしてみてくださいね。応援しています！
コメント