क्या Redis की ज़रूरत है? जब PostgreSQL queueing, locking और pub/sub सुविधाएँ देता है (2021)

 (spin.atomicobject.com)
2 पॉइंट द्वारा GN⁺ 2024-11-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • उपयोग का मामला 1: कार्य queueing

    • Redis का उपयोग वेब सेवाओं में background jobs को समन्वित करने के लिए अक्सर किया जाता है।
    • PostgreSQL 9.5 के बाद SKIP LOCKED विकल्प का उपयोग करके कार्य queueing लागू की जा सकती है।
    • यह विकल्प lock का इंतज़ार किए बिना कार्य चुनने देता है, जिससे कई workers एक ही कार्य को एक साथ प्रोसेस न करें, यह सुनिश्चित होता है।

  • उपयोग का मामला 2: application locking

    • Redis का उपयोग distributed locking के लिए अक्सर किया जाता है।
    • PostgreSQL के advisory locks का उपयोग करके वही कार्यक्षमता लागू की जा सकती है।
    • Advisory locks, PostgreSQL के internal lock engine को application-परिभाषित उद्देश्यों के लिए इस्तेमाल करने देते हैं।

  • उपयोग का मामला 3: Pub/Sub

    • Redis का उपयोग active clients तक events push करने के लिए किया जाता है।
    • PostgreSQL 9 के बाद LISTEN और NOTIFY स्टेटमेंट्स का उपयोग करके Pub/Sub सुविधा प्रदान करता है।
    • PostgreSQL clients किसी खास message channel को subscribe कर सकते हैं, और जब कोई दूसरा client उस channel पर message भेजता है, तो सभी subscribers को notification मिलती है।

  • PostgreSQL का पूर्ण उपयोग

    • Redis का उपयोग PostgreSQL से अलग उद्देश्यों के लिए होता है, और यह TTL वाले data caching तथा अस्थायी data storage में बेहतरीन है।
    • PostgreSQL केवल एक SQL database से अधिक सुविधाएँ देता है, और Redis से किए जाने वाले कुछ कार्यों को PostgreSQL से बदलने की संभावना है।
    • यह कई data services इस्तेमाल करने की जटिलता घटाने और operational cost कम करने के लिए एक मूल्यवान विकल्प हो सकता है।

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

1 टिप्पणियां

 
GN⁺ 2024-11-04
Hacker News राय

  • Redis, जब एप्लिकेशन के साथ उसी मशीन पर चलता है, तो बहुत तेज़ response time देता है। इससे ऐसे काम संभव होते हैं जो Postgres से अलग हैं

    • in-memory key-value store उन कामों के लिए उपयुक्त है जिन्हें RAM की performance characteristics चाहिए
    • यह अपने-आप में स्पष्ट है कि network connection के ज़रिए RAM जैसी performance नहीं मिल सकती

  • PostgreSQL सिर्फ एक साधारण SQL database से कहीं अधिक सुविधाएँ देता है

    • अगर database को सिर्फ ORM के पीछे से इस्तेमाल किया जाए, तो उसकी कई क्षमताएँ छूट सकती हैं
    • Redis जैसी service जोड़ने की बजाय, पहले से सेटअप किए गए database का उपयोग करना बेहतर हो सकता है

  • PGQueuer, PostgreSQL का उपयोग करके job queue, locking और real-time notifications देने वाला एक न्यूनतम alternative है

    • यह Redis की आवश्यकता को कम करता है

  • Postgres एक शक्तिशाली database है

    • Redis की entry barrier कम है, performance ऊँची है, और यह primary database पर load कम करता है
    • API response caching, Postgres में भी संभव है, लेकिन Redis का उपयोग करना ज़्यादा सरल है
    • अलग system इस्तेमाल करना एक downside है, लेकिन Redis के मामले में यह downside बहुत बड़ा नहीं है

  • ज़्यादातर projects को सिर्फ एक simple job queue चाहिए होती है, और complex stack को सरल बनाना महत्वपूर्ण है

    • इसके लिए कई अलग-अलग alternatives मौजूद हैं, जिनमें से कुछ के commercial interests भी जुड़े हैं

  • Postgres की कुछ सीमाएँ हैं

    • KVstore, queue, pubsub, locking जैसी सुविधाएँ हल की जा सकती हैं, लेकिन यह सरल नहीं है

  • PostgreSQL से शुरुआत करना और ज़रूरत पड़ने पर Redis पर जाना बेहतर है

    • moving parts की संख्या को न्यूनतम रखना महत्वपूर्ण है

  • Postgres pub/sub की एक बड़ी कमी यह है कि message size 8000 bytes तक सीमित है

    • data को database में store करके सिर्फ ID भेजने का तरीका है, लेकिन इसके लिए अतिरिक्त काम करना पड़ता है

  • Redis का सबसे महत्वपूर्ण उपयोगों में से एक, caching, Postgres में अधिक जटिल है

    • Postgres में updates, inserts की तुलना में अधिक महंगे होते हैं, और durability guarantee caching के लिए उतनी महत्वपूर्ण नहीं होती

  • Postgres में इन सुविधाओं का उपयोग करने पर updates और replication और कठिन हो जाते हैं

    • यह संभव है, लेकिन लोग अक्सर Postgres की अधिक व्यापक रूप से उपयोग की जाने वाली सुविधाओं पर ध्यान केंद्रित करना पसंद करते हैं