Redis का वापरायचं? इतिहास, वापराचे प्रकार आणि उत्तम पर्याय

“हे फक्त Redis मध्ये कॅश करा” — हे तुम्ही कोड रिव्ह्यूमध्ये, सिस्टम डिझाइन इंटरव्ह्यूमध्ये किंवा Stack Overflow च्या कमेंटमध्ये नक्कीच ऐकलं असेल. आता हे जवळपास एक प्रतिक्षिप्त क्रिया बनली आहे. पण Redis च का? चांगल्या इंडेक्ससह एखाद्या सामान्य डेटाबेसने का नाही, किंवा इतर कोणत्याही इन-मेमरी स्टोअरने? मी त्याचा इतिहास, आर्किटेक्चर आणि पर्यायांचं सध्याचं चित्र खोलवर तपासलं — आणि ही गोष्ट खरोखरच मेमपेक्षा कितीतरी जास्त रंजक आहे.

Redis खरोखर काय आहे

आधी एक गोष्ट स्पष्ट करूया. Redis फक्त एक कॅश नाही. ही तीच गैरसमज आहे जी लोकांना अडकवते. Redis म्हणजे REmote DIctionary Server [1], आणि हे एक इन-मेमरी डेटा स्ट्रक्चर स्टोअर आहे — म्हणजे ते डिस्कऐवजी RAM मध्ये डेटा ठेवतं. हाच एक निर्णय त्याच्या वेगाचं बहुतांश कारण स्पष्ट करतो.

पण त्याला “की-व्हॅल्यू स्टोअर” म्हणणं म्हणजे त्याला कमी लेखणं. Redis नेटिव्हली डेटा स्ट्रक्चर्सचा एक समृद्ध संच समजतं [1]:

• Strings — मूळ प्रकार; काउंटर आणि बायनरी ब्लॉबसाठीही वापरतात
• Lists — क्रमबद्ध, डुप्लिकेट सपोर्ट करतात; रांगा आणि अॅक्टिव्हिटी फीडसाठी उत्तम
• Sets — O(1) सदस्यत्व तपासणीसह अनन्य मूल्ये
• Sorted Sets — क्रमासाठी संख्यात्मक स्कोर असलेले अनन्य सदस्य; रिअल-टाइम लीडरबोर्डसाठी आदर्श
• Hashes — एका की मध्ये मिनी हॅशमॅप; सगळं सीरियलाइझ न करता ऑब्जेक्ट साठवा
• Streams — प्रोसेसिंगसाठी अपेंड-ओन्ली इव्हेंट लॉग
• Bitmaps / HyperLogLogs — स्पेस-एफिशिएंट काउंटिंग आणि प्रोबेबिलिस्टिक डेटा
• Geospatial indexes — कोऑर्डिनेट्स वापरून जवळची ठिकाणे शोधा

म्हणूनच Redis बहुतांश आधुनिक वापरांमध्ये Memcached वर मात करतो. Memcached अत्यंत साध्या अॅक्सेस पॅटर्नसह रॉ स्ट्रिंग कॅशिंगसाठी जलद आहे — आणि तेवढंच ते करतं. जेव्हा तुम्हाला सॉर्टेड लीडरबोर्ड, पब/सब चॅनेल किंवा रेट-लिमिटिंग काउंटरची गरज पडते, तेव्हा Memcached काही करू शकत नाही.

उगमाची गोष्ट

हा भाग खरोखरच चांगला असेल असं मला अपेक्षित नव्हतं.

Salvatore Sanfilippo — जो ऑनलाइन antirez म्हणून ओळखला जातो — एक सिसिलियन प्रोग्रामर आहे जो 2007 मध्ये LLOOGG नावाचं एक रिअल-टाइम वेब अॅनालिटिक्स टूल बनवत होता [2]. कल्पना हुशारीची होती: वेबसाइट मालकांना त्यांच्या भेट देणाऱ्यांचं वर्तन लाइव्ह दाखवायचं, कोणत्या पेजेसना ते गेले आणि कोणत्या क्रमाने. संदर्भासाठी, Google Analytics ने 2011 पर्यंत रिअल-टाइम ट्रॅकिंग दिलं नव्हतं, त्यामुळे antirez खरोखरच त्याच्या काळापुढे होता [3].

