Redis और महत्वाकांक्षा की कीमत

 (charlesleifer.com)
4 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Redis 2026 में array type PR तक की समीक्षा कर रहा है, और एक साधारण data structure server से कई क्षेत्रों को समेटने वाले प्रोडक्ट में बदल चुका है
  • शुरुआती Redis, Remote Dictionary Server के नाम के अनुरूप, तेज in-memory dictionary, सीमित कमांड्स और सरल protocol की वजह से web stack में तेजी से जगह बना सका
  • पिछले 10 वर्षों में Redis, Streams, JSON, search, graph, time-series, Redis-Raft, vector sets आदि तक फैलते हुए database-केंद्रित दिशा में मजबूत हुआ
  • फीचर्स का यह विस्तार Redis की सबसे बड़ी ताकत रही सादगी और एकरूपता को कमजोर करता है, और उन क्षेत्रों में आधे-अधूरे integration बढ़ाता है जहां specialized tools की जरूरत होती है
  • Valkey, चमकदार फीचर्स की दौड़ से अधिक multi-threaded performance, memory efficiency और cluster reliability पर ध्यान देता है, और 2011-शैली के Redis user base को लक्ष्य बनाता है

Redis की खोई हुई पहचान

  • Redis 2026 में array type जोड़ने के बड़े PR की समीक्षा तक पहुंच चुका है, और यह इस बात का प्रतीक है कि वह एक साधारण data structure server से कई क्षेत्रों को समेटने वाला प्रोडक्ट बन चुका है
  • antirez का array type PR इस समस्या से शुरू होता है कि Hash, List और Stream क्रमशः arbitrary lookup, append/trim और append-only events में तो मजबूत हैं, लेकिन array की तरह middle access और range visibility साथ में नहीं दे पाते
  • Redis में पहले से ही JSON arrays, time-series और sorted-set जैसे array-जैसे उपयोग मौजूद हैं, लेकिन फिर भी नया type जोड़ने की दिशा ही उसके feature expansion की प्रकृति को साफ दिखाती है
  • Redis की शुरुआती सफलता के कारण रहे सादगी, स्पष्ट protocol, सीमित और orthogonal commands, और conceptual consistency का कमजोर होना ही मुख्य समस्या है

पिछले 10 वर्षों में बदलाव

  • लाइसेंस और कंपनी की दिशा

    • Redis Inc ने 2024 में BSD license बंद कर दिया, और बाद में AGPLv3 को एकमात्र OSI विकल्प के रूप में शामिल करने वाली triple-license व्यवस्था तक पीछे हट गया
    • AGPLv3 की वजह से Redis Inc खुद को open source कह सकता है, लेकिन यह BSD से बहुत अलग प्रकृति का license है
    • Redis के पीछे VC-समर्थित कंपनी मूल रूप से Garantia Data नाम की NoSQL cloud hosting service थी, जिसने Redis hosting की ओर जाने के बाद अपना नाम Redis-आधारित ब्रांडिंग में बदला और antirez को साथ जोड़कर वैधता हासिल की
    • कुछ साल बाद trademark transfer की प्रक्रिया ने आगे के license बदलाव की नींव रखी, और इस बारे में पुराने लेख व टिप्पणियां अब काफी अनुमानित ढंग से पुरानी लगती हैं

  • फीचर विस्तार और product positioning

    • Redis कुछ उपयोगी data types से शुरू हुआ था, लेकिन समय के साथ उसने exotic data structures, Streams जैसे जटिल stateful systems, और version के अनुसार कभी-कभी semi-proprietary nature वाले modules तक अपने भीतर शामिल कर लिए
    • 2026 में Redis की landing page positioning बदलकर “The Real-Time Context Engine for AI Apps” हो चुकी है
    • landing page पर “Try Redis for Free” और “Get a Demo” दोनों बटन दिखाई देते हैं, जिसे screenshot में भी देखा जा सकता है

  • web-scale database की ओर झुकाव

    • Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® जैसी सुविधाएं दिखाती हैं कि Redis लंबे समय से “web-scale database” बनने की दिशा में बढ़ता रहा है

  • protocol में बदलाव और client-side caching

    • RESP3, RESP2 की बुनियादी request/response model की कई धारणाओं को तोड़ता है, और Brooks द्वारा बताई गई second-system failure जैसी प्रवृत्ति के करीब माना जाता है
    • Redis मूल रूप से cache के रूप में व्यापक रूप से इस्तेमाल हुआ, लेकिन अब client-side caching को support करने के लिए उसे नया protocol तक चाहिए

