【ITニュース解説】Redis 8.10's compact hashes need HIMPORT or a restart to kick in

Redisは、非常に高速なデータ処理を可能にするインメモリデータベースであり、キーと値のペアを保存する様々なデータ構造を提供している。その中でも「ハッシュ」は、一つのキーに対して複数のフィールドと値を紐付けて管理できる便利なデータ構造だ。例えば、ユーザーIDをキーとして、そのユーザーの氏名、メールアドレス、国、最終ログイン日時といった情報をフィールドとして持つことができる。

今回、Redis 8.10で新しく導入された「コンパクトハッシュ」という機能は、このハッシュのメモリ効率とデータ読み込み速度をさらに向上させることを目的としている。多くのハッシュが全く同じフィールド名（例えば、すべてのユーザープロファイルが「name」「email」「country」「last_login」というフィールドを持つ場合）を共有しているとき、通常はそれぞれのハッシュがフィールド名のコピーを個別に保持する。しかし、コンパクトハッシュでは、これらの共通するフィールド名を一度だけ保存し、各ハッシュはその共有されたフィールド名を参照する形になる。これにより、特にフィールド名自体が多くのメモリを占める場合に、大幅なメモリ削減が期待される。Redisの開発元は、最大50%のメモリ削減と2倍の読み込みスループット向上を謳っていた。

このコンパクトハッシュ機能を利用するには、大きく二つの方法がある。一つは新しい HIMPORT コマンドを使う方法、もう一つはRedisサーバーの再起動時にRDB（Redis Database）ファイルをリロードさせる方法だ。

HIMPORT コマンドは、最初に HIMPORT PREPARE で使用するフィールド名のリストを宣言し、その後に HIMPORT SET で実際の値をロードする。例えば、HIMPORT PREPARE u name email country last_login のようにフィールドリストを定義した後、HIMPORT SET user:1 u Alice alice@example.com UK 2026-07-14 のようにデータを追加していく。これにより、Redisはフィールド名を共有してメモリ効率を良くする。

実際に10万個のユーザープロファイル（4つのフィールドを持つ一般的なスキーマ）で検証したところ、従来の HSET コマンドでデータをロードした場合と比較して、HIMPORT を使った場合は20.2%のメモリ削減が確認された。これは広告の50%には及ばないものの、明確な効果が見られた。さらに、フィールド名が長く、値が短い、例えば「account_status_code」「two_factor_enabled_flag」のような8つのフィールドを持つスキーマで試すと、67.8%という大幅なメモリ削減が達成された。この結果から、メモリ削減効果は、フィールド名が全体に占めるメモリの割合が大きいほど顕著になることがわかる。

スループット（データ処理速度）に関しても、広告では最大2倍の向上が謳われていたが、50万個のハッシュをロードするベンチマークでは、HIMPORT が HSET に比べて約35%速いという結果になった。これは大きな改善ではあるが、広告の数値ほどではない。おそらく、特定のネットワーク環境や非常に多くのフィールドを持つスキーマなど、特定の条件下で広告の数値が達成される可能性が考えられる。

このコンパクトハッシュ機能の重要な注意点の一つは、既存の HSET コマンドで既に保存されているデータは、そのままではこの恩恵を受けないことだ。Redisは、稼働中のハッシュを自動的に分析してテンプレートに変換するようなことはしない。既存のデータをコンパクトハッシュに変換するには、HIMPORT コマンドを使うようにアプリケーションの書き込み部分を変更するか、Redisを再起動してRDBファイルをリロードする際に、特定のコンフィグレーションパラメータを有効にする必要がある。

RDBリロードによる変換の場合、hash-rdb-load-min-template-entries、hash-rdb-load-max-template-entries、hash-rdb-load-template-disassembly-threshold の三つの設定パラメータを明示的に有効にする必要がある。これらのパラメータはデフォルトではオフになっている。もし設定せずに再起動してしまうと、変換は行われない。また、CONFIG SET コマンドでこれらの設定を変更した場合、Redisの設定ファイルに永続化されていないと、サーバー再起動時に設定が失われるため、注意が必要だ。実際に正しく設定して再起動することで、既存の10万個のハッシュが単一の共有テンプレートに変換され、約18.8%のメモリ削減が確認できた。これは、直接 HIMPORT を使った場合とほぼ同等の効果である。つまり、アプリケーションのコード変更が難しい場合には、RDBリロードと適切な設定によるサーバー再起動が有効な選択肢となる。

ただし、コンパクトハッシュにはいくつかの落とし穴も存在する。 まず、テンプレート自体に固定のオーバーヘッド（管理コスト）があるため、共有するキーの数が少ない場合は、かえってメモリ使用量が増えることがある。検証では、2つや3つのキーでテンプレートを共有するよりも、通常のハッシュとして保存する方がメモリ効率が良いことが示された。約4〜5個のキーでメリットが出始め、約100個のキーでメモリ削減効果が飽和する傾向にある。したがって、短命で少数のハッシュをグループ化するようなケースでは、この機能を使わない方が良い場合もある。

次に、一度テンプレート化されたハッシュのフィールドを変更した場合の挙動だ。例えば、テンプレートにない新しいフィールドを追加したり、既存のフィールドを削除したりすると、そのハッシュは元のテンプレートから切り離されるのではなく、その変更されたハッシュ専用の新しい単一キーテンプレートとして扱われる。この結果、メモリ使用量が通常のハッシュとして保存した場合よりも大幅に増えてしまう可能性がある。他の共有されているキーには影響はないが、変更された特定のキーだけが、かえってメモリを多く消費することになる。

HIMPORT コマンドの利用にも制約がある。HIMPORT で宣言するフィールドセットは、Redisサーバー全体で共有されるものではなく、それを宣言した接続ごとに有効となる。つまり、ある接続で HIMPORT PREPARE を実行しても、別の接続からそのフィールドセット名を使って HIMPORT SET を実行することはできない。一般的なアプリケーションで使われる接続プールでは、リクエストごとに異なる接続が使われる可能性があるため、PREPARE をすべての接続で再実行するか、インポート処理全体を単一の接続に固定するなどの工夫が必要になる。

興味深いことに、複数の接続がそれぞれ独立して同じフィールドリストで HIMPORT PREPARE を実行し、同時にデータを書き込んだ場合でも、Redisはサーバー側で賢く同じフィールド名を持つテンプレートを重複排除し、最終的に一つの共有テンプレートに統合する。これは並行処理の観点からは非常に良い挙動だと言える。

結論として、コンパクトハッシュは、数千ものハッシュが共通のフィールド名を持つような、大量のデータを一括でロードするバルクロードやETL（抽出・変換・ロード）のシナリオにおいて、非常に強力なメモリ削減およびスループット向上ツールとなり得る。しかし、従来の HSET コマンドの単なる代替として日常的に使うべきではない。アプリケーションの書き込みパスを変更できる場合は HIMPORT を検討し、それが難しい場合はRDBリロードによる自動変換を検討するのが良いだろう。ただし、実際に導入する前には、自分のデータスキーマ（フィールド名と値のメモリ比率）やキー数、変更頻度などを考慮し、検証環境で効果を測定することが不可欠だ。少ないキー数や、テンプレート化されたハッシュの頻繁な変更がある場合は、かえってデメリットになる可能性もあるため、INFO stats コマンドで hash_templates や hash_template_keys の値を確認しながら慎重に進めることが重要である。