समस्या? MySQL ते हाताळू शकत नव्हतं. प्रत्येक पेजव्ह्यू इतक्या लवकर लिहायला आणि क्वेरी करायला हवा होता की लाइव्ह डेटा दाखवता येईल. खऱ्या ट्रॅफिकमध्ये MySQL चा डिस्क I/O बॉटलनेक बनला. Sanfilippo ची अंतर्दृष्टी होती की डिस्कशी लढणं बंद करायचं — त्याने गृहीतक तपासण्यासाठी Tcl मध्ये LMDB (LLOOGG Memory Database) नावाचा एक झटपट प्रोटोटाइप लिहिला [2]. ते काम केलं. म्हणून त्याने ते C मध्ये नीट पुन्हा लिहिलं.

तोच प्रोटोटाइप Redis बनला. पहिलं पब्लिक रिलीझ 10 एप्रिल, 2009 रोजी झालं [1]. त्याचा मित्र David Welton ने ते Hacker News वर पोस्ट केलं. सुरुवातीची प्रतिक्रिया बहुतांश शांततेची होती — Ezra Zygmuntowicz वगळता, जो एक प्रसिद्ध Ruby on Rails डेव्हलपर होता, त्याने antirez ने काय बनवलं आहे हे लगेच ओळखलं आणि ते पसरवण्यास मदत केली [2].

तिथून ते झपाट्याने पुढे सरकलं. हा आहे ढोबळ टाइमलाइन:

1. 2010 — VMware ने Sanfilippo ला Redis वर पूर्णवेळ काम करण्यासाठी नियुक्त केलं [1]
2. 2012 — GitHub ने ते अॅक्टिव्हिटी फीडसाठी स्वीकारलं; Twitter ने ट्रेंडिंग टॉपिक्स आणि टाइमलाइन फॅनआउटसाठी वापरलं [3]
3. 2013 — VMware च्या पुनर्रचनेत Pivotal ने प्रायोजकत्व स्वीकारलं
4. 2015 — Redis Labs (आता Redis Inc.) प्राथमिक व्यावसायिक कारभारी बनले
5. 2020 — antirez ने सक्रिय विकासातून माघार घेतली

आणि LLOOGG, ते अॅनालिटिक्स टूल ज्याने सगळं सुरू केलं? ते 2014 मध्ये बंद होईपर्यंत Redis वर चाललं — दोन अब्जाहून अधिक पेजव्ह्यू हाताळत, 350–400 कमांड प्रति सेकंद वेगाने, एका व्हर्च्युअल मशीनवर जी महिन्याला $150 खर्च करत होती [2]. एका डेव्हलपरची MySQL परफॉर्मन्स समस्या सोडवण्यासाठी बनवलेला साइड प्रोजेक्ट आता ग्रहावरील जवळपास प्रत्येक गंभीर टेक स्टॅकमध्ये चालतो.

हे इतकं वेगवान का आहे

तीन आर्किटेक्चरल निर्णय Redis ला जे आहे ते बनवतात.

सगळं RAM मध्ये राहतं

हे एकदा म्हटल्यावर उघड होतं, पण स्पष्टपणे सांगणं आवश्यक आहे. RAM मध्ये प्रवेश करणं फिरत्या डिस्कपेक्षा सुमारे 100,000 पट जलद आणि रँडम रीडसाठी SSD पेक्षा सुमारे 10 पट जलद आहे [4]. डिस्क-आधारित डेटाबेस बफर पूल, पेज कॅश आणि I/O रांगा व्यवस्थापित करतात. Redis हे सगळं वगळतं. तुम्ही एखादी की मागता, ती आधीच मेमरीत आहे, काम झालं.

सिंगल-थ्रेडेड इव्हेंट लूप

