Valkey की पहली वर्षगांठ: कम्युनिटी fork ने Redis को कैसे पीछे छोड़ा

• Redis Inc ने source-closed (SSPL में बदलाव) के फैसले से कम्युनिटी के भरोसे को झटका दिया, लेकिन Valkey fork के आसपास developer community एकजुट हुई और तेज़ innovation व contribution जारी रहे
• Redis 8.0 फिर से open source में लौटा, और संस्थापक Antirez की वापसी के साथ नए features और optimizations पर काम हो रहा है, इसलिए दोनों पक्षों में तेज़ प्रगति दिख रही है
• नवीनतम benchmark नतीजों में, 8vCPU environment पर Valkey 8.1.1 का SET performance Redis 8.0 से 37% अधिक रहा, और p99 latency भी कम मापी गई (GET performance भी 16% आगे)
• IO threads/core pinning जैसी production tuning techniques के जरिए, Valkey ने multithreading environment में 3 गुना से अधिक throughput बढ़ोतरी और latency minimization हासिल की
• real-world usage के करीब benchmark और tuning know-how भी साझा किए गए हैं, साथ ही benchmark results की व्याख्या करते समय सावधानियां और actual production environment में लागू करने के तरीके भी बताए गए हैं

---

Redis source बंद होना और Valkey का आगमन

• एक साल पहले Redis Inc (पूर्व Garantia Data) ने open source license बदलाव (SSPL अपनाने) के कारण community के साथ भरोसे का रिश्ता कमजोर कर दिया
• इसके समाधान के रूप में बना open fork Valkey, distributed systems, cache, real-time data processing जैसे क्षेत्रों में व्यापक रूप से इस्तेमाल होने वाली तकनीकी संपत्ति बन गया
• Redis पक्ष ने भी बाद में Antirez (संस्थापक) की वापसी, performance/features में सुधार, और Redis 8.0 को फिर से open source बनाने जैसे कदमों से भरोसा बहाल करने की कोशिश की

Valkey 8.1 vs Redis 8.0: performance तुलना

• समान 8vCPU AWS c8g.2xl instance, 1KB item/3M keyspace/500 connections की शर्तों पर SET benchmark
  • Valkey 8.1.1: 999.8K RPS(p99 0.8ms)
  • Redis 8.0: 729.4K RPS(p99 0.99ms)
  • SET में Valkey 37% आगे, GET में 16% आगे, और SET p99 30%, GET p99 60% तेज़
• 6 IO threads लागू करने पर, Valkey 239K → 678K RPS(2.8 गुना↑), p99 1.68ms → 0.93ms(44%↓)
• Redis में भी IO threads के साथ 235K → 563K RPS, p99 1.35ms → 0.84ms(40%↓)

multithreading/core tuning का प्रभाव

• IO threads का असर 3 या उससे अधिक threads पर स्पष्ट रूप से बढ़ता है, और Valkey में 4 threads के बाद Redis से बड़ा अंतर दिखता है
• IRQ (interrupt) cores को 2 तक सीमित करने के बाद, Redis/Valkey को बाकी 6 cores पर fix (pinning) करने से अतिरिक्त performance gain मिला
  • Valkey: 832K → 999.8K RPS(core/IRQ pinning, CPU 80% उपयोग)
  • IRQ और application cores को अलग करने से cache efficiency और tail latency कम होती है
  • Docker में cpuset-cpus, --io-threads आदि के उपयोग के actual examples भी दिए गए हैं

benchmark दोहराना और practical tips

• नवीनतम AWS Graviton4(c8g.2xlarge) instance, cluster placement group का उपयोग
• core pinning/IRQ separation/connection tuning(लगभग 400~500) से अधिकतम performance हासिल
• keyspace/item size की tuning भी ज़रूरी है; छोटे values/keyspace से L3 cache hit rate बढ़ती है
• valkey-benchmark या rpc-perf (real-world usage के ज्यादा करीब Rust-आधारित tool) जैसे multithreaded benchmark tools के सक्रिय उपयोग की सिफारिश

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

performance measurement की सीमाएं और सावधानियां

• benchmark results actual production environment से अलग हो सकते हैं

  • actual workload में SET:GET mix, load fluctuation, TPS target, network latency जैसे कई संयुक्त कारक होते हैं
  • connections अचानक बढ़ने पर queue latency, throughput में कमी, और tail latency में बढ़ोतरी भी देखी गई
  • benchmark tool/options, network topology आदि के अनुसार नतीजे काफी बदल सकते हैं

प्रमुख विकास यात्रा और community प्रगति

Valkey project ने पिछले एक साल में कई पहलुओं में सक्रिय प्रगति की है

