हो सकता है कि आपको Redis की ज़रूरत न हो

 (viblo.se)
9 पॉइंट द्वारा GN⁺ 2025-03-10 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • Redis टेक इंडस्ट्री में सबसे सकारात्मक प्रतिष्ठा पाने वाली तकनीकों में से एक है
    • यह बहुत अच्छी तरह डिज़ाइन की गई बेहतरीन तकनीक है और इसमें अपने आप में कोई खामी नहीं है, लेकिन यह हमेशा ज़रूरी नहीं होती
  • 10+ सालों में 3 कंपनियों में एक ही पैटर्न देखा गया:
    • समस्या आई और Redis उपयुक्त लगा, लेकिन वास्तव में उसने स्थिति में सुधार नहीं किया या मूल समस्या का समाधान नहीं किया
    • उसने बस जटिलता के लिए जटिलता जोड़ दी

पहला मामला: Tantan का अनुभव

  • Tantan चीन का दूसरा सबसे बड़ा डेटिंग ऐप है, और PostgreSQL आधारित 50~100 हाई-परफॉर्मेंस डेटाबेस सर्वर चलाता है
  • हर सर्वर user ID के आधार पर sharding किया गया है, इसलिए किसी विशेष user का डेटा सिर्फ एक सर्वर में ही संग्रहीत होता है
  • समस्या की स्थिति
    • 'swipe' की गिनती को स्टोर करना और तेज़ी से अपडेट करना ज़रूरी था
    • शुरुआत में इसे Redis में स्टोर करना उपयुक्त माना गया
    • लगा कि कुछ हाई-परफॉर्मेंस Redis सर्वर ही पर्याप्त होंगे, इसलिए सेटअप शुरू किया गया
  • पुनर्विचार और समाधान
    • टीम में Redis की जगह सीधे PostgreSQL में स्टोर करने के विकल्प पर चर्चा हुई
    • PostgreSQL सर्वरों पर लोड पहले से ही ऊँचा था, इसलिए अतिरिक्त लोड बहुत कम रहने की उम्मीद थी
    • PostgreSQL में स्टोर करने के बाद भी परफॉर्मेंस में कोई गिरावट नहीं आई, और Redis अपनाना अनावश्यक था

दूसरा मामला: Bannerflow का अनुभव

  • पृष्ठभूमि
    • Bannerflow विज्ञापन निर्माण और प्रकाशन प्लेटफ़ॉर्म है
    • एक नई microservice में Facebook जैसे social network पर विज्ञापन प्रकाशित करने के समर्थन के लिए Redis अपनाने का निर्णय लिया गया
  • समस्या की स्थिति
    • Tantan की तुलना में लोड काफ़ी कम था, इसलिए Redis की ज़रूरत थी भी या नहीं, यह स्पष्ट नहीं था
    • शुरुआती डेवलपर के जाने के बाद Redis अपनाने की वजह साफ़ तौर पर समझाने वाला कोई नहीं था
  • परिणाम
    • लोड कम होने के कारण Redis की वास्तव में ज़रूरत नहीं थी
    • लंबे समय में Redis को हटाना सबसे अच्छा विकल्प है, इस निष्कर्ष पर पहुँचा गया

तीसरा मामला: MAJORITY का अनुभव

  • पृष्ठभूमि
    • MAJORITY एक fintech कंपनी है, जिसने बाहरी API कॉल के परिणाम cache करने के लिए Redis अपनाया
    • Redis को location lookup डेटा cache करके प्रोसेसिंग स्पीड बढ़ाने और लागत घटाने के लिए लाया गया
  • समस्या की स्थिति
    • वही डेटा DB (Azure SQL) में भी स्टोर था
    • Redis कॉल की जगह DB कॉल करने पर भी लोड में लगभग कोई वृद्धि नहीं होने की उम्मीद थी
    • lock प्रोसेसिंग की ज़रूरत के कारण Redis को बनाए रखना चाहा गया, लेकिन Azure SQL इसे पर्याप्त रूप से संभाल सकता था
  • परिणाम
    • इस निष्कर्ष पर पहुँचा गया कि Redis अपनाना अनावश्यक था
    • Redis की जगह Azure SQL उपयोग करने की योजना बनाई गई

निष्कर्ष

  • ये तीनों मामले अलग-अलग डोमेन, tech stack और लोड स्थितियों में हुए
  • समानता यह थी कि Redis अनावश्यक रूप से अपनाया गया था
  • Redis अपनाने से पहले वास्तविक आवश्यकता और परफॉर्मेंस लाभ पर पर्याप्त विचार करना चाहिए
  • Dan McKinley के 'Choose Boring Technology' व्याख्यान की सिफारिश

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

5 टिप्पणियां

 
iolothebard 2025-03-10

