バックエンドパフォーマンスRedis

Redis 8.10：新しいコンパクトハッシュとオープンソース機能

Redis 8.10 がリリース、コンパクトハッシュでメモリ使用量を最大50%削減、ロードスループットが倍増、さらに増分バックアップ復元、より完全な JSONPath クエリ、Streams と Time Series のいくつかの新コマンドを提供。

Redis BlogBosmat Tuvel約 11 分

日本語
中文日本語
コピー
题图：Redis 的红底品牌图，正中间是白色的手写体 Redis 标志

Redis 8.10 が Redis Open Source としてリリースされた。メモリ効率、表現力、大規模運用のしやすさをまとめて改善する内容となっている。

ハイライトは、コンパクトハッシュによるメモリ使用量の最大 50% 削減、ハッシュのロードスループットの 2 倍化、増分バックアップとリストア、JSONPath 構文の拡張、より柔軟な Stream の消費方法、新しい Set の基数演算、複数 List 要素のアトミックな移動、そして Time Series の機能強化だ。

Redis 8.10 に注目すべき理由

Redis 8.10 は 3 つの方向に焦点を当てている。効率の向上、Redis データ構造の表現力の拡張、本番環境の運用負荷の軽減だ。

性能面では、コンパクトハッシュと Stream の最適化がメモリ使用量を抑えつつスループットを高め、既存のインフラからより多くの性能を引き出せるようにする。RedisJSON、Streams、Lists、Sets、TimeSeries に追加された一連のコマンドと強化により、よくある操作の表現力が上がり、アプリケーション側の複雑さと、日常的なタスクに必要なラウンドトリップ数が減る。

運用担当者にとっては、増分バックアップとリストアの導入により、整合性の取れたクラスタバックアップを作成できるようになり、稼働中のワークロードへの影響も大幅に小さくなる。大規模な Redis デプロイの信頼性が上がるということだ。

以下、追加された内容を順に見ていく。

性能ハイライト

新機能だけでなく、Redis 8.10 にはハッシュと Stream のスループットとメモリ効率を高める性能最適化も複数含まれている。ハイライトは次のとおり。

データ型操作効果
Hashワイドテーブル、新規作成ハッシュに対する HSET、HMSETスループット最大 104% 向上
Hashフィールド名の構造を共有するキーメモリ使用量最大 50% 削減
StreamsXREADGROUPスループット最大 28% 向上（COUNT 100）
Streams深い Streamメモリ使用量最大 26% 削減

これらの性能向上に加えて、Redis 8.10 はデータ構造、RedisJSON、RedisTimeSeries、Streams、データ管理に多くの新機能を導入している。

Redis 8.10 の新機能

コンパクト Hash

アプリケーションは同じフィールドを持つ hash を大量に作ることがよくある。たとえば数百万件のユーザープロファイルがあり、それぞれに name、email、country、last_login が含まれるようなケースだ。従来は、こうしたフィールド名を hash ごとに個別に保存する必要があった。

Redis 8.10 は hash テンプレートを導入する。これは新しい内部エンコーディングで、複数の hash が同じフィールド名の集合を共有しつつ、値はそれぞれ独立して保持できる。構造の似た hash が大量にある場合、メモリ使用量は最大 50% 削減される。

Redis 8.10 は HIMPORT も導入する。同じフィールドを持つ hash への効率的な一括書き込みのために設計されたものだ。クライアントはフィールドの集合を一度用意するだけでよい。

HIMPORT PREPARE user-profile name email country last_login

あとは hash を書き込むときに値を送るだけになる。

HIMPORT SET user:1 user-profile "Alice" "alice@example.com" "UK" "2026-07-14"

HIMPORT SET user:2 user-profile "Bob" "bob@example.com" "US" "2026-07-14"

hash ごとにフィールド名を送信して解析する必要がなくなるため、HIMPORT はネットワークとサーバー側の処理オーバーヘッドを減らし、hash の書き込みスループットを最大 2 倍まで高める。

既存の hash コマンドのセマンティクスは変わらない。運用担当者は条件を満たす hash に対して自動テンプレート変換を有効にでき、アプリケーションを HIMPORT に切り替える必要もない。

hash テンプレートは、多数の hash が安定したフィールド集合を共有しているときに最も効果を発揮する。ユーザープロファイル、セッション、特徴量ストア、一括インポート、ETL といった用途に特に向いている。