शुरुआती Redis इतना फिट क्यों बैठा

  • समय का संदर्भ

    • 2011 के आसपास web developers के बीच NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST और JSON जैसी धाराएं बहुत मजबूत थीं
    • Redis इस माहौल के लिए बिल्कुल उपयुक्त था, और लगभग रातोंरात कई stacks का हिस्सा बन गया
    • 2011 के अंत में Redis का परिचय खुद को advanced key-value store और data structure server कहता था; उसमें “database” शब्द नहीं था

  • Memcached से बेहतर remote dictionary

    • memcached कई web servers में चुपचाप चलने वाला बुनियादी infrastructure था, और caching के अलावा lock, counter, rate limit जैसी अस्थायी जरूरतों के लिए भी अक्सर इस्तेमाल होता था
    • उस समय Redis को लगभग “memcached but way better” की तरह देखा गया, और उसका नाम Remote Dictionary Server भी तेज in-memory dictionary होने की प्रकृति को रेखांकित करता था
    • Redis केवल byte blobs तक सीमित नहीं था; वह linked-list, hash-table, set और sorted-set जैसे चुने हुए data structures देकर ad-hoc और practical use cases को बहुत विस्तृत कर देता था

  • सरल लेकिन पर्याप्त expressive protocol

    • Redis wire protocol इतना सरल था कि उसे एक घंटे के भीतर समझा और implement किया जा सकता था, फिर भी वह कई data types को व्यक्त करने के लिए पर्याप्त शक्तिशाली था
    • client libraries का implementation सरल और साफ था, और protocol खुद भी स्वाभाविक महसूस होता था
    • Redis protocol और एक साधारण server को खुद बनाने वाला write your own Redis tutorial लगभग 10 साल पहले लिखा गया एक लोकप्रिय लेख बना हुआ है

  • single-threaded, event-driven, in-memory

    • Redis की single-threaded design सभी operations की atomicity सुनिश्चित करती थी, जिससे complexity काफी घटती थी और reasoning आसान हो जाती थी
    • single-threaded model को सफल बनाने के लिए server का non-blocking I/O पर बना होना और data operations का बेहद तेज होना जरूरी था
    • इस संयोजन ने एक ही thread से कई clients संभालने वाला तेज key/value store संभव किया

  • web applications के लिए उपयुक्त data structures

    • strings और expiration time cache के लिए, lists queues के लिए, और hashes structured data के लिए उपयुक्त थे
    • locks, counters, rate limiting, liveness, monitoring, leaderboards जैसी जरूरतें भी built-in data types से आसानी से बनाई जा सकती थीं

database बनने की महत्वाकांक्षा

  • Redis की adoption तेजी से बढ़ी और उसे बड़ी सफलता मिली, लेकिन किसी बिंदु पर प्रोजेक्ट की महत्वाकांक्षा database बनने की दिशा में मुड़ गई
  • कुछ फीचर्स वास्तव में उपयोगी भी थे; उदाहरण के लिए Redis 5.0 में जोड़ा गया BZPOPMIN, sorted-set को priority queue की तरह इस्तेमाल करते समय blocking pop संभव बनाकर उसकी practical utility बढ़ाता था
  • दूसरी ओर ACL जैसे फीचर्स Redis के स्वभाव से मेल नहीं खाते लगे, और कुल मिलाकर Redis को सबके लिए सब कुछ बनाने की इच्छा ज्यादा स्पष्ट दिखने लगी
  • Redis में फीचर्स जोड़ने का यह पैटर्न पिछले 10 वर्षों में developers द्वारा Hacker News पर चर्चा किए गए “नए ट्रेंड्स” का पीछा करता दिखता है
    • MongoDB JSON store करता है, इसलिए Redis को भी document database बनना चाहिए
    • ElasticSearch full-text search देता है, इसलिए Redis को भी search engine बनना चाहिए
    • graph databases पर ध्यान बढ़ा तो Redis भी graph database बनना चाहता था, लेकिन आगे चलकर RedisGraph EOL तक बात पहुंची
    • Kafka चर्चित हुआ तो Redis भी event streaming platform बनना चाहता था
    • ZooKeeper और strong-consistency databases महत्वपूर्ण बने तो Redis-Raft आया, और Aphyr का Jepsen analysis लगभग अनिवार्य पठन माना जाता है
    • InfluxDB पर ध्यान गया तो Redis भी time series database बनना चाहता था
    • AI की लहर से पीछे न छूटने के लिए vector sets जैसे AI-संबंधित फीचर्स भी जरूरी हो गए

