HotKV का परिचय

HotKV एक मल्टीथ्रेडेड, Redis-संगत डेटा स्टोर है। इसे आधुनिक C++ में शुरू से लिखा गया है, ताकि आधुनिक मल्टी-कोर सर्वरों से कम से कम लागत पर अधिक से अधिक गति मिल सके। मैं Norbert E. Boros हूँ, HotKV Ltd का संस्थापक और CEO। यह पोस्ट बताती है कि मैंने इसे क्यों बनाया, यह आज क्या करता है और माप में इसका प्रदर्शन कैसा रहा।

संक्षेप में। HotKV एक ही प्रोसेस के भीतर कई थ्रेड पर एक साथ कमांड चलाता है और RESP2 तथा RESP3 बोलता है, जो Redis का प्रोटोकॉल है। अक्टूबर 2026 में 160 vCPU पर हमारे सिंगल-इंस्टेंस बेंचमार्क में, मापी गई 12 में से 11 कमांड पर इसका थ्रूपुट सबसे ज़्यादा रहा, और बारहवीं पर Dragonfly इसके बराबर रहा। सेटअप और उसकी सीमाएँ नीचे बताई गई हैं।

मैंने HotKV क्यों बनाया

मैं जो कुछ भी बनाता हूँ, उसमें गति की परवाह करता हूँ। वेबसाइट, टूल या सर्वर को तुरंत जवाब देना चाहिए, और जब वह नहीं देता, तो मैं जानना चाहता हूँ कि क्यों। जब से मैं सॉफ़्टवेयर लिख रहा हूँ, यही आदत मेरे काम को आकार देती रही है।

C और C++ कई सालों से मेरी मुख्य भाषाएँ रही हैं। लगभग दस साल मैंने गेम के anti-cheat सॉफ़्टवेयर पर काम किया, जो हज़ारों खिलाड़ियों के PC पर चलता था। उसे cheat खोजने के लिए मेमोरी स्कैन करनी होती थी और साथ ही CPU और मेमोरी कम से कम इस्तेमाल करनी होती थी, क्योंकि उसका खर्च किया हर साइकल गेम से छिन जाता था। उस काम ने मुझे हर चीज़ को मापना, हार्डवेयर के हिसाब से डिज़ाइन करना और कम संसाधन उपयोग को अपने आप में एक फ़ीचर मानना सिखाया।

इसके साथ-साथ, मैंने कई ऐसे प्रोजेक्ट में Redis और Valkey इस्तेमाल किए जिन्हें तेज़ cache चाहिए था। जैसे session store, फ़ायरवॉल द्वारा ब्लॉक किए गए IP पतों की सूचियाँ, और SQL Server के कई सौ मिलियन रिकॉर्ड के सामने लगा एक cache। ये बेहतरीन टूल हैं। फिर भी इन्होंने मुझे यह जानने के लिए उत्सुक किया कि अगर कोई key-value स्टोर शुरू से ही आज चलने वाले मल्टी-कोर सर्वरों के लिए डिज़ाइन किया जाए, तो वह क्या कर सकता है।

HotKV वही जवाब है जिस तक मैं पहुँचा। मैंने इसे आधुनिक C++ में शुरू से लिखा, ताकि हार्डवेयर से अधिक से अधिक गति मिले और लागत कम से कम रहे। नीचे का बेंचमार्क दिखाता है कि यह आज कहाँ खड़ा है, और मुझे उम्मीद है कि इसमें और सुधार की गुंजाइश है।

AI की लागत

एक दूसरा कारण भी था। AI एप्लिकेशन चलाना महँगा होता जा रहा था, मेरे लिए भी और, ऑनलाइन डेवलपर जो साझा कर रहे थे उसे देखकर, कई और लोगों के लिए भी। इस लागत का एक बड़ा हिस्सा अक्सर मॉडल को ऐसे सवाल भेजने से आता है जिनका जवाब वह पहले दे चुका है। एक तेज़ स्टोर जो दोहराए गए या मिलते-जुलते सवाल को पहचानकर उसका जवाब cache से दे दे, इस बिल को घटाने के सबसे सीधे तरीकों में से एक है। इसीलिए AI वर्कलोड के लिए caching HotKV का एक मुख्य हिस्सा है।

