HotKVのご紹介

HotKVは、モダンC++でゼロから書いたマルチスレッドのRedis互換データストアです。最新のメニーコアサーバーから、できるだけ低いコストで最大限の速度を引き出すために作りました。私はHotKV Ltdの創業者兼CEOのNorbert E. Borosです。この記事では、HotKVを作った理由、現在できること、そして測定結果をご説明します。

要点。 HotKVは1つのプロセス内で多数のスレッドを使って同時にコマンドを実行し、RedisプロトコルであるRESP2とRESP3に対応しています。160 vCPUで行った2026年10月の単一インスタンスのベンチマークでは、測定した12コマンド中11コマンドで最高のスループットを記録し、残る1コマンドではDragonflyと互角でした。テスト構成とその制約は以下で説明します。

HotKVを作った理由

私は、何を作るときでも速度を大切にしています。Webサイトも、ツールも、サーバーも、すぐに応答するべきです。そうでないときは、その理由を知りたくなります。この習慣は、ソフトウェアを書き始めたころからずっと私の仕事を形作ってきました。

CとC++は、長年にわたって私の主な言語です。10年近く、数千人のプレイヤーのPCで動作するゲームのアンチチートソフトウェアに携わりました。このソフトウェアは、CPUとメモリの使用をできるだけ抑えながら、メモリをスキャンしてチートを検出する必要がありました。消費するサイクルはすべて、ゲームから奪うことになるからです。この仕事を通じて、あらゆるものを測定すること、ハードウェアに合わせて設計すること、そして少ないリソース使用量をそれ自体ひとつの機能として扱うことを学びました。

並行して、高速なキャッシュを必要とする多くのプロジェクトでRedisとValkeyを使ってきました。セッションストア、ファイアウォールでブロックしたIPアドレスのリスト、数億件のSQL Serverレコードの前段に置くキャッシュなどです。どちらも優れたツールです。同時に、今日私たちが使っているメニーコアサーバー向けに最初から設計したキーバリューストアなら何ができるのか、という興味も抱くようになりました。

その答えとしてたどり着いたのがHotKVです。できるだけ低いコストで、ハードウェアからできるだけ多くの速度を引き出すために、モダンC++でゼロから書きました。現在の到達点は以下のベンチマークが示しています。まだ伸びしろはあると考えています。

AIのコスト

理由はもう1つありました。AIアプリケーションの運用コストが高くなりつつあったのです。私自身もそうでしたし、開発者がオンラインで共有している内容から判断すると、ほかの多くの人にとっても同じでした。そのコストの大部分は、モデルがすでに答えた質問を再び送ることから生じている場合がよくあります。繰り返された質問や似た質問を認識してキャッシュから答える高速なストアは、その費用を削減する最も直接的な方法の1つです。だからこそ、AIワークロード向けのキャッシュはHotKVの中核を成しています。

HotKVの目的

HotKV Ltdは、この種のソフトウェアをより高性能に、より手頃にするために存在しています。最新のサーバーは多くのコアを備えており、データストアはそれを活用すべきです。そうすれば、できるだけ低いコストで、できるだけ高い速度が得られます。

2つ目の考えは、スタックのより多くの部分を1か所にまとめることです。LLMを使って開発するチームは、キャッシュ、ベクトルデータベース、エージェントメモリの保存先を運用し、その間を大量のグルーコードでつなぐことになりがちです。私は、キャッシュと、その周辺に構築されるAIの処理を、データのすぐそばにある1つのエンジンにまとめたいと考えています。具体的には、モデル呼び出しの完全一致キャッシュとセマンティックキャッシュ、ベクトル検索、エージェントメモリ、トークン予算です。運用するシステムが減れば、可動部品が減り、請求額も下がるはずです。現在利用できる機能はAIページに、私たちのテストでモデル呼び出しのキャッシュによってどれだけ削減できたかはトークン削減のベンチマークに掲載しています。

HotKVは、Redisプロトコルと使い慣れたクライアントライブラリをそのまま維持しています。

課題