हे लोकांना आश्चर्यचकित करतं. सिंगल-थ्रेडेड म्हणजे हळू नाही का? Redis साठी नाही — कारण Redis CPU-बाउंड नाही, I/O-बाउंड आहे. सिंगल-थ्रेडेड मॉडेल लॉक कंटेंशन पूर्णपणे काढून टाकतं: म्युटेक्स नाही, रेस कंडिशन नाही, थ्रेड्समधील सिंक्रोनायझेशन ओव्हरहेड नाही. कमांड अणु-स्तरावर आणि क्रमाने चालतात [4]. इव्हेंट लूप नॉन-ब्लॉकिंग I/O द्वारे (आत epoll वापरून) हजारो समवर्ती कनेक्शन्स हाताळतो, त्यामुळे सिंगल थ्रेड कधीही मंद क्लायंटसाठी ब्लॉक होत नाही [11]. Redis 6.0 पासून, पर्यायी थ्रेडेड I/O नेटवर्क रीड्स आणि राइट्स अनेक थ्रेड्सवर ऑफलोड करू शकतो — पण कमांड एक्झिक्यूशन स्वतः सिंगल-थ्रेडेड राहतं. हे दिसतं त्यापेक्षा स्वच्छ डिझाइन आहे.

एफिशिएंट प्रोटोकॉल आणि डेटा स्ट्रक्चर्स

RESP (Redis Serialization Protocol) किमान आणि जलद पार्स करण्यायोग्य आहे. SQL प्लॅनर नाही, JOIN रिझोल्यूशन नाही, ऑप्टिमायझर ओव्हरहेड नाही. आणि डेटा स्ट्रक्चर्स जेनेरिक इम्प्लिमेंटेशन नाहीत — सॉर्टेड सेट्स, उदाहरणार्थ, एकाच वेळी स्किप लिस्ट + हॅश टेबल कॉम्बिनेशन वापरून इम्प्लिमेंट केले जातात, O(1) स्कोर लुकअपसह O(log N) इन्सर्ट देतात [5].

परिणाम: एक मानक Redis इन्स्टन्स GET/SET ऑपरेशन्ससाठी सुमारे 0.167 मिलिसेकंद मध्यम विलंबासह प्रति सेकंद 100,000 हून अधिक ऑपरेशन्स हाताळतो [4]. पाइपलाइनिंगसह — एका नेटवर्क राउंड ट्रिपमध्ये अनेक कमांड्स बॅच करून — तुम्ही त्याच हार्डवेअरवर दहा लाख ops/sec पेक्षा जास्त जाऊ शकता.

लोक खरोखर Redis कशासाठी वापरतात

कॅशिंग (उघड असलेला)

तुमच्याकडे एक Postgres क्वेरी आहे जी प्रत्येक विनंतीवर 180ms लागते. तुम्ही 60-सेकंद TTL सह निकाल Redis मध्ये कॅश करता. आता 95% रीड्स RAM मधून होतात आणि 1ms पेक्षा कमी वेळात परत येतात. हा प्रमुख वापर आहे — आणि म्हणूनच Redis खऱ्या ट्रॅफिक असलेल्या कोणत्याही कंपनीत प्रभावीपणे डिफॉल्ट इन्फ्रास्ट्रक्चर आहे [11].

GitHub ने सुरुवातीला त्यांच्या अॅक्टिव्हिटी फीडसाठी हे वापरलं. प्रत्येक पेज लोडवर डेटाबेस जॉइन्समधून वापरकर्त्याची टाइमलाइन पुन्हा तयार करण्याऐवजी, त्यांनी Redis मध्ये प्री-कम्प्युटेड टाइमलाइन साठवल्या आणि राइट इव्हेंट्सवर त्या अद्यतनित केल्या [3].

सेशन व्यवस्थापन

सेशनमध्ये काय असतं याचा विचार करा: यूझर ID, ऑथ टोकन, कदाचित कार्ट ID. हे लहान आहे, जवळपास प्रत्येक ऑथेंटिकेटेड विनंतीवर वाचलं जातं, आणि जलद असणं आवश्यक आहे. Redis अगदी योग्य आहे — तुम्ही TTL सह एक की सेट करता आणि सेशन संपायला हवं तेव्हा ते आपोआप एक्सपायर होतं. जुन्या सेशन्स साफ करण्यासाठी क्रॉन जॉब नाही, मुख्य डेटाबेसमध्ये कचरा नाही. Instagram ने त्यांच्या स्केलवर Redis मध्ये अशा शेकडो कोटी जोड्या साठवल्या [3].

रेट लिमिटिंग

