처리량 정면 비교
HotKV Ltd가 하나의 클라우드 인스턴스에서 HotKV, Redis, Valkey, Dragonfly를 테스트한 결과, HotKV는 12개 명령 중 11개에서 가장 높은 처리량 중앙값을 기록했습니다. PING에서는 Dragonfly가 0.6% 더 높았지만, 이는 부하 생성기의 한계 범위 안에 있으므로 동률로 봅니다. 이 결과는 테스트한 빌드와 설정에만 해당하며, 자세한 내용은 아래 방법론을 참조하십시오.
- 동일한 머신모든 서버를 같은 인스턴스에서 한 번에 하나씩 실행합니다.
- 별도의 부하 생성기부하는 전용 클라이언트 머신이 생성하며, 서버 자체 머신은 절대 사용하지 않습니다.
- 동일한 설정모든 서버에 동일한 스레드 수를 부여하며 그 밖의 튜닝은 하지 않습니다.
- 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일
초당 연산 수, 3회 실행의 중앙값. 각 막대의 길이는 해당 명령에서 가장 빠른 서버를 기준으로 합니다.
- 해당 명령의 최고 결과.
- 네트워크 제한: 인스턴스의 네트워크가 이 결과를 결정했으므로 서버 자체의 한계는 더 높습니다.
- 부하 생성기 제한: 부하 생성기 머신의 CPU 사용률이 85%를 넘었으므로 이 값은 서버가 아니라 부하 생성기의 한계입니다.
- Azure는 아웃바운드 트래픽을 계량합니다: 클라이언트 머신 3대로 iperf3를 측정한 결과 아웃바운드 78 Gbps, 인바운드 최소 132 Gbps였습니다. GET과 MGET은 값을 밖으로 내보냅니다. HotKV의 GET은 아웃바운드 상한의 88%를 사용했으므로 서버의 한계가 아니라 인스턴스가 정한 하한값이며, 83%를 사용한 MGET도 그에 근접합니다. Dragonfly의 읽기는 상한의 최대 44%를 사용했습니다.
- 쓰기는 인바운드로 들어오므로 쓰기 결과는 서버 자체의 수치입니다. 가장 무거운 SETNX는 약 106 Gbps로 인바운드 상한의 약 80%를 사용했으므로, HotKV의 쓰기 수치는 다소 낮게 잡힌 하한값으로 보아야 합니다.
- PING에서 부하 생성기의 CPU 사용률은 HotKV에서 86%, Dragonfly에서 82%에 도달했습니다. 둘 사이의 0.6% 차이는 이 한계 범위 안에 있으므로 PING은 동률입니다.
Azure D160alds_v7의 정확한 수치
| 명령 | HotKV | Redis | Valkey | Dragonfly | HotKV 대 Redis | HotKV 대 Valkey | HotKV 대 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~100개로 각각에 동일한 쿼리 1,000개를 실행했습니다. 두 엔진 모두 동일한 인덱스 설정으로 전체 정밀도 벡터를 보관했습니다.
동일한 재현율에서의 초당 쿼리 수
두 엔진 모두 전체 정밀도 float32 벡터를 저장했습니다. 벡터 999,000개를 로드한 후 HotKV 프로세스는 6.77 GB, Redis는 7.01 GB를 사용했습니다.
측정하지 않은 항목: Redis의 기본 8비트 양자화 모드, Redis Query Engine, 다른 데이터셋, 다른 하드웨어. HotKV 빌드는 아직 출시되지 않은 개발 빌드입니다. Redis는 vCPU 4개에 고정된 상태로 로딩되었고 다시 불러온 인덱스에서 검색되었습니다 (기사 참고).
전체 수치: 벡터 999,000개, 클라이언트 50개
| ef | HotKV 재현율 | Redis 재현율 | HotKV 쿼리/s | Redis 쿼리/s | 비율 |
|---|---|---|---|---|---|
| 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). 재현율은 정확한 전수 탐색(brute-force) 결과 대비 recall@10입니다. Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs에서 3회 실행한 중앙값입니다. 서버들은 vCPU 128개를 공유했고 부하 생성기는 별도의 vCPU 32개에서 실행되었으며, 양쪽에 동일한 클라이언트 코드를 사용했습니다.
데이터셋: Kumar Shivendu and Nirant Kasliwal의 dbpedia-entities-openai-1M 임베딩(OpenAI text-embedding-ada-002, 1,536차원), MIT 라이선스, 별도 보관 쿼리 1,000개 포함. 전체 방법, 스크립트, 원시 결과. 측정일: 2026년 10월 14일.