コアの多いマシンでは、コマンドを実行するスレッドが1つだけだと、それがボトルネックになることがあります。1つの実行スレッドを中心に作られたデータストアは、通常、複数のインスタンスやクラスターを動かすことでマシンの残りの部分を使います。そこにはデプロイ方法の選択や運用作業が伴います。私はHotKVを反対の発想から出発させたいと考えました。1つのインスタンスの中でコマンドを並行して実行し、単一のプロセスでマシン全体を使えるようにするということです。

HotKVの違い

HotKV™はC++20で書かれており、多数のコアで同時にコマンドを実行するように設計されているため、1つのインスタンスでマシン全体を活用できます。以下でベンチマークしているDragonflyも、マルチスレッドのアプローチを採っています。

• 多数のコア、1つのインスタンス。 コマンドはマシンのコア全体で並行して実行されるため、複数の小さなサーバーの代わりに、1つのインスタンスで大きなサーバーを使えます。
• 使い慣れたクライアントとプロトコル。 HotKVはRESP2とRESP3に対応しているため、使い慣れたクライアントライブラリから接続できます。トランザクション（MULTI/EXEC）とLuaスクリプトにも対応しています。対応コマンドと相違点については、コマンドのドキュメントをご覧ください。

開発とテストの方法

HotKVは私自身が開発しており、役立つ場面ではAIの支援も使っています。コードがどのように書かれたかよりも重要なのは、それがきちんと持ちこたえるかどうかです。そのため、エンジンは徹底的にテストしています。2,000件を超える自動テストがあり、AddressSanitizer、ThreadSanitizer、UndefinedBehaviorSanitizerの下でビルドしています。さらに、プロトコルパーサー、コマンドディスパッチ、RDBとAOFの読み込み、レプリケーションストリーム、クラスターバスを対象としたファズターゲットも備えています。

ベンチマークの構成、その制約、全結果はパフォーマンスページに掲載しているので、数値はご自身で判断していただけます。

ベンチマークの概要

2026年10月更新：この記事で最初に公開した数値は、後に欠陥が見つかったベンチマークの実行によるものでした（ほかの問題に加えて、すべての負荷生成マシンが同じ乱数シードを使用していました）。そのため、作り直したベンチマークの結果に置き換えました。

2026年10月：HotKV、Redis、Valkey、Dragonfly

このベンチマークはHotKV Ltdが実施しました。ソースからビルドしたHotKVを、Redis 8.10.2、Valkey 9.1.2、Dragonfly 2.0.2と比較測定しました。各サーバーは単独で、Azure D160alds_v7（AMD EPYC 9V45）の160 vCPUすべてを使う単一インスタンスとして、永続化をオフにして実行しました。負荷は、64 vCPUの独立したマシン3台がmemtier_benchmarkで生成しました。値のサイズは256バイト、パイプライン深度は30、事前に書き込んだキーは5,000,000個です。すべての数値は、10秒間の実行3回の中央値です。

HotKVは12コマンド中11コマンドで最高のスループットを記録しました。RedisまたはValkeyに対しては、コマンドとサーバーによって、そのスループットの8.6倍から少なくとも69.7倍を測定しました。Dragonflyに対しては、その11コマンドで1.97倍から4.41倍で、そのうちいくつかは下限値です。PINGではDragonflyが0.6%上回りました。負荷生成マシンが自身の上限に近かったため、私たちはこれを互角とみなしています。データコマンドでの最高値は、毎秒9,080万回のINCR操作でした。INCRとPINGはデータの移動量が少なく、負荷生成マシンによって制限されるため、これらのHotKV自体の数値はさらに高い可能性があります。

表の見方

MGETは1コマンドで8個のキーを読み取り、MSETは1コマンドで4組のキーと値のペアを書き込みます。スループットはコマンド数で数えています。レポートでは、ネットワーク使用率のしきい値85%に達したHotKVの7つの数値（GETと6つの書き込みコマンド）と、負荷生成マシンのCPU使用率が85%を超えていたPINGに印を付けています。これらに基づく倍率は下限値であり、≥で示しています。GETとPINGについては、これが実際の上限です。6つの書き込みコマンドについては、レポートのネットワーク使用率の数値が受信と送信のトラフィックを合算し、それを送信の上限と比較しているため、上限への近さを過大に示しています。最も負荷の高いSETNXでも、使用したのは測定した受信上限の最大で約80%です。私たちは慎重を期す慣例として、これらにも≥を残しています。表の全体、フラグ、測定方法の注記はパフォーマンスページに掲載しています。