JSON：表現力の高い JSONPath クエリ

Redis JSON は JSONPath 式を使って JSON ドキュメントの特定部分にアクセスして操作する。ドキュメント全体を取得する必要はない。

Redis 8.10 は JSONPath 構文を大幅に拡張し、フィルタリング、計算、集計、データ処理の多くを Redis 内で直接こなせるようにする。

追加された機能は次のとおり。

  • 算術演算子と比較演算子

  • in、nin、フィルタの否定

  • 文字列、配列、オブジェクト、ノードリストに対する操作

  • match()、search()、concat() などの文字列関数

  • first()、last()、append()、index() などの配列関数

  • min()、max()、avg()、sum()、stddev() を含む集計操作

  • length()、count()、keys()、value() などの関数

例：

JSON.GET key '$.price * 0.8'

JSON.GET key '$.arr1.avg()'

JSON.GET key 'count($.items[?@.price > 10])'

表現力が増したことで、フィルタリングや後処理のロジックをより多く Redis に置けるようになり、データ転送が減り、アプリケーションコードも簡素になる。

Streams：XREAD の結果全体のサイズを制御する

XREAD と XREADGROUP はすでに COUNT をサポートしているが、この制限は Stream ごとに個別に適用される。複数の Stream から読み取る場合や、Stream に大きなエントリが含まれる場合、レスポンス全体は依然として非常に大きくなりうる。

Redis 8.10 は 2 つのオプションを追加する。

  • MAXCOUNT：すべての Stream が返すメッセージの総数を制限する。

  • MAXSIZE：返信全体のバイトサイズを制限する。

例：

XREAD COUNT 100 MAXCOUNT 200 STREAMS stream:1 stream:2 stream:3 0 0 0

このコマンドは各 Stream から最大 100 件のメッセージを読み取り、全体で返すメッセージは 200 件を超えない。

こうした制御により、アプリケーションはネットワーク転送量とメモリ消費を抑え、想定外に大きなレスポンスを避けられる。

Sets：メンバーを取得せずに和集合と差集合の基数を得る

アプリケーションは Sets をユーザーセグメント、権限、商品カテゴリ、検索フィルタなどの集合表現によく使う。必要なのはいくつの要素が演算の条件に合致するかであって、要素そのものを取り出すことではない。

Redis はすでに Set の積集合に SINTERCARD を提供している。Redis 8.10 は和集合と差集合にも対応する操作を追加した：

SUNIONCARD numkeys key [key ...] [APPROX] [LIMIT limit]

SDIFFCARD numkeys key [key ...] [LIMIT limit]

SUNIONCARD は和集合の基数を返し、SDIFFCARD は最初の Set と後続の Set との差集合の基数を返す。

これにより、巨大になりうる集合をクライアントに返す必要も、カウントのためだけに一時的な Set を作る必要もなくなる。SUNIONCARD では APPROX も使え、HyperLogLog による高速な推定が可能で、標準誤差は 0.81% だ。

Lists：複数要素をアトミックに移動する

Redis Lists はキュー、スタック、処理パイプラインによく使われる。LMOVE と BLMOVE はすでに Lists 間で単一要素をアトミックに移動できるが、多くのワークフローでは複数要素をまとめて確保したり転送したりする必要がある。

Redis 8.10 は次を導入した：

LMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT>
       [<COUNT|EXACTLY> count <OBO|BULK>]

BLMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT> timeout
        [<COUNT|EXACTLY> count <OBO|BULK>]

新しいコマンドは複数の要素を 1 つの List から別の List へアトミックに移動できる。

COUNT は要求した数まで移動し、EXACTLY は要求した数がすべて揃っている場合にのみバッチ全体を移動する。アプリケーションは要素ごとの順序（OBO）と BULK 順のどちらでも選べ、後者は移動する要素の相対順序を保つ。

これはバッチタスクの確保、キューの処理、パイプラインの受け渡し、リトライキューなど、要素をまとめて移動する必要のあるワークフローに向く。

Time Series：タイムスタンプで複数シリーズをクエリする

関連する Time Series は、タイムスタンプを共有していても別々に保存されるのが普通だ。たとえば金融の OHLCV データでは、open、high、low、close、volume をそれぞれ独立したシリーズとして持つことがある。

