5,000 万件のソート済みセット、第 3 ラウンド：Redis はなお Valkey を追う

Valkey で同じソート済みセットのベンチマークを、これまでに 2 回実施しました。パイプライン化した ZADD で一つの ZSET に 5,000 万件のメンバーを挿入し、最後にメモリ使用量を測定するものです。最初の記事では、Valkey 8.1 が 8.0 に比べてメモリを 22% 削減したことを報告しました。続編では、Valkey 9.1 でさらに 11% の削減を確認しました。次に知りたくなるのは、当然、同じテストを Redis で実行するとどうなるかです。

各ビルドでの進歩を評価するため、再現可能なベンチマークを用意しました。同じベンチマーク、同じツール（sorted-set-benchmark、パイプライン化した ZADD NX、メンバーは m:{i}、スコアは整数）、同じ Graviton4 マシン（r8g.4xlarge）、同じ測定手順です。各バージョンで、実行の間にデータをフラッシュしながら 10 回繰り返し、公式 Docker イメージを --save '' --appendonly no で起動しました。サーバーは一度に一つだけ動かし、同じホスト上の単一のベンチマーククライアントから測定しました。対象は Redis の 6 バージョンと Valkey の 5 バージョンです。

測定結果

メモリの値は、サーバーの used_memory です。ツールの表示どおり、10 進の GB を使っています。どのバージョンでも、10 回の測定値はツールの表示精度である約 10 MB の粒度では同じ値になりました。mem_fragmentation_ratio は一貫して 1.01x で、RSS もこれらの値に近い値を示します。10 回の実行間でスループットのばらつきは小さく、注目する二つの構成の範囲は重なりませんでした（Valkey 9.1：643～652k/s、Redis 8.10：628～639k/s）。

三つの点が目立ちます。第一に、この最適化以前の両エンジンの全バージョンは、このワークロードで同じ 4.83 GB に並びます。ZSET 実装が共通のコードベースに由来することを考えると、予想どおりです。第二に、Redis にも同程度の削減が入りました。メモリ使用量は 4.83 GB から 3.73 GB へ 23% 減り、その境目は正確に 8.6 です（8.4.7 は旧レイアウト、8.6.7 は新レイアウト）。挿入数の中央値も 536k/s から 613k/s に増えています。第三に、今回測定した中で最も省メモリかつ高速な構成は、引き続き Valkey 9.1.2 でした。Redis 8.10.2 よりメモリ使用量が約 10% 少なく、スループットでも小さいながら一貫した優位性があります。

同じアイデアが伝わっていく

特に興味深かったのは、Redis の最新の値が Valkey 8.1 の値から約 1% の範囲に収まったことです。3.73 GB と 3.77 GB で、どちらもメンバーあたり約 75 バイトです。2026 年後半の Redis は、バイト単位で見ると、ほぼ 2025 年 4 月の Valkey に相当します。これは偶然ではありません。公開されているプルリクエストとリリースノートから、その理由を正確にたどれます。

Valkey PR #1427（2025 年 1 月にマージ、同年 4 月の Valkey 8.1 でリリース）では、ソート済みセットの構造を変更し、ハッシュ検索構造がマッピングのコピーを独自に保持する代わりに、スキップリストのノードを直接参照するようにしました。このベンチマークでは、4.83 GB から 3.77 GB への削減に相当します。続く Valkey PR #2508（2025 年 11 月にマージ、9.1 でリリース）では、メンバー文字列をスキップリストのノード自体に埋め込み、要素ごとのポインターと個別のメモリ割り当てを一つずつ取り除きました。これが 3.77 GB から 3.34 GB への削減です。

Redis PR #14701（Valkey の PR から 1 年と 10 日後、2026 年 1 月にマージ）は、この取り組みを Redis に移植しました。PR の説明には、出典がそのまま明記されています。「This is based on: valkey-io/valkey/pull/1427.」（この変更は valkey-io/valkey/pull/1427 に基づきます。）明確に出典を示したエンジニアの姿勢は評価すべきです。誰もがそうするわけではありません。この移植では、Valkey の新しいハッシュテーブルを採用せずに Redis の dict を no_value モードで使い続け、ノードへの埋め込みを組み合わせ、Redis 8.6 でリリースしました。私の測定もリリースノートと一致しており、削減の境目は正確に 8.6 でした。

では、なぜ Redis は依然として 10% 遅れているのでしょうか。後から取り入れる以上、常に後を追うことになるからです。Redis は設計を取り込みましたが、その設計の土台だったハッシュテーブルは採用しませんでした。そして、移植版がリリースされる頃には、Valkey はすでに次の段階へ進んでいました。差の全体像は、採用しなかった設計上の要素と、まだ追いついていないリリースの組み合わせです。作業を担当したエンジニアへの皮肉を込めているわけではありません。Valkey が BSD ライセンスを採用しているのは、まさに Redis を含め誰もがそれを基に開発できるようにするためであり、Redis のユーザーにも確かな恩恵があります。アイデアが逆方向に流れたなら、それも報告します。ただし、私がベンチマークするのは実際にリリースされたものです。その結果は、このデータ構造において、一方のプロジェクトが先行し、もう一方が約 1 年遅れで追いついていることを示しています。

運用者への示唆

注意点はいつもと同じです。これは、スキップリストでエンコードされた一つの大きな ZSET、短いメンバー、整数のスコア、アロケーター単位のメモリ集計、単一のパイプライン化クライアントという条件での測定です。データの形が変われば結果も変わるため、自分たちのワークロードで ツールを実行してください。

Valkey を運用しているなら、結論は明快です。9.1 は、この表の全構成の中でメモリ使用量が最も少なく、挿入速度が最も高い結果でした。アップグレードするだけで、この最適化を利用できます。両プロジェクトがリリースを重ねるたびに、今後もこのベンチマークを続けます。

Redis を運用していて、Valkey の方が効率的なのではないかと気になる場合、選択肢は二つあります。Redis がいずれ Valkey の最新 PR を取り込むのを待つか、Valkey に切り替えるかです。皆さんはどうしますか。

Momento Cache：クラウドで最速の Valkey

Momento のマネージドサービスなら、インフラを自分で管理せずに、常に最新の Valkey を利用できます。Momento は、世界最大級のキャッシュを支えるのと同じ技術で、アップグレード、フェイルオーバー、最適化などを円滑に処理します。Snap、Coinbase、Paramount、Capcom などの企業に続いて、今すぐ Momento Cache をお試しください！