Memperkenalkan HotKV

HotKV adalah data store multithread yang kompatibel dengan Redis, ditulis dari nol dalam C++ modern, dibangun untuk mendapatkan kecepatan sebesar mungkin dari server many-core modern dengan biaya serendah mungkin. Saya Norbert E. Boros, pendiri dan CEO HotKV Ltd. Tulisan ini menjelaskan mengapa saya membangunnya, apa yang dilakukannya hari ini, dan bagaimana hasil pengukurannya.

Singkatnya. HotKV menjalankan perintah pada banyak thread sekaligus dalam satu proses dan berbicara RESP2 dan RESP3, protokol Redis. Dalam benchmark instance tunggal kami pada Oktober 2026 dengan 160 vCPU, HotKV memiliki throughput tertinggi pada 11 dari 12 perintah yang kami ukur, dan Dragonfly setara pada yang kedua belas. Pengaturan dan batasannya dijelaskan di bawah.

Mengapa saya membangun HotKV

Saya peduli pada kecepatan dalam segala hal yang saya bangun. Sebuah situs web, alat, atau server harus merespons seketika, dan ketika tidak, saya ingin tahu mengapa. Kebiasaan itu telah membentuk pekerjaan saya sejak saya menulis perangkat lunak.

C dan C++ telah menjadi bahasa utama saya selama bertahun-tahun. Selama hampir sepuluh tahun saya mengerjakan perangkat lunak anti-cheat game yang berjalan di PC ribuan pemain. Ia harus memindai memori untuk mencari cheat sambil memakai CPU dan memori sesedikit mungkin, karena setiap siklus yang dipakainya diambil dari game. Pekerjaan itu mengajari saya mengukur segalanya, merancang di sekitar perangkat keras, dan memperlakukan pemakaian sumber daya yang rendah sebagai fitur tersendiri.

Di samping itu, saya memakai Redis dan Valkey dalam banyak proyek yang membutuhkan cache cepat: session store, daftar alamat IP yang diblokir firewall, dan cache di depan ratusan juta rekaman SQL Server. Keduanya adalah alat yang sangat baik. Keduanya juga membuat saya penasaran tentang apa yang bisa dilakukan sebuah key-value store jika dirancang sejak awal untuk server many-core yang kita jalankan sekarang.

HotKV adalah jawaban yang saya capai. Saya menulisnya dari nol dalam C++ modern untuk mendapatkan kecepatan sebanyak mungkin dari perangkat keras, dengan biaya serendah mungkin. Benchmark di bawah menunjukkan posisinya hari ini, dan saya perkirakan masih ada yang bisa diperoleh.

Biaya AI

Ada alasan kedua. Menjalankan aplikasi AI menjadi mahal, bagi saya dan, menilai dari apa yang dibagikan developer secara online, bagi banyak orang lain juga. Sebagian besar biaya itu sering berasal dari mengirim kepada model pertanyaan yang sudah dijawabnya. Store cepat yang mengenali pertanyaan yang berulang atau serupa dan menjawabnya dari cache adalah salah satu cara paling langsung untuk memangkas tagihan itu, itulah sebabnya caching untuk beban kerja AI adalah bagian inti dari HotKV.

Untuk apa HotKV ada

HotKV Ltd ada untuk membuat perangkat lunak semacam ini lebih berperforma dan lebih terjangkau. Server modern memiliki banyak core, dan data store harus memakainya, agar Anda mendapatkan kecepatan sebesar mungkin dengan biaya serendah mungkin.

Gagasan kedua adalah menyimpan lebih banyak bagian stack di satu tempat. Tim yang membangun di atas LLM sering akhirnya menjalankan cache, vector database, dan tempat menyimpan memori agen, dengan setumpuk kode perekat di antaranya. Saya ingin caching dan pekerjaan AI di sekitarnya berada dalam satu mesin, di samping data Anda: caching persis dan semantik untuk panggilan model, vector search, memori agen, dan anggaran token. Lebih sedikit sistem untuk dijalankan seharusnya berarti lebih sedikit bagian yang bergerak dan tagihan yang lebih rendah. Halaman AI mendaftar apa yang tersedia hari ini, dan benchmark penghematan token menunjukkan apa yang dihemat dengan meng-cache panggilan model dalam pengujian kami.

HotKV mempertahankan protokol Redis dan pustaka klien yang sudah dikenal.