फीचर विस्तार की कीमत

  • पहली समस्या यह है कि Redis खुद उन कारणों को कमजोर कर देता है जिन्होंने उसे लगभग हर stack का जरूरी टूल बनाया था
    • Redis सरल था, उसके commands orthogonal और सीमित थे, protocol साफ था, और वह conceptually consistent tool था
  • दूसरी समस्या यह है कि जो लोग full-text search, event stream processing, strong-consistency key/value, time-series और vector storage को गंभीरता से integrate करना चाहते हैं, वे Redis की सीमाएं विरासत में लेने वाले आधे-पके modules नहीं बल्कि specialized tools चाहते हैं
  • Redis की high availability जटिल है, persistence में सूक्ष्म trade-offs हैं, और protocol overhead तथा client fragmentation भी वास्तविक बाधाएं हैं
  • यह दृष्टिकोण है कि Redis, Postgres का विकल्प बनने वाला टूल नहीं है, और ElasticSearch व RabbitMQ जैसे systems को अपने-अपने बुनियादी स्तंभ बने रहना चाहिए
  • Redis-Raft के शुरुआती implementation पर Aphyr के analysis में 21 समस्याएं दर्ज थीं
    • स्वस्थ cluster में लंबे समय तक unavailability
    • 8 crashes
    • 3 stale reads
    • 1 aborted read
    • 5 bugs जो committed updates के loss तक ले जा सकते थे
    • 1 infinite loop
    • 2 समस्याएं जिनसे clients को logically corrupted responses भेजे जा सकते थे
    • test किया गया पहला version 1b3fbf6 व्यावहारिक रूप से उपयोग के लायक नहीं माना गया
  • cache और data structure server के रूप में Redis और “Redis the etcd” या अन्य specialized database बनने की कोशिश करने वाला Redis, मूल रूप से दो अलग प्रस्ताव हैं; यही अंतर केंद्रीय समस्या है

Disque ने यही पैटर्न दिखाया

  • antirez ने 2015 में Disque की घोषणा की, और उस समय स्वीकार किया कि यह किसी वास्तविक use case से नहीं बल्कि Redis को message queue की तरह इस्तेमाल करने वालों और दूसरे message queues को देखकर “astronaut mode” में design किया गया था
  • वास्तविक use case के बिना निजी चुनौती या सीखने के प्रोजेक्ट के रूप में बने systems भी उत्कृष्ट हो सकते हैं, लेकिन users बढ़ने के बाद सामने आने वाली long-tail कठिन समस्याओं को लगातार सुलझा पाना एक अलग बात है
  • high-availability message delivery मूल रूप से कठिन समस्या है, और CAP theorem के किसी भी पक्ष को optimize करने पर trade-offs और मुश्किल समस्याओं से बचा नहीं जा सकता
  • 2015 तक कई mature message brokers पहले से मौजूद थे, और लोग Redis को message broker की तरह इसलिए इस्तेमाल करते थे क्योंकि वे Redis पहले से चला रहे थे और वह पर्याप्त रूप से सरल था
  • जरूरत न तो किसी नए message broker की थी, न Redis को और अधिक जटिल message broker बनाने की
  • Disque घोषणा के तुरंत बाद लगभग abandonware बन गया, और GitHub पर 8K stars पाने के बावजूद उपेक्षित रहा
  • बाद में उसे Redis module के रूप में फिर से लिखा गया, लेकिन वह प्रोजेक्ट भी पिछले 7–8 वर्षों से उपेक्षित पड़ा है