“या IP ने गेल्या 60 सेकंदात किती API कॉल्स केल्या?” Redis एकाच अणु-स्तरीय INCR + EXPIRE ने याचं उत्तर देतो. कोणते ट्रान्झॅक्शन नाही, लॉकिंग नाही, रेस कंडिशन नाही. Twitter ने संपूर्ण प्लॅटफॉर्मवर API रेट लिमिट्स लागू करण्यासाठी हा पॅटर्न वापरला [3]. हे कदाचित लीकी बकेट पॅटर्नचं सर्वात सुंदर इम्प्लिमेंटेशन आहे जे मी पाहिलं आहे — आणि ते कोडच्या तीन ओळींमध्ये आहे.

रिअल-टाइम लीडरबोर्ड

इथेच सॉर्टेड सेट्स त्यांचं महत्त्व सिद्ध करतात. ZADD leaderboard 9500 "player:88" एक स्कोर जोडतो. ZRANGE leaderboard 0 9 WITHSCORES REV पुन्हा सॉर्ट न करता लगेच टॉप 10 परत करतो, O(log N) इन्सर्टसह [5]. मोबाइल गेम्स रिलेशनल डेटाबेसला न दाबता लाखो समवर्ती स्कोर अद्यतनं अशा प्रकारे हाताळतात. ते फक्त काम करतं.

Pub/Sub मेसेजिंग

Redis मध्ये एक बिल्ट-इन पब्लिश/सबस्क्राइब मेसेजिंग सिस्टम आहे — प्रकाशक नावाच्या चॅनेल्सवर पाठवतात, सदस्य रिअल टाइममध्ये प्राप्त करतात [9]. हे टिकाऊ, रिप्लेड इव्हेंट स्ट्रीम्ससाठी Kafka ची जागा घेण्यासाठी नाही (Redis Pub/Sub मेसेज टिकवत नाही), पण हलक्या रिअल-टाइम सूचनांसाठी — “नवीन चॅट मेसेज”, “किंमत अद्यतन”, “फॉलो इव्हेंट” — हे सुंदरपणे काम करतं आणि शून्य इन्फ्रास्ट्रक्चर ओव्हरहेड जोडतं.

वेक्टर शोध आणि AI वर्कलोड्स

अलीकडे, Redis ने AI वापरांमध्ये खूप रस दाखवला आहे. Redis नियमित डेटासोबत वेक्टर एम्बेडिंग साठवू शकतो, ज्यामुळे ते LLM प्रतिसादांचं सिमॅंटिक कॅशिंग आणि रिट्रीव्हल-ऑगमेंटेड जनरेशन (RAG) पाइपलाइनसाठी उपयुक्त ठरतं [4]. जर तुम्ही LangChain, LangGraph किंवा mem0 सोबत काहीतरी बनवत असाल, तर तुम्ही आधीच Redis ला मेमरी बॅकएंड म्हणून पाहिलं असेल. Redis 8.0 मधील नवीन Vector Sets प्रकार antirez ने स्वतः या वापरासाठी लिहिला होता [13].

परवाना नाट्य (हे खरोखर महत्त्वाचं आहे)

जर तुम्ही आज आर्किटेक्चर निर्णय घेत असाल तर हा भाग संबंधित आहे. प्रामाणिकपणे सांगायचं तर, हे गुंतागुंतीचं झालं.

मार्च 2024 मध्ये, Redis Inc. ने प्रकल्पाचा परवाना परवानगीदायक BSD 3-Clause वरून दुहेरी RSALv2 / SSPLv1 मॉडेलमध्ये बदलला [6]. दोन्ही OSI-मंजूर ओपन सोर्स नाहीत. SSPLv1 मूळतः MongoDB ने क्लाउड प्रदात्यांना लक्ष्य करण्यासाठी तयार केला होता — तो मूलतः म्हणतो: जर तुम्ही हे व्यवस्थापित सेवा म्हणून ऑफर करत असाल, तर तुम्हाला तुमचं संपूर्ण प्लॅटफॉर्मही ओपन-सोर्स करायला हवं.

लक्ष्य स्पष्ट होतं. AWS ElastiCache Redis मधून शेकडो कोटी डॉलर कमवत होता तर Redis Inc. मोफत ते सशुल्क वापरकर्त्यांमध्ये ~1% रूपांतरण दराशी झुंजत होतं [6]. निराशा पूर्णपणे समजण्यासारखी आहे. अंमलबजावणी एक आपत्ती होती.

