Postgres queue तकनीक चुनना

 (adriano.fyi)
6 पॉइंट द्वारा GN⁺ 2023-09-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Postgres queue अच्छा है, लेकिन मुख्यधारा में न होने का कारण यह आम धारणा है कि दूसरी queue तकनीकें ज़्यादा scalability देती हैं
  • webapp.io जैसी कंपनियों ने scalability से अधिक operational simplicity, maintainability, और familiarity को महत्व देते हुए Postgres queue चुना
  • Postgres queue तकनीक के घटक
    • नए काम की सूचना देना और सुनना (pub/sub) तथा mutual exclusion (row locks)
    • ये दोनों Postgres 9.5 में उपलब्ध हुए, जो 2016 में रिलीज़ हुआ था
  • उद्योग में मौजूद इस आम सोच का खंडन कि Postgres का इस तरह उपयोग करना 'hacky' है, और यह तर्क कि Postgres कोई घटिया queue तकनीक नहीं है
  • लंबे समय तक चलने वाले कामों को संभालने के लिए Redis, Apache Kafka, RabbitMQ, Amazon SQS जैसे queue tools चुने जाते रहे हैं
  • तकनीकी उद्योग में 'scale' के प्रति जुनून की आलोचना, और simplicity, maintainability, तथा developer cognitive load को कम करने की कीमत पर लिए जाने वाले फैसलों की भी आलोचना
  • लेखक का सुझाव है कि तकनीकी निर्णय लेते समय उन तकनीकों पर भी विचार करना चाहिए जिन्हें आप अभी इस्तेमाल कर रहे हैं और अच्छी तरह समझते हैं
  • पहले से उपयोग में और अच्छी तरह समझी जा चुकी 'boring technology' चुनने की सिफारिश
  • 'building an escape hatch' की अवधारणा का परिचय, जिसका मतलब है कि job processing के लिए application code queue से स्वतंत्र होना चाहिए
  • लेखक निष्कर्ष निकालते हैं कि लोगों को Postgres queue तकनीक पर विचार करना चाहिए और 'boring technology' को default choice बनाना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2023-09-25
Hacker News राय
  • Kafka की सादगी, durability और fault tolerance को मान्यता मिली है, लेकिन इसकी distributed प्रकृति ज़्यादातर use cases में complexity बढ़ा सकती है.
  • Postgres queue, Redis queue की जगह ले सकती है, लेकिन SQS queue की नहीं.
  • Postgres का उपयोग सिस्टम के चालू होने के बाद 40 करोड़ से अधिक events प्रोसेस करने के लिए किया गया, और यह प्रतिदिन लगभग 10 लाख events प्रोसेस करता था.
  • सामान्य table का उपयोग करके SELECT FOR UPDATE SKIP LOCKED इस्तेमाल करना एक सरल तरीका है, जो सभी ORM/Query DSL framework में काम करता है.
  • LISTEN/NOTIFY का उपयोग करके PostgreSQL को pub/sub bus की तरह इस्तेमाल करने की मुख्य कमी यह है कि LISTEN एक session feature है, इसलिए यह statement-level connection pooling के साथ compatible नहीं है.
  • Postgres को application queue के रूप में इस्तेमाल करने से transactionality का लाभ मिलता है, इसलिए scheduled asynchronous jobs इससे फायदा उठाते हैं.
  • Postgres को queue के लिए scale किया जा सकता है, लेकिन AWS, GCP, Azure में SQS या किसी दूसरे queue stack को सेट अप करना ज़्यादा सरल है और वह इसी उद्देश्य के लिए बनाया गया है.
  • Postgres ने github CI instance पर 1200jobs/s के साथ benchmark चलाया, और अतिरिक्त workers के साथ 5000jobs/s तक scale किया गया.
  • Elixir के Oban के साथ Postgres का उपयोग background jobs के आसपास transactional semantics की सुविधा के कारण, हर दिन लाखों तक jobs प्रोसेस करने में किया गया.
  • 47M jobs प्रोसेस करने वाले implementation ने VACUUM के लिए SKIP LOCKED, delayed jobs, retries, state updates, और "at least once" जैसे महंगे patterns को लागू करने के लिए indexed durable storage के फायदों को रेखांकित किया.