ベンチマークの範囲

• ビルドとチューニング。 HotKVはテスト用のCPU向けに-march=nativeでコンパイルし、他のサーバーは標準のリリースビルドを使用しました。
• スレッド設定。 すべてのサーバーにマシンの全コアを割り当てました。HotKVは--threads 160、Dragonflyは160のproactorスレッド、Valkeyはio-threads 160、Redisは上限のio-threads 128です。RedisとValkeyはコマンドを1つのスレッドで実行するため、I/Oスレッドを減らしたほうが高いスループットに達する可能性があり、これらの数値は最良値を下回っているかもしれません。RedisとValkeyのクラスターや複数インスタンスでの実行は行っていません。
• 範囲。 12コマンド、1つの値サイズ、1つのパイプライン深度で、TLSと永続化はなしです。LPOPとRPOPは測定していません。このレートでは、破壊的な読み取りによって、メモリに収まるリストはどれも10秒以内に空になってしまうためです。レポートにはレイテンシとメモリ使用量も記録していますが、ここでは比較しません。10秒間の各実行でサーバーが行った処理量が大きく異なるため、メモリの数値は同じ条件での比較にならないからです。混合ワークロードは測定していません。
• ばらつき。 Redisはいくつかのコマンドで3回の実行の間に大きくばらつき、HSETでは最速と最遅の実行の間で最大7.2倍の差があり、中央値ではそれが見えなくなります。各競合製品の中央値ではなく最速の実行と比較しても、HotKVは11コマンドすべてで首位でした。

Redis、Valkey、Dragonflyは、それぞれの所有者の商標です。これらの名称は測定したソフトウェアを特定するためにのみ使用しており、後援、推奨、提携関係を示すものではありません。

現在提供している機能

コアとなるコマンドファミリーには、文字列、リスト、セット、ハッシュ、ソート済みセット、ストリーム、地理空間インデックス、ビットマップ、HyperLogLog、pub/sub、Luaスクリプトがあります。AIモジュールとエンタープライズ機能はライセンス付きのプランで動作し、各プランに含まれる内容は料金に掲載しています。現在のコマンド対応状況はドキュメントをご覧ください。Redisのコマンドセットに加えて、次の機能があります：

• キーのタグ付け： キーに任意のタグを付け、タグで照会できます（TAG.SET、TAG.MEMBERSほか5つのコマンド）。
• ナノ秒単位のTTL： NEXPIRE、NTTL、NEXPIREATで有効期限をナノ秒単位で設定・取得できるため、期限を1ミリ秒より細かく指定できます。期限切れのキーは、バックグラウンドのスイープと、アクセスされた時点で回収されます。
• 値の圧縮（オプション）： サイズのしきい値（デフォルトは512バイト）を超える値が対象で、有効にしない限りオフです。
• forkを使わないスナップショット： BGSAVEは、forkしたプロセスではなくバックグラウンドスレッドで書き込みます。スナップショットはある時点のコピーではなく、各キーはスナップショットの処理がそのキーに到達した時点の状態で保存されます。なお、追記専用ファイルの書き換えではforkを行います。
• Prometheusメトリクス： HTTPエンドポイントを内蔵しており（デフォルトはオフで、metrics-portで有効化）、外部のエクスポーターは不要です。

HotKVには、HNSWインデックスによるベクトル検索も組み込まれています（VSIM.CREATEINDEX、VSIM.SET、VSIM.SEARCH）。Redis 8との比較測定はベクトル検索：HotKVとRedis 8のベクトルセット、1～100クライアントで比較に掲載しています。

HotKV Cloudで始めるか、自社のサーバーでHotKVを運用する方法について営業チームにご相談ください。