Przedstawiamy HotKV

HotKV to wielowątkowy magazyn danych zgodny z Redis, napisany od zera w nowoczesnym C++, stworzony po to, by wycisnąć jak najwięcej szybkości z nowoczesnych serwerów z wieloma rdzeniami przy możliwie najniższym koszcie. Nazywam się Norbert E. Boros i jestem założycielem oraz CEO HotKV Ltd. Ten wpis wyjaśnia, dlaczego go zbudowałem, co potrafi dziś i jak wypadł w pomiarach.

W skrócie. HotKV wykonuje polecenia na wielu wątkach jednocześnie w jednym procesie i obsługuje RESP2 i RESP3, czyli protokół Redis. W naszym październikowym benchmarku z 2026 roku, na pojedynczej instancji z 160 vCPU, miał najwyższą przepustowość w 11 z 12 zmierzonych poleceń, a w dwunastym Dragonfly był na równi. Konfiguracja i jej ograniczenia są opisane poniżej.

Dlaczego zbudowałem HotKV

Szybkość jest dla mnie ważna we wszystkim, co buduję. Strona internetowa, narzędzie czy serwer powinny reagować natychmiast, a gdy tak nie jest, chcę wiedzieć dlaczego. To nastawienie kształtuje moją pracę, odkąd piszę oprogramowanie.

C i C++ są moimi głównymi językami od wielu lat. Przez prawie dziesięć lat pracowałem nad oprogramowaniem anti-cheat do gier, działającym na komputerach tysięcy graczy. Musiało przeszukiwać pamięć w poszukiwaniu cheatów, zużywając przy tym jak najmniej procesora i pamięci, bo każdy cykl, który zabrało, był odebrany grze. Ta praca nauczyła mnie mierzyć wszystko, projektować pod sprzęt i traktować niskie zużycie zasobów jako osobną funkcję.

Równolegle używałem Redis i Valkey w wielu projektach wymagających szybkiego cache: magazynach sesji, listach adresów IP blokowanych przez firewall i cache przed setkami milionów rekordów w SQL Server. To doskonałe narzędzia. Wzbudziły jednak we mnie ciekawość, co mógłby osiągnąć magazyn klucz-wartość zaprojektowany od początku z myślą o serwerach z wieloma rdzeniami, które dziś uruchamiamy.

HotKV to odpowiedź, do której doszedłem. Napisałem go od zera w nowoczesnym C++, aby wycisnąć ze sprzętu jak najwięcej szybkości przy możliwie najniższym koszcie. Poniższy benchmark pokazuje, gdzie jest dziś, i spodziewam się, że można zyskać jeszcze więcej.

Koszt AI

Był jeszcze drugi powód. Uruchamianie aplikacji AI stawało się drogie, dla mnie i, sądząc po tym, co programiści pisali w sieci, dla wielu innych. Duża część tego kosztu często bierze się z wysyłania do modelu pytań, na które już odpowiedział. Szybki magazyn, który rozpoznaje powtórzone lub podobne pytanie i odpowiada na nie z cache, to jeden z najbardziej bezpośrednich sposobów obniżenia tego rachunku, dlatego cache dla obciążeń AI jest centralną częścią HotKV.

Do czego służy HotKV

HotKV Ltd istnieje, aby uczynić tego rodzaju oprogramowanie wydajniejszym i tańszym. Nowoczesne serwery mają wiele rdzeni, a magazyn danych powinien z nich korzystać, abyś dostał jak najwięcej szybkości za możliwie najniższy koszt.

Druga idea to trzymanie większej części stosu w jednym miejscu. Zespoły budujące na LLM często kończą z uruchomionym cache, bazą wektorową i miejscem na pamięć agentów, z górą kodu sklejającego pomiędzy nimi. Chcę, aby cache i praca AI wokół niego żyły w jednym silniku, obok Twoich danych: dokładne i semantyczne buforowanie wywołań modeli, wyszukiwanie wektorowe, pamięć agentów i budżety tokenów. Mniej systemów do uruchamiania powinno oznaczać mniej ruchomych części i niższy rachunek. Strona AI wymienia to, co jest dostępne dziś, a benchmark oszczędności tokenów pokazuje, ile buforowanie wywołań modeli zaoszczędziło w naszym teście.

HotKV zachowuje protokół Redis i znane biblioteki klienckie.

Problem