• GitHub आदि पर कई developers और कंपनियों के सहयोग से features जोड़े गए, bugs ठीक किए गए, और security improvements की गईं
• documentation और user support पर भी ध्यान देकर नए users के लिए entry barrier कम किया गया
• project संचालन में transparent decision-making और community voting जैसी प्रक्रियाओं पर ज़ोर दिया गया

industry और तकनीकी महत्व

Valkey की प्रमुख ताकतें इस प्रकार हैं

• license restrictions के बिना कोई भी इसका उपयोग कर सकता है, इसलिए यह cloud service vendors और बड़ी web service कंपनियों के लिए आकर्षक विकल्प है
• Redis के साथ उच्च compatibility होने से migration आसान है
• community-driven development होने के कारण विभिन्न जरूरतों को शामिल करना और तेज़ लगातार updates देना संभव है

निष्कर्ष और संकेत

• Valkey ने Redis fork बनने के सिर्फ एक साल में technology/performance/community तीनों मोर्चों पर Redis से आगे निकलने जैसे परिणाम दिखाए हैं
• IO threads, core/IRQ separation, connection tuning जैसी practical optimization techniques और tools इसकी कुंजी हैं
• performance अपने आप नहीं आती; system/workload/infrastructure के अनुरूप लगातार optimization ज़रूरी है
• actual service environment में सिर्फ benchmark numbers पर निर्भर न रहकर, अलग-अलग परिस्थितियों में सीधे परीक्षण करने वाला व्यावहारिक दृष्टिकोण आवश्यक है

[ethanhur]

Redis ने भले ही कई गलत फैसले लिए हों, लेकिन यह अफसोस की बात है कि मेहनत कोई और करे और पैसा कोई और ले जाए।

[kgcrom]

Facebook "Redis User Group" पर पोस्ट किया गया
Valkey 8 में कौन-कौन से सुधार किए गए हैं, इसे संक्षेप में समझाने वाली सामग्री है।
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

ऊपर की सामग्री के साथ इसे भी देखें, तो समझने में मदद मिलेगी।

[ndrgrd]

असल में Valkey ने कुछ किया हो ऐसा नहीं है... उधर वाले खुद ही अपने आप बर्बाद हो गए...

[GN⁺]

Hacker News राय

• मुझे खुशी है कि ValKey ने I/O threading में शानदार प्रगति की है, और इसने हाल के कुछ सबसे दिलचस्प बदलावों को अपनाना भी शुरू किया है। ValKey contributors को बहुत धन्यवाद। लेकिन मुझे लगता है कि यह लेख थोड़ा भ्रामक है। मूल Redis में shared nothing architecture एक बहुत महत्वपूर्ण दर्शन था, और 2020 में I/O threading को मैंने खुद पेश किया था। Shared nothing के उद्देश्य को नुकसान पहुँचाए बिना, यह देखते हुए कि event loop से लौटते समय write(2)/read(2) syscall बहुत धीमे हो सकते हैं, उस बिंदु पर zero contention स्थिति में केवल I/O को N threads में parallel किया गया और उसके तुरंत बाद फिर single thread पर लौट आने वाली संरचना लाई गई थी। ValKey टीम ने इस सिस्टम को आगे बढ़ाया है, इसके लिए आभारी हूँ। यह सिस्टम पहले से काम कर रहा था, और मुझे असहज लगता है कि मीडिया ऐसे डेटा को बढ़ा-चढ़ाकर पेश करती है जिसमें वास्तव में इतना बदलाव नहीं आया है। ये फीचर वास्तव में ज़्यादातर सामान्य Redis users की तुलना में enterprise users या cloud providers (Amazon, Google आदि) के लिए अधिक रुचिकर हैं। जब तक बहुत भारी load या बहुत सारे users को एक साथ संभालना ज़रूरी न हो, अधिकांश Redis उपयोग में CPU utilization कम रहता है, इसलिए इसे सक्षम करने की खास ज़रूरत नहीं पड़ती। हाल ही में Redis में vector set data type विकसित करते समय threading को default बनाया जा रहा है, और VADD के ज़रिए vector set writes भी threaded तरीके से किए जा सकते हैं। HNSW जैसी data structures Redis के इतिहास में पहली बार बहुत बड़े constant time लाती हैं, इसलिए design space ही बदल जाता है। पहले modules के लिए thread support भी लागू किया जा चुका है। Threads का उपयोग करना है या नहीं, यह परिस्थिति के अनुसार लिया जाने वाला निर्णय है।
  • सूक्ष्म दृष्टिकोण clicks नहीं खींच पाते, इस बात का ज़िक्र किया गया
  • मुझे लगता है कि इस तरह की आलोचनात्मक पोस्ट हर महीने HN front page पर आ जाती है, और मैं हमेशा antirez का समर्थन करना चाहता था। मैं तकनीकी बिंदु से सहमत हूँ, लेकिन मुझे लगता है कि ऐसी आलोचना अक्सर ठोस सामग्री से ज़्यादा उस classic tall poppy syndrome से जुड़ी होती है जिसमें बहुत सफल लोगों को निशाना बनाया जाता है। आप दूसरों की प्रतिक्रिया नियंत्रित नहीं कर सकते, इसलिए ऐसी आलोचनाओं को अपनी उपलब्धियों की एक परोक्ष स्वीकृति मानना शायद अधिक स्वस्थ दृष्टिकोण हो सकता है। LinkedIn पर जुड़े होने के लिए भी धन्यवाद। tall poppy syndrome देखें
