スループットの直接比較
HotKV LtdがHotKV、Redis、Valkey、Dragonflyを1つのクラウドインスタンスでテストした結果、HotKVは12コマンド中11コマンドで最高の中央値スループットを記録しました。PINGではDragonflyが0.6%上回りましたが、これは負荷生成マシンの限界の範囲内であるため、互角と判断しています。これらの結果は、テストしたビルドと設定に限られます。詳しくは以下の測定方法をご覧ください。
- 同一マシンすべてのサーバーを同じインスタンスで、一度に1つずつ実行します。
- 負荷生成は別マシン負荷は専用のクライアントマシンで生成し、サーバー自身のマシンで生成することはありません。
- 同一の設定すべてのサーバーに同じスレッド数を割り当て、それ以外のチューニングは行いません。
- 3回の実行の中央値各コマンドを3回実行します。その中央値を示しています。
- 上限を明示ネットワークまたは負荷生成マシンによって決まった結果には印を付けています。
- 方法の詳細すべての設定、上限、注意事項を結果の下に詳しく記載しています。
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- アーキテクチャ:
- x86_64
- RAM:
- 314.8 GB
- ネットワーク:
- 送信78 Gbps、受信132+ Gbps
- スレッド:
- サーバーあたり160（Redisは上限の128）
- 測定日:
- 2026年10月9日
1秒あたりの操作数（3回の実行の中央値）。各バーは、そのコマンドで最も速いサーバーを基準にスケーリングしています。
- そのコマンドでの最高結果。
- ネットワーク律速：この結果はインスタンスのネットワークによって決まったもので、サーバー自体の上限はこれより高くなります。
- 負荷生成側律速：負荷生成マシンのCPU使用率が85%を超えていたため、これはサーバーではなく負荷生成マシンの上限です。
- Azureは送信トラフィックを制限しています。3台のクライアントマシンを使ったiperf3の測定では、送信は78 Gbps、受信は少なくとも132 Gbpsでした。GETとMGETは値を送信します。HotKVのGETは送信上限の88%を使用しており、サーバーの限界ではなくインスタンスによって決まる下限値です。MGETも83%でそれに迫ります。Dragonflyの読み取りが使用したのは、最大でも上限の44%でした。
- 書き込みは受信方向に流れるため、書き込みの結果はサーバー自体の数値です。最も負荷の高いSETNXは約106 Gbpsで受信上限の約80%を使用したため、HotKVの書き込みの数値はやや控えめな下限値とお考えください。
- PINGでは、負荷生成マシンのCPU使用率がHotKVで86%、Dragonflyで82%に達しました。両者の0.6%の差はこの制限の範囲内であるため、PINGは互角です。
Azure D160alds_v7の詳細な数値
| コマンド | HotKV | Redis | Valkey | Dragonfly | Redis比 | Valkey比 | Dragonfly比 |
|---|---|---|---|---|---|---|---|
| SET | 最高値： 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | 最高値： 36,643,656(ネットワーク律速) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | 最高値： 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | 最高値： 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | 最高値： 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | 最高値： 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | 最高値： 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | 最高値： 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | 最高値： 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | 最高値： 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | 最高値： 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(負荷生成側律速) | 3,235,600 | 3,480,446 | 最高値： 126,033,542 | 38.70x | 35.98x | 0.99x |
当社のテストでRedis 8のベクトルセットより高速
同じOpenAIの埋め込みをHotKVとRedis 8に読み込み、それぞれに対して同じ1,000件のクエリを、1～100の同時クライアント接続で、1台のマシン上で実行しました。どちらも同じインデックス設定で、全精度のベクトルを保持しています。
同じ再現率での毎秒クエリ数
両エンジンとも全精度のfloat32ベクトルを格納しました。999,000ベクトルの読み込み後、HotKVのプロセスは6.77 GB、Redisは7.01 GBを使用していました。
未測定の項目：Redisのデフォルトである8ビット量子化モード、Redis Query Engine、その他のデータセット、その他のハードウェア。HotKVのビルドは未リリースの開発ビルドです。 Redisは4つのvCPUに固定して読み込み、再読み込みしたインデックスに対して検索しました（記事を参照）。
すべての数値：999,000ベクトル、50クライアント
| ef | HotKV再現率 | Redis再現率 | HotKVクエリ/秒 | Redisクエリ/秒 | 倍率 |
|---|---|---|---|---|---|
| 40 | 0.940 | 0.923 | 63,897 | 8,061 | 7.9x |
| 80 | 0.970 | 0.962 | 37,508 | 6,825 | 5.5x |
| 150 | 0.987 | 0.980 | 21,912 | 5,241 | 4.2x |
| 300 | 0.993 | 0.990 | 12,393 | 3,454 | 3.6x |
| 500 | 0.997 | 0.994 | 7,688 | 2,483 | 3.1x |
HotKVビルドc8dafd37とRedis 8.10.2、コサイン類似度、両方ともM=16、ef_construction=200のHNSW、両方ともfloat32（Redis NOQUANT）。再現率は、総当たりによる正確な結果に対するrecall@10です。Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs上での3回の実行の中央値。サーバーは128個のvCPUを共有し、負荷生成マシンは別の32個のvCPU上で、両方に同じクライアントコードを使用して実行しました。
データセット：Kumar Shivendu and Nirant Kasliwalによるdbpedia-entities-openai-1Mの埋め込み（OpenAI text-embedding-ada-002、1,536次元）、ライセンス：MIT、および1,000件のホールドアウトクエリ。完全な手法、スクリプト、生データ。 2026年10月14日に測定。