Masalahnya

Satu thread eksekusi perintah dapat menjadi hambatan pada mesin dengan banyak core. Data store yang dibangun di sekitar satu thread eksekusi biasanya menjangkau sisa mesin dengan menjalankan beberapa instance atau klaster, dan itu membawa pilihan deployment dan pekerjaan operasional. Saya ingin HotKV mulai dari ujung yang lain, dengan perintah berjalan bersamaan di dalam satu instance, sehingga satu proses dapat memakai seluruh mesin.

Apa yang dilakukan HotKV secara berbeda

HotKV™ ditulis dalam C++20 dan dirancang untuk menjalankan perintah di banyak core sekaligus, sehingga satu instance dapat memanfaatkan seluruh mesin. Dragonfly, yang kami benchmark di bawah, juga mengambil pendekatan multithread.

• Banyak core, satu instance. Perintah berjalan bersamaan di seluruh core mesin, sehingga satu instance dapat memakai server besar sebagai ganti beberapa yang lebih kecil.
• Klien dan protokol yang sudah dikenal. HotKV mendukung RESP2 dan RESP3, sehingga pustaka klien yang sudah dikenal dapat terhubung ke HotKV. Transaksi (MULTI/EXEC) dan scripting Lua didukung. Lihat dokumentasi perintah untuk perintah yang didukung dan perbedaan apa pun.

Cara ia dibangun dan diuji

Saya membangun HotKV sendiri dan memakai bantuan AI di tempat yang berguna. Yang lebih penting daripada bagaimana sebuah baris ditulis adalah apakah ia tahan uji, jadi mesin ini diuji dengan keras. Ia memiliki lebih dari 2.000 pengujian otomatis dan dibangun di bawah AddressSanitizer, ThreadSanitizer, dan UndefinedBehaviorSanitizer. Ia juga memiliki target fuzz untuk parser protokol, dispatch perintah, pemuatan RDB dan AOF, stream replikasi, dan bus klaster.

Pengaturan benchmark, batasannya, dan hasil lengkap ada di halaman Performa, sehingga Anda dapat menilai angkanya sendiri.

Cuplikan benchmark

Diperbarui Oktober 2026: angka yang pertama kali dipublikasikan dalam tulisan ini berasal dari eksekusi benchmark yang kemudian kami temukan cacat (antara lain, setiap generator beban memakai seed acak yang sama), jadi kami menggantinya dengan hasil dari benchmark kami yang dibangun ulang.

Oktober 2026: HotKV, Redis, Valkey, dan Dragonfly

HotKV Ltd menjalankan benchmark ini. Kami mengukur HotKV, yang dibangun dari sumber, terhadap Redis 8.10.2, Valkey 9.1.2, dan Dragonfly 2.0.2. Setiap server berjalan sendiri, sebagai instance tunggal pada seluruh 160 vCPU dari Azure D160alds_v7 (AMD EPYC 9V45), dengan persistensi mati. Tiga mesin 64-vCPU terpisah menghasilkan beban dengan memtier_benchmark: nilai 256 byte, kedalaman pipeline 30, dan 5.000.000 kunci yang diisi lebih dulu. Setiap angka adalah median dari tiga kali jalan selama 10 detik.

HotKV memiliki throughput tertinggi pada 11 dari 12 perintah. Terhadap Redis atau Valkey, ia terukur antara 8,6 dan setidaknya 69,7 kali throughput mereka, tergantung perintah dan server; terhadap Dragonfly, antara 1,97 dan 4,41 kali pada 11 perintah tersebut, beberapa di antaranya merupakan batas bawah. Pada PING Dragonfly terukur 0,6 persen lebih tinggi. Kami menghitungnya sebagai seri, karena generator beban mendekati batasnya sendiri. Angka tertinggi pada perintah data adalah 90,8 juta operasi INCR per detik. INCR dan PING memindahkan sedikit data dan dibatasi oleh generator beban, jadi angka HotKV sendiri untuk keduanya mungkin lebih tinggi.

Membaca tabel

