11 पॉइंट द्वारा GN⁺ 2024-03-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें

वितरित, fault-tolerant कार्य queue

  • Hatchet मौजूदा कठिन-प्रबंधनीय queue या pub/sub सिस्टम की जगह लेकर ऐसे durable workloads डिज़ाइन करने में मदद करता है जो failures से recover कर सकें और concurrency, fairness, rate limiting जैसी समस्याओं को हल कर सकें।
  • अपनी खुद की कार्य queue या pub/sub सिस्टम को manage करने के बजाय, Hatchet का उपयोग करके बहुत कम setup या infrastructure के साथ functions को workers की एक श्रृंखला के बीच वितरित किया जा सकता है.

Hatchet के फायदे

  • अत्यंत कम latency और high-throughput scheduling
    • Hatchet 25ms औसत start time वाली low-latency queue पर बनाया गया है, जो real-time interaction क्षमता और mission-critical कार्यों के लिए आवश्यक reliability के बीच बेहतरीन संतुलन देता है।
  • Concurrency, fairness, rate limiting
    • FIFO, LIFO, Round Robin, Priority Queues जैसी strategies को Hatchet की built-in strategies के रूप में लागू करके, बहुत कम setup के साथ आम scaling समस्याओं से बचा जा सकता है।
  • डिज़ाइन के स्तर पर resilience
    • custom retry policies और integrated error handling के जरिए Hatchet यह सुनिश्चित करता है कि कार्य transient failures से तेज़ी से recover कर सकें।

बेहतर visibility और control

  • Observability
    • हर execution पूरी तरह searchable है, जिससे समस्याओं की तेज़ी से पहचान की जा सकती है।
  • (व्यावहारिक) durable execution
    • events को replay किया जा सकता है और workflow के किसी विशेष चरण से execution को manually फिर से शुरू किया जा सकता है।
  • Cron
    • function execution को बार-बार schedule किया जा सकता है।
  • One-time scheduling
    • किसी खास समय और तारीख पर function execution को schedule किया जा सकता है।
  • Spike protection
    • traffic spikes को कम करता है और केवल उतना ही execute करता है जितना सिस्टम संभाल सकता है।
  • Incremental streaming
    • background workers की progress के अनुसार updates को subscribe किया जा सकता है।

उदाहरण उपयोग मामले

  • Generative AI के लिए fairness
    • व्यस्त users सिस्टम पर हावी न हों, इसके लिए Hatchet का उपयोग करके requests को workers में fairness के साथ वितरित किया जा सकता है।
  • दस्तावेज़ indexing के लिए batch processing
    • Hatchet documents, images और अन्य data की large-scale batch processing संभाल सकता है और failure होने पर बीच से कार्य फिर शुरू कर सकता है।
  • Multimodal सिस्टम्स के लिए workflow orchestration
    • Hatchet multimodal inputs और outputs को coordinate कर सकता है, और पूरे DAG-style execution को संभाल सकता है।
  • Event-driven processing के लिए correctness
    • external events या system के internal events पर प्रतिक्रिया दे सकता है और events को अपने आप replay कर सकता है।

Quick start

  • Hatchet Python, Typescript, Go के लिए open source SDKs को support करता है।
  • शुरू करने के लिए Hatchet docs देखें, या quickstart repository देख सकते हैं।

SDK repositories

  • Hatchet मुख्य रूप से Go SDK प्रदान करता है।
  • Typescript SDK भी उपलब्ध है।
  • SDK से जुड़ी समस्या आने पर संबंधित repository में issue submit किया जा सकता है।

क्या Hatchet का managed cloud version है?

  • हाँ, beta अवधि के दौरान कुछ कंपनियों को cloud version दिया जा रहा है जो product को build और shape देने में मदद कर रही हैं।

क्या Hatchet का self-hosted version है?

  • हाँ, self-hosting के लिए open source Docker containers के निर्देश docs में मिल सकते हैं।

यह alternatives से कैसे तुलना करता है? (Celery, BullMQ)

  • एक और managed queue क्यों बनाया गया?
    • खास तौर पर DAG-style execution पर निर्भर end-to-end transactional queueing के लाभ हासिल करने का लक्ष्य था, और यह मज़बूत विश्वास है कि Postgres अधिकांश queueing use cases की जगह ले सकता है।
    • कई queues Redis पर आधारित हैं, और सावधानी न बरतने पर OOM के कारण data loss हो सकता है, लेकिन PG का उपयोग करके इन समस्याओं से बचा जा सकता है।

समस्याएँ

  • GitHub issues के जरिए मिले हुए bugs submit किए जा सकते हैं।
  • प्रोजेक्ट अभी शुरुआती चरण में है, इसलिए जटिल feature requests से पहले Discord पर पहले संपर्क करना बेहतर है।

अगर आप योगदान करना चाहते हैं

  • contribution docs देखें, और Discord के #contributing चैनल में बताएं कि आप किस पर काम करना चाहते हैं, ताकि project direction तय करने और collaboration को आसान बनाने में मदद मिल सके।