TS.MRANGE が返す結果は Time Series ごとにグループ化されるため、タイムスタンプを揃えたデータを必要とするアプリケーションは、結果を自分で組み替えることが多い。

Redis 8.10 は TS.NRANGE と TS.NREVRANGE を導入した。明示的に指定した Time Series 群をクエリし、タイムスタンプごとにグループ化した結果を返す：

TS.NRANGE 5 {ACMZ}:open {ACMZ}:high {ACMZ}:low
            {ACMZ}:close {ACMZ}:volume
            <fromTimestamp> <toTimestamp>

キーを明示的に指定するため、ラベルは不要だ。Redis Cluster では、指定したキーはすべて同じハッシュスロットに属している必要がある。

両コマンドはシリーズごとのアグリゲータにも対応しており、同じクエリの中で Time Series ごとに異なる集約関数を適用できる。

これによりタイムスタンプを揃えたデータを扱いやすくなり、金融アプリケーション、分析パイプライン、監視ダッシュボード、機械学習の特徴量抽出で、クライアント側のピボット変換が不要になる。

Time Series：ブロッキング読み取りで新しいデータを待つ

リアルタイムの Time Series データを表示するアプリケーションは、新しいサンプルが届いたかどうかを知るために Redis を繰り返しポーリングしがちだ。

Redis 8.10 は TS.READ を導入した。任意でブロックするコマンドで、アプリケーションは新しいサンプルを待てる：

TS.READ key timestamp
        [BLOCK milliseconds min_count]
        [MAX_COUNT max_count]

アプリケーションは範囲クエリを投げ続ける代わりに、最小数のサンプルが揃うか、指定したタイムアウトが切れるまでブロックできる。

TS.READ はリアルタイムダッシュボード、監視システム、金融アプリケーション、アラート、そして新しい Time Series データを継続的に消費する IoT ワークロードに向く。

Time Series：空の結果を除外する

TS.MRANGE と TS.MREVRANGE は、フィルタ条件に合致しても、要求した時間範囲にサンプルが 1 つもない Time Series を返すことがある。

Redis 8.10 は EXCLUDEEMPTY フラグを追加した：

TS.MRANGE - 500 WITHLABELS EXCLUDEEMPTY FILTER s=1

EXCLUDEEMPTY を使うと、要求した範囲にサンプルがない一致 Time Series はレスポンスから除外され、不要な結果データとクライアント側のフィルタリングが減る。

増分バックアップと復元

大規模な Redis Cluster のバックアップは非常にリソースを食う。RDB スナップショットの作成には Redis の fork が必要で、同じノード上の複数シャードが同時に fork すると CPU とメモリの使用量が跳ね上がり、ワークロードの遅延やバックアップの失敗につながる。

Redis 8.10 は増分バックアップと復元を導入した。新しい BACKUP コマンドファミリを中心に構成されている。

各シャードが同時にスナップショットを取る必要はなくなり、シャードごとにスナップショットのタイミングをずらしながら、整合の取れたバックアップを 1 つ生成できる。各バックアップは、ある時点で一貫した RDB スナップショット（BASE）から始まる。その後、バックアップを開いたままにしている間、Redis は以降の書き込みを増分（INCR）AOF ファイルに記録する。

バックアップを封止すると、RDB スナップショット、増分 AOF ファイル、マニフェストがそろって 1 つの完全なバックアップとなり、バックアップウィンドウ終了時点のデータセットを表す。封止に再度の fork は不要なので、シャードごとにスナップショットの作成時刻が違ってもまとめて完了できる。

復元については、新しい preload-file 起動オプションで、封止済みのバックアップマニフェストも、単体の RDB ファイルも読み込める。

こうして得られるバックアップ手順は拡張性が高く、リソースのピークも低い。特に 1 ノードに複数シャードを載せる大規模構成で効果がある。

クイックスタート

Redis 8.10 が Redis Open Source として正式にリリースされました。

Redis 8.10 をダウンロードして、ぜひあなたのアプリケーションで新機能をお試しください。

ご意見やご質問がありましたら、Discord サーバーにご参加のうえ議論に加わっていただくか、担当のアカウントマネージャーまでお問い合わせください。

出典: Redis Blog← ホームへ戻る