Postgres में बदलावों को कैप्चर करने के तरीके

 (blog.sequin.io)
4 पॉइंट द्वारा GN⁺ 2023-09-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख Postgres डेटाबेस में होने वाले बदलावों को कैप्चर करने के विभिन्न तरीकों पर चर्चा करता है।
  • Sequin नाम की एक कंपनी Salesforce और HubSpot जैसे third-party API से डेटा sync करती है, ताकि डेवलपर्स अपने Postgres डेटाबेस का उपयोग करके API डेटा पर applications बना सकें।
  • Postgres में चलते हुए डेटा को कैप्चर करने के कई विकल्प हैं, जैसे table changes के आधार पर workflows trigger करना, या real time में डेटा को दूसरे data store, system, या service तक stream करना।
  • सबसे सरल तरीका Postgres के inter-process communication feature, Listen/Notify, का उपयोग करना है। यह publish-subscribe pattern का एक implementation है, लेकिन इसमें "at most once" delivery semantics और 8000 bytes payload size limit जैसी सीमाएँ हैं।
  • एक और तरीका है tables को सीधे poll करना। इसके लिए हर table में updated_at column या वैसा कोई field होना चाहिए, जो हर row update होने पर update हो। लेकिन यह तरीका row delete होने का पता नहीं लगा सकता और differences भी उपलब्ध नहीं कराता।
  • Postgres दूसरे Postgres डेटाबेस के लिए streaming replication को support करता है, जिसका उपयोग application changes को कैप्चर करने में किया जा सकता है। लेकिन यह तरीका जटिल है और postgresql.conf को adjust करना पड़ सकता है।
  • बदलावों को audit tables से भी कैप्चर किया जा सकता है, जो changes को log करती हैं। यह approach replication slots के उपयोग जैसा है, लेकिन अधिक manual है।
  • Postgres में foreign data wrappers (FDWs) भी हैं, जो external data sources से पढ़ने और लिखने की सुविधा देते हैं। हालांकि, यह तरीका केवल बहुत specific situations में ही recommended है।
  • निष्कर्षतः, Postgres में बदलावों को कैप्चर करने का सबसे अच्छा तरीका आपके use case पर निर्भर करता है। Listen/Notify non-critical events को कैप्चर करने के लिए अच्छा है, polling simple use cases के लिए एक intuitive solution है, और replication एक robust solution के लिए सबसे बेहतर विकल्प है। अगर replication बहुत कठिन लगे, तो audit tables एक अच्छा middle-ground solution हो सकती हैं।

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

1 टिप्पणियां

 
GN⁺ 2023-09-24
Hacker News राय
  • यह लेख लोकप्रिय डेटाबेस सिस्टम Postgres में बदलावों को कैप्चर करने के विभिन्न तरीकों पर चर्चा करता है।
  • एक कमेंट करने वाला 30 से अधिक वर्षों से इस्तेमाल हो रही तकनीक, यानी trigger और history table (audit table), का उपयोग करके बदलावों को कैप्चर करने की जोरदार सिफारिश करता है।
  • कमेंट करने वाला इस तकनीक को लागू करने के तरीके पर एक गाइड लिंक देता है और application-space history tracking library इस्तेमाल करने के बारे में चेतावनी देता है।
  • एक अन्य कमेंट करने वाला Temporal Tables pattern के साथ अपने सकारात्मक अनुभव साझा करता है, जो किसी खास समय पर table की स्थिति देखने की सुविधा देता है।
  • एक अन्य कमेंट करने वाला pgaudit नाम के एक अच्छी तरह परखे गए extension का उपयोग करने का सुझाव देता है, जो audit table बनाता है।
  • कुछ कमेंट करने वाले updated_at column को poll करने जैसे कुछ खास तरीकों के संभावित जोखिमों पर चर्चा करते हैं।
  • Elixir & Postgres उपयोगकर्ताओं के लिए WAL बदलावों को सुनने वाली एक library का भी उल्लेख है।
  • कुछ कमेंट करने वाले कहते हैं कि इस क्षेत्र में innovation की जरूरत है, और सुझाव देते हैं कि Postgres को query results को incrementally push करने की क्षमता से फायदा हो सकता है।
  • एक कमेंट करने वाला replication का उपयोग करके बदलावों को कैप्चर करने के जोखिमों के बारे में चेतावनी देता है, और कहता है कि अगर Postgres डेटा consume करना बंद कर दे, तो वह छूटा हुआ डेटा तब तक स्टोर कर सकता है जब तक disk भर न जाए।
  • वही कमेंट करने वाला polling का उपयोग करने की सलाह देता है, लेकिन updated_at के बजाय txid को स्टोर करने का सुझाव देता है।
  • यह चर्चा data world के एक हिस्से को उजागर करती है — query results को incrementally push करने के लिए एक साफ-सुथरे समाधान की जरूरत।