Bezpośrednie porównanie przepustowości
W teście HotKV Ltd obejmującym HotKV, Redis, Valkey i Dragonfly na jednej instancji chmurowej HotKV uzyskał najwyższą medianę przepustowości w 11 z 12 poleceń. W PING Dragonfly zmierzył 0,6% więcej, co mieści się w granicach możliwości generatorów obciążenia, więc liczymy to jako remis. Wyniki dotyczą przetestowanych wersji i ustawień. Zobacz metodologię poniżej.
- Ta sama maszynaKażdy serwer działa na tej samej instancji, jeden po drugim.
- Osobne generatory obciążeniaObciążenie tworzą dedykowane maszyny klienckie, nigdy sam serwer.
- Te same ustawieniaKażdy serwer dostaje tę samą liczbę wątków i żadnego innego strojenia.
- Mediana z 3 uruchomieńKażde polecenie działa trzy razy. Pokazana jest mediana.
- Oznaczone limityWyniki wyznaczone przez sieć lub generatory obciążenia są oznaczone.
- Pełna metodaKażde ustawienie, limit i zastrzeżenie jest opisane pod wynikami.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- Arch.:
- x86_64
- RAM:
- 314,8 GB
- Sieć:
- 78 Gbps wychodzące, 132+ Gbps przychodzące
- Wątki:
- 160 na serwer (Redis 128, jego maksimum)
- Zmierzono:
- 9 października 2026
Operacje na sekundę, mediana z 3 uruchomień. Każdy słupek jest skalowany do najszybszego serwera w danym poleceniu.
- Najwyższy wynik w danym poleceniu.
- Ograniczone siecią: wynik wyznaczyła sieć instancji, więc własny limit serwera jest wyższy.
- Ograniczone generatorem obciążenia: maszyny generujące obciążenie działały powyżej 85% CPU, więc to ich sufit, a nie serwera.
- Azure mierzy ruch wychodzący: iperf3 zmierzył 78 Gbps wychodzących i co najmniej 132 Gbps przychodzących przy trzech maszynach klienckich. GET i MGET wysyłają wartości na zewnątrz. GET w HotKV zużył 88% limitu ruchu wychodzącego, więc jest to dolna granica wyznaczona przez instancję, a nie limit serwera, a jego MGET, z 83%, jest tuż za nim. Odczyty Dragonfly zużyły najwyżej 44% limitu.
- Zapisy przychodzą jako ruch przychodzący, więc wyniki zapisów są liczbami serwera. Najcięższy, SETNX przy około 106 Gbps, zużył około 80% limitu ruchu przychodzącego, więc wyniki zapisów HotKV traktuj jako łagodne dolne granice.
- W PING generatory obciążenia osiągnęły 86% CPU z HotKV i 82% z Dragonfly. Różnica 0,6% między nimi mieści się w tym limicie, więc PING to remis.
Dokładne liczby dla Azure D160alds_v7
| Polecenie | HotKV | Redis | Valkey | Dragonfly | HotKV vs Redis | HotKV vs Valkey | HotKV vs Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Najwyższy: 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Najwyższy: 36,643,656(Ograniczone siecią) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Najwyższy: 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Najwyższy: 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Najwyższy: 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Najwyższy: 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Najwyższy: 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Najwyższy: 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Najwyższy: 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Najwyższy: 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Najwyższy: 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Ograniczone generatorem obciążenia) | 3,235,600 | 3,480,446 | Najwyższy: 126,033,542 | 38.70x | 35.98x | 0.99x |
Szybszy niż zestawy wektorowe Redis 8 w naszym teście
Wczytaliśmy te same embeddingi OpenAI do HotKV i Redis 8 i wykonaliśmy te same 1000 zapytań na każdym, przy 1 do 100 równoległych połączeniach klientów, na jednej maszynie. Oba przechowywały wektory o pełnej precyzji, z tymi samymi ustawieniami indeksu.
Zapytania na sekundę przy tym samym recallu
Oba silniki przechowywały wektory float32 o pełnej precyzji. Po wczytaniu 999 000 wektorów proces HotKV zajmował 6,77 GB, a Redis 7,01 GB.
Nie zmierzono: domyślnego 8-bitowego trybu skwantowanego Redis, Redis Query Engine, innych zbiorów danych i innego sprzętu. Build HotKV to wersja deweloperska, która nie została wydana. Redis został wczytany przypięty do czterech vCPU i przeszukiwany na ponownie wczytanym indeksie (zobacz artykuł).
Pełne liczby: 999 000 wektorów, 50 klientów
| ef | Recall HotKV | Recall Redis | Zapytania/s HotKV | Zapytania/s Redis | Stosunek |
|---|---|---|---|---|---|
| 40 | 0,940 | 0,923 | 63 897 | 8061 | 7,9x |
| 80 | 0,970 | 0,962 | 37 508 | 6825 | 5,5x |
| 150 | 0,987 | 0,980 | 21 912 | 5241 | 4,2x |
| 300 | 0,993 | 0,990 | 12 393 | 3454 | 3,6x |
| 500 | 0,997 | 0,994 | 7688 | 2483 | 3,1x |
Build HotKV c8dafd37 i Redis 8.10.2, podobieństwo cosinusowe, HNSW z M=16 i ef_construction=200 w obu, float32 w obu (Redis NOQUANT). Recall to recall@10 względem dokładnych wyników brute-force. Mediana z 3 uruchomień na Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. Serwery dzieliły 128 vCPU, a generatory obciążenia działały na 32 innych, z tym samym kodem klienta dla obu.
Zbiór danych: embeddingi dbpedia-entities-openai-1M (OpenAI text-embedding-ada-002, 1536 wymiarów) autorstwa Kumar Shivendu and Nirant Kasliwal, licencja MIT, plus 1000 zapytań wyłączonych ze zbioru. Pełna metoda, skrypty i surowe wyniki. Zmierzono 14 października 2026.
Gotowy, by wykorzystać HotKV?
Uzyskaj wczesny dostęp i sprawdź HotKV na swoim obciążeniu.
Uzyskaj wczesny dostęp