समुदायाची प्रतिक्रिया त्वरित होती. Linux वितरणं (openSUSE, Fedora) त्यांच्या रेपोमधून Redis काढू लागले. काही आठवड्यांत, माजी Redis मेंटेनर्सनी शेवटच्या BSD-परवानाकृत आवृत्तीचं फोर्क केलं आणि एप्रिल 2024 मध्ये AWS, Google Cloud, Oracle, Alibaba आणि Ericsson च्या पाठिंब्याने Linux Foundation अंतर्गत Valkey लाँच केलं [7].

मग antirez स्वतः — जो 2020 मध्ये प्रकल्पातून मागे गेला होता — नोव्हेंबर 2024 मध्ये Redis Inc. मध्ये परत आला. त्याने मार्ग सुधारण्यासाठी जोरदार दबाव आणला. 1 मे, 2025 रोजी Redis 8.0 ट्राय-लायसन्स: RSALv2, SSPLv1, किंवा AGPLv3 अंतर्गत लाँच झालं [13]. AGPLv3 OSI-मंजूर ओपन सोर्स आहे — समुदायाकडे परत एक खरं पाऊल. Antirez ने याबद्दल उघडपणे लिहिलं: “मला आनंद आहे की Redis पुन्हा ओपन सोर्स सॉफ्टवेअर आहे.”

उलट्या दिशेने जाण्याने नुकसान भरून निघालं का? खरंच नाही. Valkey तोपर्यंत क्रिटिकल मास गाठला होता [14].

पर्याय

Valkey

अलीकडच्या ओपन-सोर्स इतिहासातील सर्वात महत्त्वाचं फोर्क. Valkey म्हणजे Linux Foundation अंतर्गत Redis 7.2.4 — पूर्णपणे प्रोटोकॉल-संगत, जवळपास प्रत्येक वापरासाठी ड्रॉप-इन रिप्लेसमेंट [7]. AWS ने ElastiCache त्यावर स्थलांतरित केलं. Google Cloud Memorystore त्याला सपोर्ट करतो. Aiven ने मे ते ऑगस्ट 2024 दरम्यान 15,000 सर्व्हर स्थलांतरित केले.

Valkey 8.1 कथितपणे Redis OSS पेक्षा ~8% जास्त ops/sec चालवतो, P99 विलंब 22% कमी करतो आणि 20% कमी मेमरी वापरतो [7]. बहुतांश टीम्ससाठी, हा सर्वात सुरक्षित स्थलांतरण मार्ग आहे — पॅकेजचं नाव बदला, इमेज स्वॅप करा, झालं.

Dragonfly

C++ मध्ये नव्याने लिहिलेलं, Redis फोर्क नाही. Dragonfly सर्व CPU कोर एफिशिएंटली वापरण्यासाठी आधुनिक कंकरन्सी प्रिमिटिव्ह — फायबर्स, SIMD, शेअर्ड-नथिंग आर्किटेक्चर — वापरतो [8]. दावा केलेला थ्रूपुट त्याच हार्डवेअरवर Redis पेक्षा 25 पट चांगला आहे, प्रति डेटासेट मेमरी फूटप्रिंटही कमी आहे.

सावधगिरी: हे ~95-98% Redis-संगत आहे. प्रशासकीय कमांडमध्ये एज-केस अंतर आहेत [8]. अत्यंत थ्रूपुट आवश्यकता असलेल्या नवीन प्रकल्पांसाठी, बेंचमार्क रन करणं योग्य आहे. विद्यमान सेटअप स्थलांतरित करण्यासाठी, वचनबद्ध होण्यापूर्वी तुमच्या विशिष्ट कमांड वापराची चाचणी करा.

KeyDB

मल्टी-थ्रेडेड Redis. तोच प्रोटोकॉल, त्याच कमांड्स, पण ते तुमच्या सर्व कोर वर चालतं. Snap ने अधिग्रहण केलं, ज्याने त्यात योग्य अभियांत्रिकी संसाधने आणली [8]. FLASH फीचर (SSD वर टायर्ड स्टोरेज) अशा डेटासेट्ससाठी खरोखरच मनोरंजक आहे जे पूर्णपणे RAM मध्ये बसत नाहीत. जर तुम्हाला परिचित Redis सिमॅंटिक्सवर मल्टी-थ्रेडिंग हवं असेल, तर KeyDB हा सिद्ध पर्याय आहे.