• मुझे याद है कि antirez ने घोषणा की थी कि Redis फिर से open source बनेगा संबंधित पोस्ट। पहले Node.js लगभग Io.js fork प्रकरण से बिखर ही गया था, लेकिन community ने उसे वापस संभाल लिया। सोचता हूँ क्या Redis भी वैसी वापसी कर पाएगा। पहले मैं Redis का बहुत उपयोग करता था, लेकिन पिछले कुछ वर्षों में community की दिशा पर नज़र नहीं रखी
  • आखिरी बार देखने पर Redis अभी भी CLA (Contributor License Agreement) मांगता है। इसका मतलब है कि उसके पास फिर से source बंद करने का एकाधिकार अधिकार अब भी है। यदि contributors को ऐसी शर्त माननी पड़े, तो यह भरोसा करने का कोई कारण नहीं है कि वे फिर वही काम नहीं करेंगे
  • Redis AGPL के तहत और Valkey BSD license के तहत वितरित हो रहा है (BSD पुराना Redis license था)। दोनों आधिकारिक open source licenses हैं, लेकिन BSD कहीं अधिक permissive है
  • ईमानदारी से कहूँ तो 99% users को इस बात से फर्क नहीं पड़ता कि मालिक कौन है, बस एक मुफ्त key-value store ठीक से चलता रहे। business के नज़रिए से Redis एक दिलचस्प स्थिति में है: इसमें बहुत फीचर्स हैं, लेकिन वास्तविक users उनमें से 5% ही इस्तेमाल करते हैं। Sentinel/Streams जैसे जटिल फीचर्स में उनकी खास रुचि नहीं होती। जब monetization की बात आती है, तो users के पास कई विकल्प होते हैं: "बस इस्तेमाल न करना", "प्रतिद्वंद्वी के पास जाना", "खुद सिर्फ ज़रूरी फीचर्स बनाना", या "आखिरी open source version को fork करके खुद maintain करना और लागत बचाना"। PostgreSQL की तुलना में Redis का सरल संस्करण (hashmap + network interface) खुद बनाना आसान है, इसलिए कई businesses के लिए fork करना या खुद बनाना बेहतर विकल्प बन जाता है
  • मेरी राय में भी अब काफी देर हो चुकी है। Redis के अचानक policy change के बाद मेरे लिए Redis अब अविश्वसनीय हो गया है, और आगे Valkey ही default विकल्प है। एक बार धोखा खाओ तो दूसरी बार भरोसा मत करो
  • Redis ने जो किया उसके बाद उस पर भरोसा कैसे किया जाए, यह सवाल उठाया गया
• मुझे लगता है कि Valkey को default distribution package managers में होना चाहिए। उदाहरण के लिए GitHub Action runner पर इसे install करने के लिए हर बार key जोड़ना और distribution update करना झंझट लगता है
  • कौन-सी distribution में यह नहीं है, यह सवाल पूछा गया। repology डेटा के अनुसार यह पहले से nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL आदि में है। बस Debian में यह 13 या 12+backports से उपलब्ध है
  • जानकारी के लिए, Arch Linux में Valkey पहले ही Redis की जगह ले चुका है
  • यदि CI में container image लेने के तुरंत बाद पहला काम कई चीज़ें install करना है, तो अपनी image खुद बनाना बेहतर हो सकता है