HotKV किसके लिए है

HotKV Ltd इसलिए है कि इस तरह के सॉफ़्टवेयर को अधिक performant और अधिक किफ़ायती बनाया जा सके। आधुनिक सर्वरों में बहुत सारे कोर होते हैं और डेटा स्टोर को उन्हें इस्तेमाल करना चाहिए, ताकि कम से कम लागत में अधिक से अधिक गति मिले।

दूसरा विचार यह है कि स्टैक का ज़्यादा हिस्सा एक ही जगह रखा जाए। LLM पर बनाने वाली टीमें अक्सर एक cache, एक vector डेटाबेस और agent memory रखने की कोई जगह चलाने लगती हैं, और इनके बीच ढेर सारा glue code होता है। मैं चाहता हूँ कि caching और उसके आसपास का AI काम एक ही इंजन में, आपके डेटा के बगल में रहे। यानी मॉडल कॉल की exact और semantic caching, vector search, agent memory और token budget। कम सिस्टम चलाने का मतलब कम हिस्से और कम बिल होना चाहिए। AI पेज बताता है कि आज क्या उपलब्ध है, और token-savings बेंचमार्क दिखाता है कि हमारे टेस्ट में मॉडल कॉल की caching से कितनी बचत हुई।

HotKV Redis प्रोटोकॉल और जाने-पहचाने क्लाइंट लाइब्रेरी बनाए रखता है।

समस्या

कई कोर वाली मशीन पर कमांड चलाने वाला एक ही थ्रेड bottleneck बन सकता है। जिस डेटा स्टोर का ढाँचा एक execution थ्रेड के इर्द-गिर्द बना हो, वह आमतौर पर मशीन के बाकी हिस्से तक कई इंस्टेंस या एक cluster चलाकर पहुँचता है, और इससे deployment के विकल्प और ऑपरेशनल काम जुड़ जाते हैं। मैं चाहता था कि HotKV दूसरे छोर से शुरू करे, यानी एक ही इंस्टेंस के भीतर कमांड समानांतर चलें, ताकि एक अकेला प्रोसेस पूरी मशीन इस्तेमाल कर सके।

HotKV अलग क्या करता है

HotKV™ C++20 में लिखा गया है और एक साथ कई कोर पर कमांड चलाने के लिए डिज़ाइन किया गया है, ताकि एक इंस्टेंस पूरी मशीन का उपयोग कर सके। Dragonfly, जिसे हम नीचे बेंचमार्क करते हैं, भी मल्टीथ्रेडेड तरीका अपनाता है।

• कई कोर, एक इंस्टेंस। कमांड मशीन के कोर पर समानांतर चलती हैं, इसलिए एक इंस्टेंस कई छोटे सर्वरों की जगह एक बड़ा सर्वर इस्तेमाल कर सकता है।
• जाने-पहचाने क्लाइंट और प्रोटोकॉल। HotKV RESP2 और RESP3 सपोर्ट करता है, इसलिए जाने-पहचाने क्लाइंट लाइब्रेरी इससे जुड़ सकती हैं। Transactions (MULTI/EXEC) और Lua scripting सपोर्टेड हैं। सपोर्टेड कमांड और अंतर देखने के लिए कमांड डॉक्यूमेंटेशन देखें।

यह कैसे बना और कैसे टेस्ट हुआ

HotKV मैं खुद बनाता हूँ और जहाँ मदद मिले वहाँ AI सहायता इस्तेमाल करता हूँ। कोई लाइन कैसे लिखी गई, इससे ज़्यादा मायने यह रखता है कि वह टिकती है या नहीं। इसलिए इंजन को कड़ाई से टेस्ट किया जाता है। इसमें 2,000 से ज़्यादा automated टेस्ट हैं और यह AddressSanitizer, ThreadSanitizer और UndefinedBehaviorSanitizer के साथ बनता है। प्रोटोकॉल पार्सर, कमांड dispatch, RDB और AOF लोडिंग, replication स्ट्रीम और cluster bus के लिए fuzz टारगेट भी हैं।

बेंचमार्क का सेटअप, उसकी सीमाएँ और पूरे नतीजे Performance पेज पर हैं, ताकि आप आँकड़ों को खुद परख सकें।

