Throughput frente a frente
Nos testes da HotKV Ltd com HotKV, Redis, Valkey e Dragonfly em uma instância de nuvem, o HotKV registrou o maior throughput mediano em 11 de 12 comandos. No PING, o Dragonfly mediu 0,6% a mais, dentro do limite dos geradores de carga, então tratamos isso como empate. Esses resultados valem para os builds e as configurações testados. Veja a metodologia abaixo.
- Mesma máquinaTodo servidor roda na mesma instância, um por vez.
- Geradores de carga separadosMáquinas cliente dedicadas geram a carga, nunca a própria máquina do servidor.
- Mesmas configuraçõesTodo servidor recebe a mesma quantidade de threads e nenhum outro ajuste.
- Mediana de 3 execuçõesCada comando roda 3 vezes. A mediana é exibida.
- Limites sinalizadosResultados definidos pela rede ou pelos geradores de carga são sinalizados.
- Método completoCada configuração, limite e ressalva está descrito abaixo dos resultados.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPUs:
- 160
- Arquitetura:
- x86_64
- RAM:
- 314,8 GB
- Rede:
- 78 Gbps de saída, 132+ Gbps de entrada
- Threads:
- 160 por servidor (Redis 128, o máximo dele)
- Medido:
- 9 de outubro de 2026
Operações por segundo, mediana de 3 execuções. Cada barra é dimensionada em relação ao servidor mais rápido naquele comando.
- Maior resultado nesse comando.
- Limitado pela rede: a rede da instância definiu este resultado, então o limite do próprio servidor é maior.
- Limitado pelo gerador de carga: as máquinas geradoras de carga rodaram acima de 85% de CPU, então este é o teto delas, não o do servidor.
- O Azure mede o tráfego de saída: o iperf3 mediu 78 Gbps de saída e pelo menos 132 Gbps de entrada com três máquinas cliente. GET e MGET enviam valores para fora. O GET do HotKV usou 88% do limite de saída, então é um piso definido pela instância, não um limite do servidor, e o MGET dele, com 83%, vem logo atrás. As leituras do Dragonfly usaram no máximo 44% do limite.
- As escritas chegam como tráfego de entrada, então os resultados de escrita são números do servidor. A mais pesada, o SETNX com cerca de 106 Gbps, usou cerca de 80% do teto de entrada, então trate os números de escrita do HotKV como limites inferiores leves.
- No PING, os geradores de carga chegaram a 86% de CPU com o HotKV e a 82% com o Dragonfly. Os 0,6% entre eles estão dentro desse limite, então o PING é um empate.
Números exatos para Azure D160alds_v7
| Comando | HotKV | Redis | Valkey | Dragonfly | HotKV vs. Redis | HotKV vs. Valkey | HotKV vs. Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Maior valor: 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Maior valor: 36,643,656(Limitado pela rede) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Maior valor: 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Maior valor: 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Maior valor: 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Maior valor: 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Maior valor: 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Maior valor: 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Maior valor: 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Maior valor: 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Maior valor: 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Limitado pelo gerador de carga) | 3,235,600 | 3,480,446 | Maior valor: 126,033,542 | 38.70x | 35.98x | 0.99x |
Mais rápido que os vector sets do Redis 8 em nosso teste
Carregamos os mesmos embeddings da OpenAI no HotKV e no Redis 8 e executamos as mesmas 1.000 consultas em cada um, com 1 a 100 conexões de cliente simultâneas, em uma única máquina. Ambos mantinham vetores de precisão total, com as mesmas configurações de índice.
Consultas por segundo com o mesmo recall
Ambos os motores armazenaram vetores float32 de precisão total. Depois de carregar 999.000 vetores, o processo do HotKV ocupava 6,77 GB e o do Redis, 7,01 GB.
Não medido: o modo padrão do Redis com quantização de 8 bits, o Redis Query Engine, outros conjuntos de dados e outro hardware. O build do HotKV é um build de desenvolvimento que não foi lançado. O Redis foi carregado fixado em quatro vCPUs e consultado em um índice recarregado (veja o artigo).
Todos os números: 999.000 vetores, 50 clientes
| ef | Recall do HotKV | Recall do Redis | Consultas/s do HotKV | Consultas/s do Redis | Razão |
|---|---|---|---|---|---|
| 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 c8dafd37 do HotKV e Redis 8.10.2, similaridade de cosseno, HNSW com M=16 e ef_construction=200 em ambos, float32 em ambos (Redis NOQUANT). O recall é o recall@10 em relação a resultados exatos de força bruta. Mediana de 3 execuções em Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. Os servidores compartilharam 128 vCPUs e os geradores de carga rodaram em outras 32, usando o mesmo código de cliente para ambos.
Conjunto de dados: embeddings dbpedia-entities-openai-1M (OpenAI text-embedding-ada-002, 1.536 dimensões) de Kumar Shivendu and Nirant Kasliwal, licenciado sob MIT, mais 1.000 consultas reservadas. Método completo, scripts e resultados brutos. Medido em 14 de outubro de 2026.
Pronto para colocar o HotKV para trabalhar?
Obtenha acesso antecipado e explore o HotKV para a sua carga de trabalho.
Obter acesso antecipado