GN⁺ की राय

  • Hatchet वितरित सिस्टम्स में कार्य queue प्रबंधन की जटिलता को कम करने और high availability व fault tolerance देने वाला समाधान लगता है, खासकर large-scale data processing और real-time services के लिए।
  • मौजूदा बाज़ार के अन्य queue सिस्टम्स की तुलना में Postgres के उपयोग से मिलने वाली stability और scalability इसका एक उल्लेखनीय फायदा है।
  • Hatchet अपनाते समय मौजूदा infrastructure के साथ compatibility, data migration, और टीम की technical capability जैसी बातों पर विचार करना होगा।
  • Hatchet द्वारा दी गई advanced visibility और control सुविधाएँ system performance monitoring और troubleshooting को आसान बनाकर developers और operations टीम का काम कम कर सकती हैं।
  • चूँकि Hatchet अभी beta चरण में है, इसलिए stability और functionality के लिहाज़ से पर्याप्त validation ज़रूरी है, और इसे बड़े सिस्टम्स में लागू करने से पहले पर्याप्त testing की जानी चाहिए।

1 टिप्पणियां

 
GN⁺ 2024-03-09
Hacker News राय
  • एक उपयोगकर्ता ने कहा कि वह 3 साल से Postgres-आधारित job queue, कई भाषाओं में काम करने वाले worker, और उचित built-in observability वाला प्रोडक्ट ढूंढ रहे थे। यह उपयोगकर्ता हर 6 महीने में बाज़ार देखकर विकल्पों का मूल्यांकन करता था, लेकिन हमेशा निराश हुआ। हालांकि, वह RabbitMQ जैसी अतिरिक्त dependency से बचना चाहता था, इसलिए Postgres-आधारित queue को प्राथमिकता देता है। अभी वह graphile-worker का उपयोग कर रहा है, लेकिन उसकी कुछ ज़रूरतें अब भी पूरी नहीं हुई हैं।
  • एक अन्य उपयोगकर्ता ने बताया कि इस प्रोडक्ट को Y Combinator का समर्थन प्राप्त है, और उसने पूछा कि क्या यह कंपनी "open core" मॉडल अपनाएगी या कमाई का कोई दूसरा तरीका खोजेगी।
  • एक और उपयोगकर्ता ने कहा कि उसे pub/sub सिस्टम की push subscription सुविधा पसंद है। उदाहरण के लिए, GCP pub/sub में queue से event pull करने के बजाय ऐसा subscriber रखा जा सकता है जो HTTP endpoint पर push करे। इस तरीके का फायदा यह है that cloud run या lambda जैसे runtime का उपयोग करके HTTP requests के आधार पर scale किया जा सकता है और zero तक scale down भी किया जा सकता है। worker के लिए auto-scaling सेट करना अधिक जटिल हो सकता है, और RabbitMQ में queue depth metric के आधार पर KEDA auto-scaling भी सेट किया जा सकता है, लेकिन इससे जटिलता बढ़ती है। उपयोगकर्ता ने पूछा कि क्या daemon जो HTTP connection बनाए रखता है, उसके जरिए jobs push करने वाले मॉडल को सपोर्ट करने की योजना है।
  • एक उपयोगकर्ता ने पूछा कि सभी functions context को argument के रूप में क्यों लेते हैं। उसका कहना था कि इससे function लिखते समय काफी boilerplate code लिखना पड़ता है।
  • एक अन्य उपयोगकर्ता ने कहा कि जब वह distributed DAG processing system लागू कर रहा था, तब काश उसके पास यह विचार होता, और अब वह इसे आज़माना चाहता है।
  • एक उपयोगकर्ता ने पूछा कि क्या cloud-hosted service की pricing सार्वजनिक की जाएगी, और क्या self-hosting विकल्प के लिए Kubernetes operator बनाने की योजना है। उसने यह चिंता भी जताई कि MIT license के कारण भविष्य में Amazon, Amazon Hatchet service बना सकता है।
  • एक अन्य उपयोगकर्ता ने कहा कि वह DAG-आधारित job runner के लिए job queue लिख रहा है और चाहता है कि job graph PostgreSQL, SQLite, in-memory आदि का उपयोग करते हुए retries, timeouts, serialized resources जैसी बातों की चिंता किए बिना चल सके। उसने कहा कि उसे इस approach में रुचि है।
  • एक उपयोगकर्ता ने कहा कि उसे ऐसी job queue चाहिए जिसमें client (web browser) job की progress को completion तक सुन सके। उसे Deno queue की simplicity और accessibility पसंद है, लेकिन client से job status subscribe करने का तरीका खुद बनाना पड़ता है। उसने पूछा कि क्या Postgres के आधार पर यह संभव है, और documentation link देखकर पुष्टि की कि यह संभव है।
  • एक अन्य उपयोगकर्ता ने बताया कि अपनी पिछली नौकरी में उसे unlimited jobs schedule करने की समस्या का सामना करना पड़ा था। उदाहरण के लिए, अगर कोई मरीज 6 महीने बाद appointment बुक करता है, तो उस अवधि के दौरान appointment reminder की एक श्रृंखला schedule करनी होती है। उसने शुरुआत database queue में records डालकर और हर कुछ सेकंड में polling करके की थी, लेकिन polling से होने वाली IO cost आदर्श नहीं थी, इसलिए वह distributed system का उपयोग किए बिना इसका समाधान चाहता था। बाद में वह Redis पर गया, लेकिन multiple dispatcher को संभालने की जटिलता, OOM समस्याएँ, और jobs को immediate queue में ले जाने के लिए auxiliary jobs चलाने जैसी समस्याएँ आईं। उसने PG पर जाकर SKIP LOCKED आदि इस्तेमाल करने के तरीके पर विचार किया, लेकिन फिर नौकरी बदल ली। उसने पूछा कि क्या Hatchet इस तरह के use case के लिए उपयुक्त है।
  • अंत में, एक उपयोगकर्ता ने पूछा कि Hatchet की तुलना Temporal/Cadence/Conductor से कैसे की जाती है, और क्या Hatchet भी durable execution को support करता है।