बेंचमार्क की झलक

अक्टूबर 2026 में अपडेट किया गया। इस पोस्ट में पहले प्रकाशित आँकड़े ऐसे बेंचमार्क रन से आए थे जो हमें बाद में त्रुटिपूर्ण मिले (दूसरी बातों के अलावा, हर लोड जनरेटर एक ही random seed इस्तेमाल करता था), इसलिए हमने उन्हें अपने दोबारा बनाए गए बेंचमार्क के नतीजों से बदल दिया।

अक्टूबर 2026: HotKV, Redis, Valkey और Dragonfly

यह बेंचमार्क HotKV Ltd ने चलाया। हमने source से बनाए गए HotKV को Redis 8.10.2, Valkey 9.1.2 और Dragonfly 2.0.2 के सामने मापा। हर सर्वर अकेले चला, Azure D160alds_v7 (AMD EPYC 9V45) के सभी 160 vCPU पर एक इंस्टेंस की तरह, persistence बंद रखकर। तीन अलग 64-vCPU मशीनों ने memtier_benchmark से लोड दिया। वैल्यू 256 बाइट की थीं, पाइपलाइन की गहराई 30 थी और 5,000,000 keys पहले से भरी थीं। हर आँकड़ा 10 सेकंड के तीन रन का median है।

12 में से 11 कमांड पर HotKV का थ्रूपुट सबसे ज़्यादा रहा। Redis या Valkey के मुकाबले यह कमांड और सर्वर के हिसाब से उनके थ्रूपुट का 8.6 से लेकर कम से कम 69.7 गुना रहा। Dragonfly के मुकाबले उन 11 कमांड पर यह 1.97 से 4.41 गुना रहा, और इनमें से कई lower bound हैं। PING पर Dragonfly 0.6 प्रतिशत आगे मापा गया। हम इसे बराबरी मानते हैं, क्योंकि लोड जनरेटर अपनी सीमा के करीब थे। किसी डेटा कमांड पर सबसे ऊँचा आँकड़ा 90.8 million INCR ऑपरेशन प्रति सेकंड का था। INCR और PING बहुत कम डेटा हिलाते हैं और लोड जनरेटरों से सीमित होते हैं, इसलिए इनके लिए HotKV का अपना आँकड़ा इससे ज़्यादा हो सकता है।

तालिका को कैसे पढ़ें

MGET हर कमांड में आठ keys पढ़ता है और MSET चार key-value जोड़े लिखता है, और थ्रूपुट कमांड गिनता है। रिपोर्ट HotKV के सात आँकड़ों (GET और छह write कमांड) को चिह्नित करती है क्योंकि वे उसकी 85% नेटवर्क-उपयोग सीमा तक पहुँच गए थे, और PING को इसलिए कि लोड जनरेटर 85% CPU से ऊपर थे। इन पर आधारित अनुपात lower bound हैं और ≥ से चिह्नित हैं। GET और PING असली सीमाएँ हैं। छह write कमांड के लिए रिपोर्ट का नेटवर्क-उपयोग आँकड़ा इनबाउंड और आउटबाउंड ट्रैफ़िक को जोड़ता है और उसकी तुलना आउटबाउंड सीमा से करता है, इसलिए वह सीमा से उनकी निकटता को बढ़ाकर दिखाता है। सबसे भारी, SETNX, ने मापी गई इनबाउंड सीमा का अधिकतम लगभग 80% इस्तेमाल किया। हम उन पर ≥ को एक रूढ़िवादी परिपाटी के तौर पर रखते हैं। पूरी तालिकाएँ, flag और मेथड नोट Performance पेज पर हैं।

बेंचमार्क का दायरा

