Vorstellung von HotKV

HotKV ist ein multithreaded, Redis-kompatibler Datenspeicher, von Grund auf in modernem C++ geschrieben und darauf ausgelegt, auf modernen Servern mit vielen Kernen die größtmögliche Geschwindigkeit zu den geringstmöglichen Kosten zu erreichen. Ich bin Norbert E. Boros, Gründer und CEO von HotKV Ltd. Dieser Beitrag erklärt, warum ich es gebaut habe, was es heute kann und wie es im Test abgeschnitten hat.

Kurz gesagt. HotKV führt Befehle auf vielen Threads gleichzeitig in einem einzigen Prozess aus und spricht RESP2 und RESP3, das Redis-Protokoll. In unserem Benchmark mit einer einzelnen Instanz auf 160 vCPUs im Oktober 2026 erzielte es bei 11 der 12 gemessenen Befehle den höchsten Durchsatz, und beim zwölften war Dragonfly gleichauf. Der Aufbau und seine Grenzen sind unten beschrieben.

Warum ich HotKV gebaut habe

Geschwindigkeit ist mir bei allem wichtig, was ich baue. Eine Website, ein Tool oder ein Server sollte sofort reagieren, und wenn das nicht so ist, will ich wissen, warum. Diese Haltung prägt meine Arbeit, seit ich Software schreibe.

C und C++ sind seit vielen Jahren meine Hauptsprachen. Fast zehn Jahre lang habe ich an Anti-Cheat-Software für Spiele gearbeitet, die auf den PCs von Tausenden Spielern lief. Sie musste den Arbeitsspeicher nach Cheats durchsuchen und dabei so wenig CPU und Speicher wie möglich beanspruchen, denn jeder Zyklus, den sie verbrauchte, fehlte dem Spiel. Diese Arbeit hat mich gelehrt, alles zu messen, das Design an der Hardware auszurichten und einen geringen Ressourcenverbrauch als eigenständiges Feature zu betrachten.

Daneben habe ich Redis und Valkey in vielen Projekten eingesetzt, die einen schnellen Cache brauchten: Session-Stores, Listen von IP-Adressen, die eine Firewall blockierte, und ein Cache vor Hunderten Millionen Datensätzen in SQL Server. Das sind hervorragende Werkzeuge. Sie haben mich aber auch neugierig darauf gemacht, was ein Key-Value-Store leisten könnte, wenn er von Anfang an für die Server mit vielen Kernen entworfen wäre, die wir heute betreiben.

HotKV ist die Antwort, zu der ich gekommen bin. Ich habe es von Grund auf in modernem C++ geschrieben, um so viel Geschwindigkeit wie möglich aus der Hardware zu holen, zu den geringstmöglichen Kosten. Der Benchmark unten zeigt, wo es heute steht, und ich gehe davon aus, dass noch mehr zu gewinnen ist.

Die Kosten von KI

Es gab einen zweiten Grund. KI-Anwendungen zu betreiben wurde teuer, für mich und, nach dem zu urteilen, was Entwickler online berichteten, auch für viele andere. Ein großer Teil dieser Kosten entsteht oft dadurch, dass man einem Modell Fragen schickt, die es bereits beantwortet hat. Ein schneller Speicher, der eine wiederholte oder ähnliche Frage erkennt und sie aus dem Cache beantwortet, ist einer der direktesten Wege, diese Rechnung zu senken. Deshalb ist Caching für KI-Workloads ein zentraler Bestandteil von HotKV.

Wofür HotKV da ist

HotKV Ltd gibt es, um diese Art von Software leistungsfähiger und erschwinglicher zu machen. Moderne Server haben viele Kerne, und ein Datenspeicher sollte sie nutzen, damit Sie so viel Geschwindigkeit wie möglich zu den geringstmöglichen Kosten bekommen.

Die zweite Idee ist, mehr vom Stack an einem Ort zu bündeln. Teams, die auf LLMs aufbauen, betreiben am Ende oft einen Cache, eine Vektordatenbank und irgendeinen Ort für den Agentenspeicher, mit einer Menge Glue-Code dazwischen. Ich möchte, dass Caching und die KI-Arbeit darum herum in einer Engine leben, direkt neben Ihren Daten: exaktes und semantisches Caching von Modellaufrufen, Vektorsuche, Agentenspeicher und Token-Budgets. Weniger Systeme im Betrieb sollten weniger bewegliche Teile und eine niedrigere Rechnung bedeuten. Die KI-Seite listet auf, was heute verfügbar ist, und der Benchmark zur Token-Einsparung zeigt, was das Caching von Modellaufrufen in unserem Test eingespart hat.

HotKV behält das Redis-Protokoll und vertraute Client-Bibliotheken bei.

Das Problem

