रिलेशनल डेटा से events की ओर बदलाव

 (event-driven.io)
2 पॉइंट द्वारा GN⁺ 2023-12-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें

रिलेशनल डेटा से events की ओर बदलाव की मार्गदर्शिका

  • Event sourcing में business data को खोए बिना events के रूप में संरक्षित किया जाता है।
  • Events घटित हुई वास्तविक बातों को दर्शाते हैं, और हर operation के बाद सहेजे जाते हैं।
  • Event stream रिकॉर्ड किए गए सभी events की सूची होती है, जो immutable होती है, और अतीत की गलतियों को नए events जोड़कर सुधारा जा सकता है।

1. status columns खोजें

  • status column के मान data lifecycle के चरणों को दर्शा सकते हैं।
  • उदाहरण के लिए, कोई order शुरू हो सकता है, ship हो सकता है, और paid हो सकता है।
  • इन statuses को Order Initiated, Order Shipped, Order Paid जैसे events में बदला जा सकता है।

2. date columns जाँचें

  • date columns process की महत्वपूर्ण घटनाओं के बारे में जानकारी दे सकते हैं।
  • ShipmentDate, DeliveryDate, OrderPlacementDate आदि business terminology बताते हैं और नए events शुरू करने में मदद कर सकते हैं।

3. column selectivity का विश्लेषण करें

  • Nullable columns बाद में दिए जाने वाले या optional हो सकते हैं।
  • Required columns पहले Order Initiated event में दिए जाने चाहिए।

4. सबसे अधिक 1-to-many relationships वाली tables खोजें

  • Event sourcing में efficient processing के लिए data को business process के केंद्र में group किया जाता है।
  • जिन tables में 1-to-many relationships अधिक हों, वे stream type के candidate हो सकते हैं।

5. explicit events शामिल करें

  • रिलेशनल डेटा को events में migrate करते समय, नए खोजे गए events को import के दौरान दोबारा इस्तेमाल नहीं करना चाहिए; इसके बजाय Order Imported event को स्पष्ट रूप से देना चाहिए।

6. प्रयोग और सत्यापन

  • सुरक्षित environment में prototype आज़माएँ, परिणामों की अपेक्षाओं से तुलना करें, और जल्दबाज़ी किए बिना iteration करें।

GN⁺ की राय

  • इस लेख का सबसे महत्वपूर्ण बिंदु यह है कि relational database से event sourcing में बदलाव के दौरान business data को संरक्षित रखने के लिए एक नए approach का महत्व क्या है।
  • यह लेख इसलिए रोचक है क्योंकि यह पारंपरिक data management तरीके से आगे बढ़कर data lifecycle को बेहतर समझने और उपयोग करने का तरीका दिखाता है।
  • Event sourcing सिर्फ तकनीकी दृष्टिकोण से ही नहीं, बल्कि business और technical teams के बीच साझा समझ बनाने में भी मदद कर सकता है।

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