Memcached

ज्येष्ठ नेता. Memcached Redis पूर्वीचा आहे आणि किमान ऑपरेशनल ओव्हरहेडसह शुद्ध स्ट्रिंग कॅशिंगसाठी खरोखरच जलद आहे [10]. कोणती टिकाऊपणा नाही, सॉर्टेड सेट्स नाही, Lua स्क्रिप्टिंग नाही, pub/sub नाही — फक्त जलद की-व्हॅल्यू स्टोरेज. जर तुम्हाला फक्त “हा डेटाबेस निकाल 60 सेकंदांसाठी कॅश करायचा आहे” आणि अधिक काही नाही, तर Memcached ची साधेपणा हा एक गुणधर्म आहे. पण मूळ स्ट्रिंग कॅशिंगच्या पुढे कोणत्याही वापरासाठी, Redis (किंवा Valkey) समान विलंबावर तुम्हाला खूप जास्त देतो.

तुम्ही कोणतं निवडावं?

एकच उत्तर नाही, पण काही प्रामाणिक शॉर्टकट:

• आधीच Redis वर आहात, काम करतंय — AGPLv3 अंतर्गत Redis 8.0 वर अपग्रेड करणं ठीक आहे. AGPLv3 तुम्हाला तेव्हाच प्रभावित करतो जेव्हा तुम्ही Redis ला व्यवस्थापित सेवेत गुंडाळून विकत असाल.
• नव्याने सुरुवात करत आहात, AWS किंवा GCP वर — ElastiCache किंवा Memorystore द्वारे Valkey वापरा. तोच प्रोटोकॉल, स्वच्छ परवाना, AWS वर 20% स्वस्त [7].
• अत्यंत थ्रूपुट आवश्यकता आणि नवीन प्रकल्प — Dragonfly ला गांभीर्याने बेंचमार्क करा.
• फक्त साधं कॅशिंग — Memcached चुकीचं उत्तर नाही जर तुम्हाला खरोखरच अतिरिक्त गोष्टी नको असतील.
• Redis प्रोटोकॉलवर मल्टी-थ्रेडिंग हवं — KeyDB.

या सगळ्याचं विचित्र पाद-टीप: LLOOGG — ते अॅनालिटिक्स टूल ज्याने सगळं सुरू केलं — एक दशकाहून अधिक आधी बंद झालं. antirez ने एका डेव्हलपरची MySQL परफॉर्मन्स समस्या सोडवण्यासाठी बनवलेला साइड प्रोजेक्ट आता ग्रहावरील जवळपास प्रत्येक गंभीर टेक स्टॅकमध्ये चालतो. ते 2020 मध्ये मागे गेले, 2024 मध्ये परत आले, बघितलं की एक फोर्क बारा महिन्यांत प्रमुख क्लाउड प्रदात्यांवर डिफॉल्ट बनलं, आणि नंतर Redis ला ओपन सोर्सकडे परत ढकलण्यात मदत केली.

तुम्ही खरोखरच या मार्गाची योजना आखू शकत नाही.

समाप्त

स्रोत

1. Redis - Wikipedia
2. Story: Redis and its creator antirez — Brachiosoft Blog
3. History of Redis: From Side Project to Industry Standard — OneUptime
4. Complete Guide to Redis in 2026 — DragonflyDB
5. Redis sorted sets | Docs — redis.io
6. Redis tightens its license terms, pleasing no one — The Register
7. Valkey Turns One: How the Community Fork Left Redis in the Dust — Momento
8. 8 Best Redis Alternatives — DragonflyDB
9. Complete Guide to Redis Publish Subscribe — GeeksforGeeks
10. The Good and the Bad of Redis In-Memory Database — AltexSoft
11. What is Redis Explained? — IBM
12. Redis Switches to SSPLv1: Restrictive License Sparks Fork — InfoQ
13. Redis is open source again — antirez.com
14. Redis Returns to Open Source under AGPL License: Is It Too Late? — InfoQ
15. Redis is now available under the AGPLv3 open source license — redis.io
16. Understanding Redis Threading — DEV Community