Pojedynczy wątek wykonujący polecenia może stać się wąskim gardłem na maszynie z wieloma rdzeniami. Magazyn danych zbudowany wokół jednego wątku wykonawczego zwykle dociera do reszty maszyny, uruchamiając kilka instancji lub klaster, a to niesie ze sobą wybory wdrożeniowe i pracę operacyjną. Chciałem, aby HotKV zaczynał od drugiej strony, z poleceniami wykonywanymi współbieżnie wewnątrz jednej instancji, tak aby pojedynczy proces mógł wykorzystać całą maszynę.

Co HotKV robi inaczej

HotKV™ jest napisany w C++20 i zaprojektowany do wykonywania poleceń na wielu rdzeniach jednocześnie, więc pojedyncza instancja może wykorzystać całą maszynę. Dragonfly, który porównujemy poniżej, również stosuje podejście wielowątkowe.

• Wiele rdzeni, jedna instancja. Polecenia wykonują się współbieżnie na rdzeniach maszyny, więc jedna instancja może wykorzystać duży serwer zamiast kilku mniejszych.
• Znani klienci i protokół. HotKV obsługuje RESP2 i RESP3, więc znane biblioteki klienckie mogą się z nim łączyć. Obsługiwane są transakcje (MULTI/EXEC) i skrypty Lua. Obsługiwane polecenia i ewentualne różnice znajdziesz w dokumentacji poleceń.

Jak jest zbudowany i testowany

HotKV buduję sam i korzystam ze wsparcia AI tam, gdzie pomaga. Ważniejsze od tego, jak powstała dana linia, jest to, czy wytrzymuje próbę, dlatego silnik jest testowany intensywnie. Ma ponad 2000 testów automatycznych i buduje się z AddressSanitizer, ThreadSanitizer i UndefinedBehaviorSanitizer. Ma też cele fuzzingu dla parsera protokołu, dyspozytora poleceń, wczytywania RDB i AOF, strumienia replikacji i magistrali klastra.

Konfiguracja benchmarku, jego ograniczenia i pełne wyniki są na stronie Wydajność, więc możesz sam ocenić liczby.

Migawka benchmarku

Zaktualizowano w październiku 2026: liczby opublikowane pierwotnie w tym wpisie pochodziły z uruchomień benchmarku, które później uznaliśmy za wadliwe (między innymi każdy generator obciążenia używał tego samego ziarna losowego), więc zastąpiliśmy je wynikami z przebudowanego benchmarku.

Październik 2026: HotKV, Redis, Valkey i Dragonfly

Ten benchmark przeprowadził HotKV Ltd. Zmierzyliśmy HotKV zbudowany ze źródeł oraz Redis 8.10.2, Valkey 9.1.2 i Dragonfly 2.0.2. Każdy serwer działał osobno, jako pojedyncza instancja na wszystkich 160 vCPU maszyny Azure D160alds_v7 (AMD EPYC 9V45), z wyłączoną trwałością. Trzy osobne maszyny po 64 vCPU generowały obciążenie przez memtier_benchmark: wartości 256-bajtowe, głębokość potoku 30 i 5 000 000 wstępnie wypełnionych kluczy. Każda liczba to mediana z trzech 10-sekundowych uruchomień.

HotKV miał najwyższą przepustowość w 11 z 12 poleceń. W porównaniu z Redis lub Valkey zmierzył od 8,6 do co najmniej 69,7 razy większą przepustowość, zależnie od polecenia i serwera; w porównaniu z Dragonfly od 1,97 do 4,41 razy w tych 11 poleceniach, przy czym kilka z nich to dolne granice. W PING Dragonfly zmierzył o 0,6 procent więcej. Liczymy to jako remis, ponieważ generatory obciążenia były blisko własnego limitu. Najwyższy wynik w poleceniu danych to 90,8 miliona operacji INCR na sekundę. INCR i PING przenoszą niewiele danych i są ograniczone przez generatory obciążenia, więc własny wynik HotKV dla nich może być wyższy.

Jak czytać tabelę

MGET odczytuje osiem kluczy, a MSET zapisuje cztery pary klucz-wartość na polecenie, a przepustowość liczy polecenia. Raport oznacza siedem wyników HotKV (GET i sześć poleceń zapisu), ponieważ osiągnęły jego próg 85% wykorzystania sieci, oraz PING, ponieważ generatory obciążenia przekroczyły 85% CPU. Stosunki zbudowane na nich są dolnymi granicami, oznaczonymi ≥. GET i PING to rzeczywiste limity. Dla sześciu poleceń zapisu wskaźnik wykorzystania sieci w raporcie sumuje ruch przychodzący i wychodzący i porównuje go z limitem ruchu wychodzącego, więc zawyża, jak blisko limitu były. Najcięższe, SETNX, zużyło najwyżej około 80% zmierzonego limitu ruchu przychodzącego. Zachowujemy ≥ przy nich jako ostrożną konwencję. Pełne tabele, oznaczenia i uwagi o metodzie są na stronie Wydajność.