Ein einzelner Thread für die Befehlsausführung kann auf einer Maschine mit vielen Kernen zum Engpass werden. Ein Datenspeicher, der um einen einzigen Ausführungsthread herum aufgebaut ist, erschließt den Rest der Maschine meist dadurch, dass mehrere Instanzen oder ein Cluster betrieben werden, und das bringt Entscheidungen beim Deployment und betrieblichen Aufwand mit sich. Ich wollte, dass HotKV vom anderen Ende her ansetzt, mit Befehlen, die gleichzeitig innerhalb einer Instanz laufen, sodass ein einzelner Prozess die ganze Maschine nutzen kann.

Was HotKV anders macht

HotKV™ ist in C++20 geschrieben und darauf ausgelegt, Befehle auf vielen Kernen gleichzeitig auszuführen, sodass eine einzelne Instanz eine ganze Maschine nutzen kann. Auch Dragonfly, das wir unten im Benchmark messen, verfolgt einen Multithreading-Ansatz.

• Viele Kerne, eine Instanz. Befehle laufen gleichzeitig auf den Kernen der Maschine, sodass eine Instanz einen großen Server nutzen kann, statt mehrerer kleinerer.
• Vertraute Clients und vertrautes Protokoll. HotKV unterstützt RESP2 und RESP3, sodass sich vertraute Client-Bibliotheken damit verbinden können. Transaktionen (MULTI/EXEC) und Lua-Scripting werden unterstützt. Die unterstützten Befehle und etwaige Unterschiede stehen in der Befehlsdokumentation.

Wie es gebaut und getestet wird

Ich baue HotKV selbst und setze KI-Unterstützung ein, wo sie hilft. Wichtiger als die Frage, wie eine Zeile entstanden ist, ist, ob sie standhält, deshalb wird die Engine hart getestet. Sie hat mehr als 2.000 automatisierte Tests und wird mit AddressSanitizer, ThreadSanitizer und UndefinedBehaviorSanitizer gebaut. Außerdem gibt es Fuzz-Targets für den Protokoll-Parser, den Befehls-Dispatch, das Laden von RDB und AOF, den Replikationsstrom und den Cluster-Bus.

Der Aufbau des Benchmarks, seine Grenzen und die vollständigen Ergebnisse stehen auf der Performance-Seite, damit Sie die Zahlen selbst beurteilen können.

Benchmark-Momentaufnahme

Aktualisiert im Oktober 2026: Die zuerst in diesem Beitrag veröffentlichten Zahlen stammten aus Benchmark-Läufen, die sich später als fehlerhaft herausstellten (unter anderem verwendeten alle Lastgeneratoren denselben Zufalls-Seed). Wir haben sie daher durch Ergebnisse aus unserem neu aufgebauten Benchmark ersetzt.

Oktober 2026: HotKV, Redis, Valkey und Dragonfly

HotKV Ltd hat diesen Benchmark durchgeführt. Wir haben HotKV, aus dem Quellcode gebaut, gegen Redis 8.10.2, Valkey 9.1.2 und Dragonfly 2.0.2 gemessen. Jeder Server lief allein, als einzelne Instanz auf allen 160 vCPUs einer Azure D160alds_v7 (AMD EPYC 9V45), mit ausgeschalteter Persistenz. Drei separate Maschinen mit je 64 vCPUs erzeugten die Last mit memtier_benchmark: Werte mit 256 Byte, eine Pipeline-Tiefe von 30 und 5.000.000 vorab befüllte Keys. Jeder Wert ist der Median aus drei Läufen von je 10 Sekunden.

HotKV erzielte bei 11 der 12 Befehle den höchsten Durchsatz. Gegenüber Redis oder Valkey lag er je nach Befehl und Server zwischen dem 8,6-Fachen und mindestens dem 69,7-Fachen von deren Durchsatz; gegenüber Dragonfly lag er bei diesen 11 Befehlen zwischen dem 1,97- und dem 4,41-Fachen, mehrere davon als Untergrenzen. Bei PING lag Dragonfly um 0,6 Prozent vorn. Wir werten das als Gleichstand, weil die Lastgeneratoren nahe an ihrer eigenen Grenze lagen. Der höchste Wert bei einem Datenbefehl waren 90,8 Millionen INCR-Operationen pro Sekunde. INCR und PING bewegen wenig Daten und werden durch die Lastgeneratoren begrenzt, sodass der eigene Wert von HotKV dafür höher liegen kann.

Die Tabelle richtig lesen