• बिल्ड और ट्यूनिंग। HotKV को टेस्ट CPU के लिए -march=native के साथ कंपाइल किया गया था, जबकि बाकी सर्वर अपने stock release बिल्ड थे।
• थ्रेड सेटिंग। हर सर्वर को मशीन के सभी कोर दिए गए। HotKV --threads 160, Dragonfly के 160 proactor थ्रेड, Valkey io-threads 160 और Redis io-threads 128, जो उसका अधिकतम है। Redis और Valkey कमांड एक थ्रेड पर चलाते हैं और कम I/O थ्रेड के साथ ज़्यादा थ्रूपुट पा सकते हैं, इसलिए उनके आँकड़े उनके सर्वश्रेष्ठ से नीचे हो सकते हैं। हमने उनके cluster या कई इंस्टेंस नहीं चलाए।
• दायरा। बारह कमांड, एक वैल्यू साइज़, एक पाइपलाइन गहराई, न TLS और न persistence। LPOP और RPOP नहीं मापे गए, क्योंकि इन दरों पर विनाशकारी पढ़ाई मेमोरी में समाने वाली किसी भी सूची को 10 सेकंड के भीतर खाली कर देती है। रिपोर्ट latency और मेमोरी उपयोग दर्ज करती है, लेकिन हम उनकी तुलना यहाँ नहीं करते। हर 10 सेकंड के रन में सर्वरों ने बहुत अलग मात्रा में काम किया, इसलिए मेमोरी के आँकड़े बराबरी के नहीं हैं। मिश्रित वर्कलोड नहीं मापे गए।
• विचलन। Redis अपने तीन रन के बीच कई कमांड पर काफ़ी बदला, HSET पर अपने सबसे तेज़ और सबसे धीमे रन के बीच 7.2 गुना तक, और median इसे छिपा लेता है। हर प्रतिद्वंद्वी के median की जगह उसके सबसे तेज़ रन से तुलना करने पर भी HotKV सभी 11 कमांड पर आगे रहा।

Redis, Valkey और Dragonfly अपने-अपने मालिकों के ट्रेडमार्क हैं। इनके नाम केवल उस सॉफ़्टवेयर की पहचान के लिए लिए गए हैं जिसे हमने मापा, और इससे कोई प्रायोजन, समर्थन या संबद्धता नहीं जताई जाती।

आज क्या उपलब्ध है

मुख्य कमांड परिवारों में strings, lists, sets, hashes, sorted sets, streams, geospatial इंडेक्स, bitmaps, HyperLogLog, pub/sub और Lua scripting शामिल हैं। AI मॉड्यूल और enterprise फ़ीचर लाइसेंस वाले प्लान पर चलते हैं। Pricing बताता है कि हर प्लान में क्या शामिल है। मौजूदा कमांड कवरेज के लिए डॉक्यूमेंटेशन देखें। Redis कमांड सेट के अलावा:

• Key tagging: keys पर मनमाने tag लगाएँ और tag से क्वेरी करें (TAG.SET, TAG.MEMBERS और पाँच और कमांड)।
• Nanosecond TTL: NEXPIRE, NTTL और NEXPIREAT expiry को nanosecond में सेट और पढ़ते हैं, इसलिए डेडलाइन एक millisecond से भी बारीक हो सकती है। Expired keys को एक बैकग्राउंड स्वीप और एक्सेस होने पर साफ़ किया जाता है।
• वैकल्पिक वैल्यू compression: एक साइज़ सीमा (डिफ़ॉल्ट रूप से 512 बाइट) से बड़ी वैल्यू के लिए, जब तक आप चालू न करें यह बंद रहता है।
• बिना fork के snapshot: BGSAVE fork किए गए प्रोसेस की जगह बैकग्राउंड थ्रेड पर लिखता है। Snapshot किसी एक क्षण की कॉपी नहीं होता। हर key वैसी ही सेव होती है जैसी वह snapshot के उस तक पहुँचते समय थी। Append-only फ़ाइल को दोबारा लिखना fork करता है।
• Prometheus metrics: एक बिल्ट-इन HTTP endpoint, जो डिफ़ॉल्ट रूप से बंद है और metrics-port से चालू होता है, इसलिए किसी बाहरी exporter की ज़रूरत नहीं।

HotKV में HNSW इंडेक्स के साथ बिल्ट-इन vector search भी है (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH)। हमने इसे Redis 8 के मुकाबले Vector search: HotKV बनाम Redis 8 vector sets, 1 से 100 क्लाइंट तक में मापा।

HotKV Cloud से शुरू करें, या अपने सर्वरों पर HotKV चलाने के बारे में sales से बात करें।