• यह बदलाव हो रहे हैं और Valkey लगातार अच्छा कर रहा है, यह देखकर बहुत अच्छा लग रहा है। उम्मीद है Redis जल्द गायब हो जाए
  • open source को monopolistic कंपनियों के लिए बना बताया गया, एक व्यंग्यात्मक लहजे में। AWS जैसे hyperscalers Redis से सैकड़ों मिलियन डॉलर कमा रहे हैं, लेकिन असली developers और contributors को उसका लाभ नहीं मिलता। इसलिए database startups को शुरू से fair source (anti-hyperscaler clauses वाले licenses) के साथ शुरू करना चाहिए, ताकि code को कोई भी आज़ादी से इस्तेमाल करे, लेकिन AWS या Google अगर उसे managed service के रूप में बेचना चाहें तो उन्हें भुगतान करना पड़े। Redis और Elasticsearch जैसे प्रोजेक्ट जो पहले ही बहुत permissive licenses के साथ शुरू हुए, उनके लिए वापस मुड़ना कठिन भाग्य जैसा है
• हाल में कई dotnet projects commercial हो रहे हैं। developers के लिए ऐसा बदलाव किसी rug pull जैसा महसूस होता है। ऐसा माहौल दूसरे open source dotnet libraries के प्रसार को भी नुकसान पहुँचा सकता है
  • .NET में यह commercial रुझान कोई नई बात नहीं है; freeware/open-core और business का रिश्ता शुरू से ही गहरा रहा है
• मैंने पिछले साल से Valkey के बारे में सुना है, और यह देखकर खुशी है कि यह अभी भी अच्छा कर रहा है
• सोच रहा हूँ कि क्या Valkey अपनी client library देता है। अभी GCP environment में MemoryStore और self-managed दोनों तरह के सेटअप में Redis/Redis Cluster इस्तेमाल कर रहा हूँ। आधिकारिक C library Redis Cluster+TLS के साथ निराशाजनक है, इसलिए hiredis-cluster नाम की एक unofficial client (https://github.com/Nordix/hiredis-cluster) इस्तेमाल करनी पड़ती है। GCP का Memorystore भी बहुत संतोषजनक नहीं लगा। Scylla पर migrate करने पर विचार कर रहा हूँ
  • hiredis और hiredis-cluster को मिलाकर बना libvalkey नाम का एक आधिकारिक fork है, जिसे मौजूदा hiredis/hiredis-cluster maintainers ही संभाल रहे हैं libvalkey देखें
• अब जब Redis ने policy बदल दी है, तो क्या Valkey और Redis बात करके फिर से जुड़ सकते हैं, यह सोचता हूँ
  • यह बताया गया कि license को पहले जैसा नहीं किया गया, बल्कि AGPL पर ले जाया गया है, इसलिए यह असली U-turn नहीं है
• अपेक्षित GPL FUD (fear, uncertainty, doubt) पर एक शानदार व्याख्यात्मक लेख का लिंक साझा किया गया संबंधित लेख
  • पोस्ट में copyleft license को अधिक स्वतंत्र बताने वाला तर्क कुछ हद तक आसान तर्क लगता है। जैसे-जैसे obligations बढ़ते हैं, freedom कम होती है; इसलिए कौन-सा style ज़्यादा ‘free’ है, इस पर चर्चा और गहरी है
• मैं दर्जनों applications में Redis इस्तेमाल करता हूँ। AWS ने Valkey को discounted pricing पर दिया, इसलिए मैंने 2 महीने पहले से इसे इस्तेमाल करना शुरू किया और performance में कोई अंतर महसूस नहीं हुआ। लेकिन अचानक Valkey पूरी तरह अटक गया। AWS की नज़र में वह अभी भी running था, लेकिन connection पूरी तरह कट गया। 12 घंटे से ज़्यादा समय तक वह recover नहीं हुआ, और फिर दोबारा भी ऐसा हुआ। AWS ने 2 हफ्ते तक जाँच की लेकिन कारण नहीं ढूँढ पाया। अब Valkey को mission-critical environment में इस्तेमाल करना मेरे लिए कठिन हो गया है। बाद में उसी workload पर Redis से बदल दिया और समस्या नहीं हुई
  • शायद यह AWS की समस्या हो सकती है। हमारे साथ भी production RDS postgres cluster में ऐसा कुछ हुआ था। network response रुक गया था, AWS enterprise support लिया, लेकिन अंत में खुद backup restore करके नया cluster बनाना पड़ा, जिसमें 4 घंटे लगे। उसके बाद हमने AWS encapsulated services से बचना शुरू किया और सामान्य EC2 पर replication, snapshots, S3 replication आदि के साथ migrate किया
  • यह AWS operations की समस्या भी हो सकती है; मैंने केवल Redis को खुद चलाया है, इसलिए यह ज़रूरी नहीं कि समस्या Valkey की ही हो
  • यह सवाल पूछा गया कि आप सीधे अपना Valkey instance क्यों नहीं चलाते
  • संदर्भ के लिए इस्तेमाल किए गए instance type के बारे में पूछा गया