Zakres benchmarku

• Build i strojenie. HotKV został skompilowany z -march=native pod testowy procesor, podczas gdy pozostałe serwery były standardowymi wydaniami.
• Ustawienia wątków. Każdy serwer dostał wszystkie rdzenie maszyny: HotKV --threads 160, Dragonfly 160 wątków proactor, Valkey io-threads 160 i Redis io-threads 128, jego maksimum. Redis i Valkey wykonują polecenia w jednym wątku i mogą osiągać wyższą przepustowość z mniejszą liczbą wątków I/O, więc ich wyniki mogą być poniżej ich najlepszych. Nie uruchamialiśmy klastrów ani wielu ich instancji.
• Zakres. Dwanaście poleceń, jeden rozmiar wartości, jedna głębokość potoku, bez TLS i bez trwałości. LPOP i RPOP nie były mierzone, ponieważ przy takich tempach destrukcyjny odczyt opróżnia w 10 sekund każdą listę mieszczącą się w pamięci. Raport zapisuje opóźnienia i zużycie pamięci, ale tutaj ich nie porównujemy. Serwery wykonywały bardzo różne ilości pracy w każdym 10-sekundowym uruchomieniu, więc wyniki pamięci nie są porównywalne jeden do jednego. Obciążenia mieszane nie były mierzone.
• Zmienność. Redis bardzo się różnił między trzema uruchomieniami w kilku poleceniach, do 7,2 raza między najszybszym a najwolniejszym uruchomieniem w HSET, a mediana to ukrywa. W porównaniu z najszybszym uruchomieniem każdego konkurenta zamiast z medianą HotKV nadal prowadził we wszystkich 11 poleceniach.

Redis, Valkey i Dragonfly są znakami towarowymi ich właścicieli. Są wymienione wyłącznie w celu identyfikacji zmierzonego oprogramowania i nie oznaczają sponsoringu, poparcia ani powiązania.

Co jest dostępne dziś

Podstawowe rodziny poleceń obejmują ciągi znaków, listy, zbiory, hashe, zbiory posortowane, strumienie, indeksy geoprzestrzenne, bitmapy, HyperLogLog, pub/sub i skrypty Lua. Moduły AI i funkcje enterprise działają w planach z licencją. Cennik wymienia, co zawiera każdy plan. Aktualny zakres poleceń znajdziesz w dokumentacji. Poza zestawem poleceń Redis:

• Tagowanie kluczy: oznaczaj klucze dowolnymi tagami i odpytuj po tagu (TAG.SET, TAG.MEMBERS i pięć kolejnych poleceń).
• TTL w nanosekundach: NEXPIRE, NTTL i NEXPIREAT ustawiają i odczytują wygasanie w nanosekundach, więc terminy mogą być drobniejsze niż milisekunda. Wygasłe klucze są odzyskiwane przez przeszukiwanie w tle i przy dostępie do nich.
• Opcjonalna kompresja wartości: dla wartości powyżej progu rozmiaru (domyślnie 512 bajtów), wyłączona, dopóki jej nie włączysz.
• Migawki bez forka: BGSAVE zapisuje w wątku w tle zamiast w rozwidlonym procesie. Migawka nie jest kopią z jednego punktu w czasie. Każdy klucz jest zapisywany w stanie, w jakim był, gdy migawka do niego dotarła. Przepisywanie pliku tylko do dopisywania robi fork.
• Metryki Prometheus: wbudowany punkt końcowy HTTP, domyślnie wyłączony i włączany przez metrics-port, więc zewnętrzny eksporter nie jest potrzebny.

HotKV ma też wbudowane wyszukiwanie wektorowe z indeksami HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Zmierzyliśmy je względem Redis 8 w Wyszukiwanie wektorowe: HotKV vs zestawy wektorowe Redis 8, od 1 do 100 klientów.

Zacznij w HotKV Cloud albo porozmawiaj ze sprzedażą o uruchomieniu HotKV na własnych serwerach.