Valkey एक अलग दिशा दिखाता है

  • Redis की दिशा को चलाने वाली ताकतें थीं: जटिल समस्याएं हल करने की developer ambition, सबके लिए सब कुछ बनने की ambition, और Redis के मालिकों की AWS तथा GCP से पीछे छूटने से पहले अधिकतम राजस्व निकालने की ambition
  • महत्वाकांक्षा अपने-आप में समस्या नहीं है, लेकिन जब वही सफलता के मूल कारणों को मिटा दे, तब वह समस्या बन जाती है
  • Valkey का अस्तित्व और adoption, इस गतिशीलता पर व्यापक बाजार का अंतिम फैसला बताकर पेश किया जाता है
  • Valkey, feature chase या comparison chart की bullet points के बजाय multi-threaded performance, memory efficiency, cluster reliability और throughput improvements जैसे कम चमकदार कामों में निवेश करता है
  • Valkey के performance benchmarks प्रभावशाली हैं, और वह सीधे उन 80% Redis users को लक्ष्य बनाता है जिनके लिए 2011 वाला Redis ही पर्याप्त था
  • Valkey की दुनिया में निष्कर्ष यही है कि नए array type की जरूरत नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की रायें

  • जिसने open source को काफ़ी बड़े पैमाने तक बढ़ाया हो, कंपनी बनाई हो, सैकड़ों मिलियन डॉलर का revenue, IPO, और कई बिलियन डॉलर की sale तक देखी हो, और उस प्रक्रिया में OSS से बाहर जाने वाला license change भी किया हो, उसके नज़रिए से Redis की “AI apps के लिए real-time context engine” वाली positioning दिशा के हिसाब से सही लगती है
    सॉफ़्टवेयर खरीद में actual users और technical decision-makers (TDM) होते हैं, और Redis का landing page actual developers से ज़्यादा budget authority वाले TDM को target करने वाली साइट जैसा दिखता है। बहुत से TDM “IBM चुनने पर किसी की नौकरी नहीं गई” जैसी सोच के साथ ऐसे फ़ैसले पसंद करते हैं जिन पर उन्हें निकाला न जाए, और अगर Gartner या McKinsey AI strategy और context management पर ज़ोर दें, तो “AI apps के लिए Context Engine” एक defend किया जा सकने वाला खरीद कारण बन जाता है
    HashiCorp में भी terraform.io को practitioners के लिए और hashicorp.com को TDM के लिए अलग करने की कोशिश की गई थी, और कुछ हद तक यह काम भी किया, लेकिन उसकी सीमाएँ भी थीं। developer-led OSS कंपनियों के लिए यह मुश्किल समस्या है
    “Use Redis for free” और “Get a demo” बटन भी TDM के नज़रिए से अजीब नहीं हैं। TDM तकनीकी फ़ैसलों की ज़िम्मेदारी लेना पसंद नहीं करते और बल्कि पैसे देकर software खरीदना चाहते हैं, इसलिए free विकल्प को trial जैसा नीचे रखा जाता है और किसी इंसान से जुड़ने वाला call to action सामने रखा जाता है
    Redis Inc. की management ने शायद यह निष्कर्ष निकाला है कि developers/operators की तुलना में TDM को appeal करना ज़्यादा महत्वपूर्ण है, और बिना internal data के यह कहना मुश्किल है कि यह सही है या ग़लत, लेकिन यह बिना इरादे की strategy नहीं रही होगी
    features जोड़ते रहना भी इसलिए होता है क्योंकि existing tool को expand करने की cost, नया tool adopt करने की cost से कहीं कम होती है। commercial motive न भी हो, तब भी programming languages अक्सर अपनी core identity बचाए रखने के बजाय हर feature का lowest common denominator बन जाती हैं, और commercial कंपनियों में “land and expand” बहुत मज़बूती से काम करता है। किसी flagship feature से पहला contract जीतने के बाद, average level के add-on features जोड़कर बेचना भी संभव होता है, क्योंकि procurement department के लिए नया contract करने से existing contract को expand करना आसान होता है
    यह दावा कि “serious customers full-text search/event stream/strongly consistent KV/time series/vector store के लिए असली specialist products चाहेंगे” भी काफ़ी विवादित है। public software companies के data को ही देखें तो customers गैर-तकनीकी कारणों से अक्सर बदतर विकल्प चुनते हैं
    यह कहना भी मुश्किल है कि Valkey ही बाज़ार का अंतिम फ़ैसला है। Valkey औसत fork से बहुत बेहतर कर रहा है (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), लेकिन Redis कंपनी भी बाहर से देखने पर ठीक-ठाक टिकती हुई लगती है। ElasticSearch या MongoDB जैसी कंपनियों को देखें, जिन्होंने license बदला और forks भी बने, फिर भी public market valuation पर बड़ा असर नहीं पड़ा—तो अलग निष्कर्ष भी निकाले जा सकते हैं। developer bubble में यह अलग दिख सकता है, लेकिन अगर revenue ही अंतिम lagging indicator है, तो यह भी पूछा जा सकता है: “क्या वह सच में इतना महत्वपूर्ण था?”
    यह commercial interests का बचाव करने की कोशिश नहीं है, बल्कि उस तरफ़ से दिखने वाला perspective साझा करना है। जैसे एक ही कृषि उपज को लेकर ख़रीदारी करने वाले और किसान के सवाल और लक्ष्य पूरी तरह अलग होते हैं

    • commercial नज़रिए का “क्यों” अच्छी तरह समझाया गया, और यह संदर्भ भी जुड़ता है कि Redis किसी शुद्ध software vacuum में नहीं है, OSS nerds उसका target नहीं हैं, और decision-makers के मानदंड system engineers से अलग होते हैं
      लेकिन यह तर्क ऐसा लगता है मानो सबका लक्ष्य पैसा ही है। Redis से बहुत बड़ा पैसा कमाने की महत्वाकांक्षा एक खास तरह की महत्वाकांक्षा है, और antirez के लेख में दिखे रवैये से वे ऐसे व्यक्ति नहीं लगते जिन्हें पैसे की बहुत बड़ी चिंता रही हो
      इसके counterexample के रूप में SQLite है। वह सैकड़ों मिलियन की revenue या कई बिलियन डॉलर की sale की बात नहीं करता, बल्कि चुपचाप एक अच्छी तरह परिभाषित चीज़ उपलब्ध कराने पर ध्यान देता है। SQLite सबसे लोकप्रिय embedded database क्यों बना, यह कारण उसने नहीं खोया, और बड़े databases की दुनिया में Postgres के बारे में भी यही बात कही जा सकती है। पैसे और commercial interests की दुनिया जितनी ही, इस दूसरी दुनिया से भी counterexamples लाए जा सकते हैं
      Redis के मामले में, “हम पहले से AWS/GCP इस्तेमाल करते हैं, तो वहीं का Redis-जैसा कुछ इस्तेमाल कर लें” क्षैतिज विस्तार का स्वाभाविक परिणाम लगता है। इससे भी ज़्यादा IBM-जैला रास्ता यह है कि cloud provider चुना जाए और उसका Redis इस्तेमाल किया जाए, और आजकल वह Valkey बन जाता है
      लोग बदतर विकल्प चुनते हैं, यह विवाद नहीं बल्कि तथ्य है, और Redis का उसी mode में expand होना ही महत्वाकांक्षा और भटकाव का वह उदाहरण है जिस पर ज़ोर देना था
    • मैंने Redis Labs में काम किया है, इसलिए मैं लगभग शब्दशः शैतान के developer advocate की स्थिति में था। नौकरी छोड़ते समय मैंने vested options exercise नहीं किए, और Silicon Valley से काफ़ी दूर रहता हूँ, इसलिए बहुत सारे पुल जल जाने की चिंता के बिना यह बात कह सकता हूँ
      पहले redis.com TDM साइट थी और redis.io developers के लिए था, लेकिन Redis Labs ने antirez के पास मौजूद redis.io ले लेने के बाद उसे इतना बिगाड़ दिया कि download link तक ढूँढना मुश्किल हो गया, और अब दोनों URL TDM साइटों की तरफ़ ले जाते हैं। आज भी Redis download link आसानी से नहीं मिलता, और मन करता है कि लोगों से कहूँ कि ख़ुद जाकर ढूँढें
      मूल समस्या यह है कि Redis Labs ने हमेशा marketing leadership बहुत ख़राब चुनी। CMO और VP आते, कम समय में जितना हो सके goodwill जला देते, और 6 महीने बाद “अगले adventure” पर निकल जाते। redis.io का traffic redis.com से बहुत ज़्यादा है—यह देखकर, download link न ढूँढ पाने वाले लोग “try free” पर क्लिक करें इस उम्मीद में redis.io को बिगाड़ देना, उस short-term click greed का典型 उदाहरण लगता है
      add-on features बेचना competitors से checkbox-level differentiation में भी मदद करता है। खासकर तब जब price पर compete करना मुश्किल हो, और AWS ElastiCache के साथ भारी cloud discount बाँधकर बेच सकता था, जबकि सबसे बुरा competitor वह free open source Redis था
      Valkey में सामान्य fork की तुलना में बहुत ज़्यादा पैसा लगाया जा रहा है। उदाहरण के लिए, Redis Labs के former head of developer relations अब AWS में Valkey पर काम कर रहे हैं
      लेकिन यह आकलन थोड़ा अफ़सोसजनक है कि Valkey सिर्फ़ “unglamorous work” कर रहा है। Redis बहुत पहले से multi-threaded रहा है; control plane अब भी single-threaded है, लेकिन I/O multi-threaded है, इसलिए Valkey का काम उतना नया नहीं है जितना लेखक सोच रहा होगा
      Valkey खुलकर AWS जैसी cloud कंपनियों की यह strategy है कि वे किसी को पैसे दिए बिना Redis बेचते रह सकें। बाकी तर्क सिर्फ़ marketing tools हैं ताकि उन्हें वही काम करते रहने के लिए मनाया जा सके, और अगर उन्हें लगे कि Redis compatibility तोड़ना commercial रूप से फ़ायदेमंद है, तो वे ऐसा करेंगे। शायद दोनों तरफ़ से कुछ हद तक ऐसा पहले ही हुआ हो—इस पर भी शर्त लगाई जा सकती है—लेकिन मैंने काफ़ी बारीकी से follow नहीं किया
      अगर आप ऐसा असली Redis fork चाहते हैं जो unglamorous work करे और simplicity बनाए रखे, तो redict है
      फिर भी मुझे लगता है कि Redis का समय ढल रहा है। मौजूदा अजीब commercial landscape में हर fork कहीं न कहीं लंगड़ा रहा है। सबसे virtuous redict में भी antirez के उस दौर जैसी वास्तविक रुचि कम दिखती है, जब वे मूल project को लगभग तानाशाह की तरह आगे धकेलते थे। मेरा मतलब यह नहीं कि software का “complete” हो जाना बुरा है, लेकिन मुझे लगता है कि Redis में अभी भी कई शानदार अनदेखे क्षेत्र हैं, और संदेह है कि commercial forks ऐसा ecosystem बना पाएँगे। हाँ, हो सकता है कि मैं Arrays और AI-संबंधित applications की value को कम आँक रहा हूँ, इसलिए मैं सुनने के लिए खुला रहना चाहता हूँ
      पीछे मुड़कर देखें तो यह लगभग चौंकाने वाला है कि Redis Labs ने यह सब इतना बुरी तरह बिगाड़ दिया, और अच्छा है कि अब काफ़ी समय बीत जाने से ग़ुस्सा भी कम हो गया है
    • लगता है कि कंपनियाँ बिना पैसे दिए जितना हो सके उतना लेना चाहती हैं। शायद इसी वजह से Redis, MongoDB, HashiCorp ने आख़िरकार license बदला

  • कंपनी में Lua scripts से एक ज़्यादा fair work queue system बना रहा हूँ, और Redis बहुत अजीब महसूस होता है। मेरे दिमाग़ में इसका मॉडल हमेशा “simple key-value store” था, लेकिन अब global lock के भीतर Lua scripts चलाने जैसी हर तरह की features सीखनी पड़ रही हैं
    लेकिन documentation उस चमकदार website पर है, और चीज़ें साफ़-साफ़ नहीं बताता। config values भी बस config sample के भीतर समझाई गई लगती हैं
    मुझे पता है Redis अच्छी तरह काम करता है और सब यही कहते हैं, लेकिन Redis के features सीखने का अनुभव काफ़ी असुविधाजनक है। जैसे किसी ने एक बहुत अच्छा program बनाया हो, और फिर उस अच्छे program के साथ आम तौर पर होनी चाहिए वैसी शानदार documentation को भूल गया हो
    यह थोड़ी अजीब शिकायत है। Redis शायद बेहद अच्छी तरह काम करता है, और मुझे Postgres docs जैसी documentation पसंद है जो “सब कुछ” समझा दे

    • सोचता हूँ कि क्या कम TDM-oriented product की documentation ज़्यादा समझने लायक होती है: https://valkey.io/topics/programmability/
      कई open source projects को भी पता है कि उनकी documentation कमज़ोर होती है, इसलिए ऐसा नहीं लगता कि इस experiment में सिर्फ़ pointy-haired bosses ही variable हैं
    • Redis में पहले हर तरह की documentation हुआ करती थी, और शुक्र है कि Wayback Machine से Redis Labs द्वारा किए गए नुकसान को कुछ हद तक undo किया जा सकता है। शायद आप यहाँ अपनी मनचाही चीज़ ढूँढ लें: https://web.archive.org/web/20190725152042/…
      redict की documentation भी अच्छी लगती है: https://redict.io/docs/scripting/