Debit față în față
În testul făcut de HotKV Ltd cu HotKV, Redis, Valkey și Dragonfly pe aceeași instanță cloud, HotKV a înregistrat cel mai mare debit median la 11 din 12 comenzi. La PING, Dragonfly a măsurat cu 0,6% mai mult, ceea ce se încadrează în limita generatoarelor de încărcare, așa că îl socotim egalitate. Rezultatele se aplică versiunilor și setărilor testate. Vedeți metodologia mai jos.
- Aceeași mașinăFiecare server rulează pe aceeași instanță, pe rând.
- Generatoare de încărcare separateMașini client dedicate creează încărcarea, niciodată serverul însuși.
- Aceleași setăriFiecare server primește același număr de thread-uri și nicio altă optimizare.
- Mediana a 3 rulăriFiecare comandă rulează de trei ori. Se afișează mediana.
- Limite marcateRezultatele stabilite de rețea sau de generatoarele de încărcare sunt semnalate.
- Metoda în întregimeFiecare setare, limită și rezervă este scrisă sub rezultate.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- Arhitectură:
- x86_64
- RAM:
- 314,8 GB
- Rețea:
- 78 Gbps ieșire, 132+ Gbps intrare
- Thread-uri:
- 160 per server (Redis 128, maximul lui)
- Măsurat:
- 9 octombrie 2026
Operații pe secundă, mediana a 3 rulări. Fiecare bară este scalată la cel mai rapid server pentru acea comandă.
- Cel mai bun rezultat la acea comandă.
- Limitat de rețea: rețeaua instanței a stabilit acest rezultat, deci limita proprie a serverului este mai mare.
- Limitat de generatorul de încărcare: mașinile generatoare de încărcare au rulat peste 85% CPU, deci acesta este plafonul lor, nu al serverului.
- Azure măsoară traficul de ieșire: iperf3 a măsurat 78 Gbps ieșire și cel puțin 132 Gbps intrare cu trei mașini client. GET și MGET trimit valori spre exterior. GET-ul HotKV a folosit 88% din plafonul de ieșire, deci este un minim stabilit de instanță, nu o limită a serverului, iar MGET-ul său, la 83%, este aproape. Citirile Dragonfly au folosit cel mult 44% din plafon.
- Scrierile sosesc pe intrare, deci rezultatele la scriere sunt cifre ale serverului. Cea mai grea, SETNX la aproximativ 106 Gbps, a folosit circa 80% din plafonul de intrare, deci tratați cifrele HotKV la scriere ca limite inferioare ușoare.
- La PING, generatoarele de încărcare au ajuns la 86% CPU cu HotKV și la 82% cu Dragonfly. Diferența de 0,6% dintre ele se încadrează în această limită, deci PING este egalitate.
Cifre exacte pentru Azure D160alds_v7
| Comandă | HotKV | Redis | Valkey | Dragonfly | HotKV vs Redis | HotKV vs Valkey | HotKV vs Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Cel mai mare: 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Cel mai mare: 36,643,656(Limitat de rețea) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Cel mai mare: 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Cel mai mare: 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Cel mai mare: 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Cel mai mare: 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Cel mai mare: 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Cel mai mare: 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Cel mai mare: 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Cel mai mare: 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Cel mai mare: 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Limitat de generatorul de încărcare) | 3,235,600 | 3,480,446 | Cel mai mare: 126,033,542 | 38.70x | 35.98x | 0.99x |
Mai rapid decât seturile vectoriale Redis 8 în testul nostru
Am încărcat aceleași embeddinguri OpenAI în HotKV și în Redis 8 și am rulat aceleași 1.000 de interogări pe fiecare, cu 1 până la 100 conexiuni client simultane, pe o singură mașină. Ambele au păstrat vectori cu precizie completă, cu aceleași setări de index.
Interogări pe secundă la același recall
Ambele motoare au stocat vectori float32 cu precizie completă. După încărcarea a 999.000 vectori, procesul HotKV deținea 6,77 GB, iar Redis 7,01 GB.
Nemăsurat: modul implicit cu cuantizare pe 8 biți al Redis, Redis Query Engine, alte seturi de date și alt hardware. Build-ul HotKV este un build de dezvoltare care nu a fost lansat. Redis a fost încărcat fixat pe patru vCPU și căutat pe un index reîncărcat (vedeți articolul).
Cifrele complete: 999.000 vectori, 50 clienți
| ef | Recall HotKV | Recall Redis | Interogări/s HotKV | Interogări/s Redis | Raport |
|---|---|---|---|---|---|
| 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 |
Build HotKV c8dafd37 și Redis 8.10.2, similaritate cosinus, HNSW cu M=16 și ef_construction=200 pe ambele, float32 pe ambele (Redis NOQUANT). Recall-ul este recall@10 față de rezultatele exacte obținute prin forță brută. Mediana a 3 rulări pe Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. Serverele au împărțit 128 vCPU, iar generatoarele de încărcare au rulat pe alte 32, folosind același cod client pentru ambele.
Set de date: embeddinguri dbpedia-entities-openai-1M (OpenAI text-embedding-ada-002, 1.536 dimensiuni) de Kumar Shivendu and Nirant Kasliwal, licențiate MIT, plus 1.000 de interogări rezervate. Metoda completă, scripturi și rezultate brute. Măsurat 14 octombrie 2026.
Sunteți gata să puneți HotKV la treabă?
Obțineți acces anticipat și explorați HotKV pentru sarcina dvs. de lucru.
Acces anticipat