MGET membaca delapan kunci dan MSET menulis empat pasangan kunci-nilai per perintah, dan throughput menghitung perintah. Laporan menandai tujuh angka HotKV (GET dan enam perintah tulis) karena mencapai ambang batas pemakaian jaringan 85%, dan PING karena generator beban berada di atas 85% CPU. Rasio yang dibangun di atasnya adalah batas bawah, ditandai dengan ≥. GET dan PING adalah batas yang sebenarnya. Untuk enam perintah tulis, angka pemakaian jaringan dalam laporan menjumlahkan trafik masuk dan keluar dan membandingkannya dengan batas keluar, sehingga melebih-lebihkan seberapa dekat mereka dengan batas. Yang terberat, SETNX, memakai paling banyak sekitar 80% dari batas masuk yang terukur. Kami mempertahankan ≥ pada mereka sebagai konvensi yang konservatif. Tabel lengkap, tanda, dan catatan metode ada di halaman Performa.

Lingkup benchmark

• Build dan penyetelan. HotKV dikompilasi dengan -march=native untuk CPU pengujian, sementara server lain adalah build rilis standar mereka.
• Pengaturan thread. Setiap server diberi seluruh core mesin: HotKV --threads 160, Dragonfly 160 proactor thread, Valkey io-threads 160, dan Redis io-threads 128, maksimumnya. Redis dan Valkey menjalankan perintah pada satu thread dan mungkin mencapai throughput lebih tinggi dengan I/O thread yang lebih sedikit, jadi angka mereka mungkin di bawah yang terbaik. Kami tidak menjalankan klaster atau beberapa instance dari mereka.
• Cakupan. Dua belas perintah, satu ukuran nilai, satu kedalaman pipeline, tanpa TLS dan tanpa persistensi. LPOP dan RPOP tidak diukur, karena pada laju ini pembacaan destruktif mengosongkan list apa pun yang muat di memori dalam 10 detik. Laporan mencatat latensi dan pemakaian memori, tetapi kami tidak membandingkannya di sini. Server melakukan jumlah pekerjaan yang sangat berbeda dalam setiap eksekusi 10 detik, jadi angka memori tidak sebanding. Beban kerja campuran tidak diukur.
• Variasi. Redis bervariasi lebar di antara tiga kali jalannya pada beberapa perintah, hingga 7,2 kali antara jalan tercepat dan terlambatnya pada HSET, dan median menyembunyikan hal itu. Dibandingkan dengan jalan tercepat setiap pesaing, bukan mediannya, HotKV tetap unggul pada semua 11 perintah.

Redis, Valkey, dan Dragonfly adalah merek dagang dari masing-masing pemiliknya. Nama itu disebut hanya untuk mengidentifikasi perangkat lunak yang kami ukur, dan ini tidak menyiratkan sponsor, dukungan, atau afiliasi.

Apa yang tersedia hari ini

Keluarga perintah inti mencakup string, list, set, hash, sorted set, stream, indeks geospasial, bitmap, HyperLogLog, pub/sub, dan scripting Lua. Modul AI dan fitur enterprise berjalan pada paket berlisensi. Harga mendaftar apa yang disertakan setiap paket. Lihat dokumentasi untuk cakupan perintah saat ini. Di luar kumpulan perintah Redis:

• Tagging kunci: beri label pada kunci dengan tag sembarang dan kueri menurut tag (TAG.SET, TAG.MEMBERS, dan lima perintah lain).
• TTL nanodetik: NEXPIRE, NTTL, dan NEXPIREAT mengatur dan membaca kedaluwarsa dalam nanodetik, sehingga tenggat dapat lebih halus dari satu milidetik. Kunci yang kedaluwarsa direklamasi oleh sapuan di background dan saat diakses.
• Kompresi nilai opsional: untuk nilai di atas ambang ukuran (512 byte secara default), nonaktif kecuali Anda mengaktifkannya.
• Snapshot tanpa fork: BGSAVE menulis di background thread, bukan proses hasil fork. Snapshot bukan salinan point-in-time. Setiap kunci disimpan sebagaimana adanya saat snapshot mencapainya. Penulisan ulang append-only file memang melakukan fork.
• Metrik Prometheus: endpoint HTTP bawaan, nonaktif secara default dan diaktifkan dengan metrics-port, sehingga tidak perlu exporter eksternal.

HotKV juga memiliki vector search bawaan dengan indeks HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Kami mengukurnya terhadap Redis 8 dalam Vector search: HotKV vs vector set Redis 8, dari 1 hingga 100 klien.

Mulai di HotKV Cloud, atau hubungi bagian penjualan tentang menjalankan HotKV di server Anda sendiri.