MGET liest pro Befehl acht Keys und MSET schreibt vier Key-Value-Paare, und der Durchsatz zählt Befehle. Der Bericht markiert sieben Werte von HotKV (GET und sechs Schreibbefehle), weil sie seine Schwelle von 85 % Netzwerknutzung erreichten, und PING, weil die Lastgeneratoren über 85 % CPU-Auslastung lagen. Verhältnisse, die auf ihnen beruhen, sind Untergrenzen und mit ≥ gekennzeichnet. Bei GET und PING handelt es sich um echte Limits. Bei den sechs Schreibbefehlen addiert der Netzwerkwert des Berichts eingehenden und ausgehenden Datenverkehr und vergleicht die Summe mit der Obergrenze für ausgehenden Verkehr, überzeichnet also, wie nah sie an einem Limit lagen. Der datenintensivste, SETNX, nutzte höchstens etwa 80 % der gemessenen Obergrenze für eingehenden Verkehr. Wir behalten das ≥ bei ihnen als konservative Konvention bei. Die vollständigen Tabellen, Markierungen und Methodenhinweise stehen auf der Performance-Seite.

Umfang des Benchmarks

• Build und Tuning. HotKV wurde mit -march=native für die Test-CPU kompiliert, die anderen Server liefen als unveränderte Standard-Release-Builds.
• Thread-Einstellungen. Jeder Server erhielt alle Kerne der Maschine: HotKV --threads 160, Dragonfly 160 Proactor-Threads, Valkey io-threads 160 und Redis io-threads 128, sein Maximum. Redis und Valkey führen Befehle auf einem Thread aus und erreichen mit weniger I/O-Threads möglicherweise einen höheren Durchsatz, ihre Werte liegen daher womöglich unter ihrem Bestwert. Cluster oder mehrere Instanzen davon haben wir nicht betrieben.
• Messumfang. Zwölf Befehle, eine Wertgröße, eine Pipeline-Tiefe, kein TLS und keine Persistenz. LPOP und RPOP wurden nicht gemessen, weil bei diesen Raten ein destruktives Lesen jede Liste, die in den Speicher passt, innerhalb von 10 Sekunden leert. Der Bericht erfasst Latenz und Speichernutzung, wir vergleichen sie hier aber nicht. Die Server leisteten in jedem Lauf von 10 Sekunden sehr unterschiedlich viel Arbeit, daher sind die Speicherwerte nicht direkt vergleichbar. Gemischte Workloads wurden nicht gemessen.
• Streuung. Redis schwankte bei mehreren Befehlen stark zwischen seinen drei Läufen, bei HSET bis zum 7,2-Fachen zwischen dem schnellsten und dem langsamsten Lauf, und der Median verdeckt das. Verglichen mit dem schnellsten Lauf jedes Konkurrenten statt mit seinem Median lag HotKV weiterhin bei allen 11 Befehlen vorn.

Redis, Valkey und Dragonfly sind Marken ihrer jeweiligen Inhaber. Sie werden nur genannt, um die von uns gemessene Software zu bezeichnen; damit wird weder ein Sponsoring noch eine Empfehlung noch eine Verbindung impliziert.

Was heute ausgeliefert wird

Zu den Kern-Befehlsfamilien gehören Strings, Listen, Sets, Hashes, Sorted Sets, Streams, Geodaten-Indizes, Bitmaps, HyperLogLog, Pub/Sub und Lua-Scripting. Die KI-Module und Enterprise-Funktionen laufen in lizenzierten Tarifen. Auf der Seite Preise steht, was jeder Tarif enthält. Die aktuelle Befehlsabdeckung finden Sie in der Dokumentation. Über den Redis-Befehlssatz hinaus:

• Key-Tagging: Keys lassen sich mit beliebigen Tags versehen und nach Tag abfragen (TAG.SET, TAG.MEMBERS und fünf weitere Befehle).
• Nanosekunden-TTL: NEXPIRE, NTTL und NEXPIREAT setzen und lesen den Ablauf in Nanosekunden, sodass Fristen feiner als eine Millisekunde sein können. Abgelaufene Keys werden durch einen Sweep im Hintergrund und beim Zugriff bereinigt.
• Optionale Wertkompression: für Werte oberhalb einer Größenschwelle (standardmäßig 512 Byte), ausgeschaltet, solange Sie sie nicht einschalten.
• Snapshots ohne Fork: BGSAVE schreibt auf einem Hintergrund-Thread statt in einem geforkten Prozess. Ein Snapshot ist keine Point-in-Time-Kopie. Jeder Key wird so gespeichert, wie er war, als der Snapshot ihn erreichte. Das Neuschreiben der Append-only-Datei nutzt dagegen einen Fork.
• Prometheus-Metriken: ein integrierter HTTP-Endpunkt, standardmäßig aus und mit metrics-port aktiviert, sodass kein externer Exporter nötig ist.

HotKV bietet außerdem eine integrierte Vektorsuche mit HNSW-Indizes (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Wir haben sie in Vektorsuche: HotKV vs. Redis 8 Vector Sets, von 1 bis 100 Clients gegen Redis 8 gemessen.

Starten Sie auf HotKV Cloud oder sprechen Sie mit dem Vertrieb darüber, HotKV auf Ihren eigenen Servern zu betreiben.