Redis का उपयोग करना है या नहीं, इससे अलग domain और persistence के बीच एक caching layer रखना (जिसका basic implementation bypass हो) बिल्कुल भी over-engineering नहीं है। Logging, fake data, debugging, profiling, और शायद असली caching भी…
 
nodelay 2025-03-10

+1 मैं भी सहमत हूँ। सिर्फ़ एक layer जोड़ने से भी leeway बनती है, और कई तरह की चीज़ों को सुलझाने के लिए जगह मिल जाती है।
 
galadbran 2025-03-10

ऐसा लगता है कि बात Redis में समस्या होने की नहीं है, बल्कि इस दृष्टिकोण की है कि जब केवल DB से काम चल सकता है, तो अतिरिक्त component जोड़कर management burden क्यों बढ़ाया जाए।
यह काफ़ी संक्षेप में समझाता है, इसलिए इसे बस इस रूप में लेना अच्छा होगा कि इस तरह का नज़रिया भी विचार करने लायक है।
ऐसी स्थितियाँ भी हो सकती हैं जहाँ application logic को simple रखते हुए Redis cache लागू करना बेहतर विकल्प हो,
इसलिए स्थिति के अनुसार चुनना होगा.
 
zinisuni 2025-03-24

टाइटल ने फँसा लिया था। हा हा, सहमत हूँ~~
 
GN⁺ 2025-03-10
Hacker News राय

  • 2015 में Uber में काम करते समय, ZIP code आधारित geographic partitioning को hexagon आधारित तरीके में बदलने की कोशिश की गई थी

    • शहर को कुछ दर्जन ZIP code में बाँटने के बजाय, उसे कई लाख hexagon में बाँटकर dynamic region बनाने का तरीका था
    • Phoenix में पहला launch हुआ था, और टीम demand pricing system को scale करने के लिए रात भर जागी थी
    • global launch में देरी हुई थी
    • Redis को पसंद करने वाले engineers बहुत थे
    • pricing service Redis पर आधारित थी और millions of requests संभालती थी
    • इसकी लागत बहुत थी, और scalability की समस्याएँ भी थीं
    • algorithm को बेहतर बनाकर एक single machine पर कई शहरों के dynamic region calculate किए जा सकते थे
    • Isaac नाम के एक engineer ने इसे weekend में implement और deploy किया था

  • Redis के overuse पर बहस हुई थी

    • Redis शानदार है, लेकिन इसे इस्तेमाल करने पर network latency और serialization overhead आता है
    • अगर data पहले से partitioned है, तो सामान्य hash map बेहतर हो सकता है
    • Java में ConcurrentHashMap, Guava Caches, Caffeine Caches आदि हैं
    • local caching implementation, network का उपयोग करने वाली चीज़ों से लगभग हमेशा तेज़ होती है
    • Redis का ज़रूरत से ज़्यादा उपयोग होने की प्रवृत्ति है

  • Redis के उपयोग की संस्कृति उसकी लोकप्रियता की तुलना में विकसित नहीं हुई है

    • Redis कई data structures को support करता है, और जैसे-जैसे company culture विकसित होती है, वैसे-वैसे अधिक patterns सीखे जा सकते हैं
    • Redis के लिए patterns का कोई संकलन नहीं होना अफ़सोसजनक है

  • यह Redis बनाम non-Redis का मुद्दा नहीं है, बल्कि ऐसे data के साथ काम करने का मुद्दा है जो अच्छी तरह serialize नहीं होता

    • counters, news feeds, chat messages आदि के लिए Redis अधिक efficient हो सकता है
    • ज़्यादातर मामलों में MySQL भी काफ़ी होता है

  • software development में अक्सर दूसरे लोगों के तरीके दोहराने की प्रवृत्ति होती है

    • यह Memcached से शुरू होकर Redis तक विकसित हुआ
    • database की जटिलता से बचने के लिए cache इस्तेमाल करने की प्रवृत्ति है
    • database अब भी जटिल और कठिन हैं

  • Redis ही एकमात्र production-ready "data structure server" है

    • जब कई instances से एक ही service access की जाती है, तब यह उपयोगी होता है

  • हो सकता है cache की ज़रूरत ही न हो

    • cache लाए बिना architecture सुधारने पर ध्यान देने का अनुभव रहा है

  • Redis का API शानदार है, लेकिन operational risk है

    • cache के रूप में अच्छा है, लेकिन production data store के रूप में भरोसेमंद नहीं है

  • Redis के उपयोग की सिफारिश न करने की प्रवृत्ति आश्चर्यजनक है

    • Redis अब भी शानदार data structures और performance देता है

  • Redis temporary cache के रूप में ठीक है, लेकिन transaction या distributed store के रूप में कमज़ोर है

    • distributed locking की समस्याओं के बारे में सीखने की ज़रूरत है