1 टिप्पणियां

 
GN⁺ 2023-12-18
Hacker News राय

  • PostgreSQL और FOSS reporting tools के उपयोग की सिफारिश

    • अगर application में पहले से PostgreSQL इस्तेमाल हो रहा है, तो event data को PostgreSQL में store करने और FOSS reporting tools (Apache Superset, Metabase आदि) इस्तेमाल करने की सिफारिश की गई है.
    • लगभग 2TB data तक PostgreSQL इस्तेमाल करने, और उसके बाद यह तय करने की बात कही गई है कि क्या 2TB data को online रखना ज़रूरी है या केवल daily/hourly summary ही चाहिए.
    • एक client case में 10TB से ज़्यादा data और प्रति सेकंड 1500 events process किए जा रहे हैं; detailed data को 2 दिनों तक online रखा जाता है और बाकी को summarize करके S3 में भेज दिया जाता है, जहाँ Athena SQL के ज़रिए query किया जा सकता है.
    • AWS RDS Multi-AZ का उपयोग automatic failover के लिए किया जा रहा है, और एक engineer हर महीने 5 घंटे से कम समय में पूरी व्यवस्था maintain कर रहा है.
    • PostgreSQL data को एक ही जगह रखने, सीखने, manage करने और scale करने के लिए एक single system देता है.
    • non-technical लोग भी Metabase या Preset जैसे systems में आसानी से charts बना सकते हैं.
    • PostgreSQL हर साल बेहतर हो रहा है, और ज़रूरत पड़ने पर PostgreSQL-compatible systems (Aurora, TimescaleDB, CitusDB आदि) के माध्यम से अतिरिक्त scaling भी संभव है.

  • event-driven architecture का सही उपयोग कब करना चाहिए

    • जब customer कोई खास action करता है और response की उम्मीद करता है, तो वह event-driven नहीं बल्कि request/response pattern होता है.
    • event-driven का मतलब उन स्थितियों से है जो अप्रत्याशित रूप से होती हैं. उदाहरण के लिए, GitHub पर code push करने से build trigger होना.

  • event sourcing पर संदेहपूर्ण अनुभव साझा करना

    • एक team ने event sourcing पर विचार किया, लेकिन स्पष्ट लाभ न दिखने और कुछ नया आज़माने के जोखिम की वजह से अंततः इसे न अपनाने का फैसला किया.
    • सीखने का मौका छूट जाने का कोई अफसोस नहीं है, और जहाँ ज़रूरत न हो वहाँ जटिल समस्याओं में न कूदना एक सकारात्मक बात मानी गई.

  • domain event modeling की उपयोगिता

    • domain event modeling, समस्या हल करने वाले domain experts के साथ संवाद में उपयोगी है.
    • लंबे समय तक state machine की audit trail देने वाली system लागू करनी हो, तो Temporal.io/durable functions जैसे tools का उपयोग करना बेहतर है.
    • ये tools अंदर ही अंदर event sourcing का उपयोग करते हैं और code लिखते समय deduplication तथा idempotency को ध्यान में रखने के लिए मजबूर करते हैं.

  • event sourcing के implementation पर सवाल

    • event stream से current state को प्रभावी ढंग से reconstruct करने और database में event stream को model करने के तरीके पर पर्याप्त विवरण नहीं है.

  • bottom-up बनाम top-down, custom बनाम general-purpose

    • top-down approach business domain से शुरू होती है और implementation को उपलब्ध technologies, tools और vendors के हिसाब से map करती है.
    • bottom-up approach उपलब्ध technologies, tools और vendors से शुरू होकर काम करने वाला solution जोड़ती है.
    • custom approach में DDD, CQRS/ES, Sagas, TBUI, GraphQL, algebraic data types आदि शामिल हैं.
    • general-purpose approach में RDBMS, CRUD, REST, ACID transactions, CDC, general-purpose admin UI, no-code/low-code, limited/general-purpose types आदि शामिल हैं.

  • event-based architecture के समर्थन और आलोचना

    • event-based architecture के समर्थन के बावजूद, संबंधित article अपनी बात स्पष्ट रूप से रखने में विफल रहता है.
    • data relationships और business behavior के बीच के अंतर पर ध्यान देने से operational relational data store से दूर जाने की बात अधिक स्पष्ट हो जाती है.

  • event sourcing और relationality की आवश्यकता

    • event sourcing के कई फ़ायदों के बावजूद, relationality की ज़रूरत बनी रहती है.
    • अगर relationality पूरी तरह application layer code में ही implied हो, तो यह स्वीकार्य नहीं है.
    • relationality को query करने या relational views को up-to-date रखने का कोई तरीका होना चाहिए.

  • relational data के समर्थन में

    • complexity से बचने और पारंपरिक relational data के साथ बने रहने का फैसला किया गया.

  • event-driven design पर नई समझ

    • हाल ही में event-driven design के बारे में पता चला, और AI-प्रभुत्व वाली दुनिया में optimal data structure पर विचार करते हुए इसी तरह के निष्कर्ष पर पहुँचा गया.
    • अगर event-driven design complexity को manage कर सके और data का वास्तविक उपयोग संभव बना सके, तो यह मूल्यवान हो सकता है.
    • आने वाले कुछ वर्षों में, जब AI हर business event का ज्ञान रखकर query करने में सक्षम होगा, event-driven design के आम होने की उम्मीद की गई है.