Durchsatz im direkten Vergleich
In einem Test von HotKV Ltd mit HotKV, Redis, Valkey und Dragonfly auf einer Cloud-Instanz erzielte HotKV bei 11 von 12 Befehlen den höchsten medianen Durchsatz. Bei PING lag Dragonfly 0,6 % vorn. Das liegt innerhalb der Grenzen der Lastgeneratoren, daher werten wir es als Gleichstand. Diese Ergebnisse gelten für die getesteten Builds und Einstellungen. Die Methodik ist unten beschrieben.
- Dieselbe MaschineJeder Server läuft auf derselben Instanz, jeweils einer zur Zeit.
- Separate LastgeneratorenDedizierte Client-Maschinen erzeugen die Last, niemals die Maschine des Servers selbst.
- Gleiche EinstellungenJeder Server erhält dieselbe Thread-Anzahl und kein weiteres Tuning.
- Median aus 3 LäufenJeder Befehl läuft 3-mal. Angezeigt wird der Median.
- Limits gekennzeichnetErgebnisse, die das Netzwerk oder die Lastgeneratoren bestimmt haben, sind gekennzeichnet.
- Methode im DetailJede Einstellung, jedes Limit und jeder Vorbehalt ist unter den Ergebnissen ausführlich beschrieben.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPUs:
- 160
- Architektur:
- x86_64
- RAM:
- 314,8 GB
- Netzwerk:
- 78 Gbps ausgehend, 132+ Gbps eingehend
- Threads:
- 160 pro Server (Redis 128, sein Maximum)
- Gemessen:
- 9. Oktober 2026
Operationen pro Sekunde, Median aus 3 Läufen. Jeder Balken ist auf den schnellsten Server bei diesem Befehl skaliert.
- Höchstes Ergebnis bei diesem Befehl.
- Netzwerkbegrenzt: Das Netzwerk der Instanz hat dieses Ergebnis bestimmt, daher liegt das eigentliche Limit des Servers höher.
- Lastgenerator-begrenzt: Die Lastgenerator-Maschinen liefen mit mehr als 85 % CPU-Auslastung, daher ist dies ihre Obergrenze, nicht die des Servers.
- Azure kontingentiert den ausgehenden Datenverkehr: iperf3 maß mit drei Client-Maschinen 78 Gbps ausgehend und mindestens 132 Gbps eingehend. GET und MGET senden Werte nach außen. GET von HotKV nutzte 88 % der Obergrenze für ausgehenden Verkehr, ist also eine von der Instanz gesetzte Untergrenze und kein Serverlimit, und sein MGET liegt mit 83 % knapp dahinter. Die Lesezugriffe von Dragonfly nutzten höchstens 44 % der Obergrenze.
- Schreibzugriffe treffen eingehend ein, daher sind die Schreibergebnisse Werte des Servers. Der datenintensivste, SETNX mit etwa 106 Gbps, nutzte etwa 80 % der Obergrenze für eingehenden Verkehr, daher sind die Schreibwerte von HotKV als leichte Untergrenzen zu verstehen.
- Bei PING erreichten die Lastgeneratoren 86 % CPU-Auslastung mit HotKV und 82 % mit Dragonfly. Die 0,6 % Abstand zwischen beiden liegen innerhalb dieses Limits, daher ist PING ein Gleichstand.
Genaue Werte für Azure D160alds_v7
| Befehl | HotKV | Redis | Valkey | Dragonfly | HotKV vs. Redis | HotKV vs. Valkey | HotKV vs. Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Höchster Wert: 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Höchster Wert: 36,643,656(Netzwerkbegrenzt) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Höchster Wert: 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Höchster Wert: 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Höchster Wert: 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Höchster Wert: 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Höchster Wert: 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Höchster Wert: 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Höchster Wert: 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Höchster Wert: 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Höchster Wert: 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Lastgenerator-begrenzt) | 3,235,600 | 3,480,446 | Höchster Wert: 126,033,542 | 38.70x | 35.98x | 0.99x |
In unserem Test schneller als Redis 8 Vector Sets
Wir haben dieselben OpenAI-Embeddings in HotKV und Redis 8 geladen und dieselben 1.000 Abfragen mit 1 bis 100 gleichzeitigen Client-Verbindungen gegen beide ausgeführt, auf einer einzigen Maschine. Beide hielten Vektoren in voller Genauigkeit, mit denselben Index-Einstellungen.
Abfragen pro Sekunde bei gleichem Recall
Beide Engines speicherten Vektoren in voller Genauigkeit (float32). Nach dem Laden von 999.000 Vektoren belegte der HotKV-Prozess 6,77 GB und Redis 7,01 GB.
Nicht gemessen: der standardmäßige 8-Bit-quantisierte Modus von Redis, die Redis Query Engine, andere Datensätze und andere Hardware. Der HotKV-Build ist ein Entwicklungs-Build, der noch nicht veröffentlicht wurde. Redis wurde auf vier vCPUs festgelegt geladen und auf einem neu geladenen Index durchsucht (siehe Artikel).
Alle Zahlen: 999.000 Vektoren, 50 Clients
| ef | HotKV-Recall | Redis-Recall | HotKV Abfragen/s | Redis Abfragen/s | Verhältnis |
|---|---|---|---|---|---|
| 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-Build c8dafd37 und Redis 8.10.2, Kosinus-Ähnlichkeit, HNSW mit M=16 und ef_construction=200 bei beiden, float32 bei beiden (Redis NOQUANT). Recall ist Recall@10 gegenüber exakten Brute-Force-Ergebnissen. Median aus 3 Läufen auf Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. Die Server teilten sich 128 vCPUs, die Lastgeneratoren liefen auf 32 weiteren, mit demselben Client-Code für beide.
Datensatz: dbpedia-entities-openai-1M-Embeddings (OpenAI text-embedding-ada-002, 1.536 Dimensionen) von Kumar Shivendu and Nirant Kasliwal, lizenziert unter MIT, plus 1.000 zurückgehaltene Abfragen. Vollständige Methode, Skripte und Rohdaten. Gemessen am 14. Oktober 2026.
Bereit, HotKV einzusetzen?
Sichere dir frühen Zugang und entdecke HotKV für deinen Workload.
Frühen Zugang sichern