डेटाबेस और उनकी जटिलता अब क्यों अनावश्यक है

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

डेटाबेस की समस्याएँ और उनकी जटिलता अब क्यों अनावश्यक है

  • डेटाबेस एक global mutable state हैं, जिससे कोड जटिल हो जाता है और उसे समझना कठिन हो जाता है.
  • डेटा मॉडल सीमित होते हैं और सभी use cases को support नहीं कर सकते, इसलिए कई डेटाबेस का उपयोग करना पड़ता है.
  • normalization बनाम denormalization की समस्या डेटा consistency और performance के बीच तनाव पैदा करती है.
  • सीमित schema डोमेन अभिव्यक्ति को डेटाबेस के अनुरूप ढालने के लिए जटिलता पैदा करते हैं.
  • जटिल deployment विभिन्न tools के संयोजन और integration के कारण लागत और जटिलता बढ़ा देता है.

application backend बनाने के लिए एक सुसंगत मॉडल

  • backend का मूल कार्य नया डेटा प्राप्त करना और उस डेटा के बारे में प्रश्नों का उत्तर देना है.
  • आदर्श backend design को वास्तविक constraints को पूरा करते हुए यथासंभव आदर्श के करीब होना चाहिए.

Rama

  • Rama एक backend development platform है, जो Mastodon को फिर से implement करके Twitter-स्तर की सेवा प्रदान करता है.
  • Rama डेटा, index, ETL, query आदि backend के सभी तत्वों को एक सामान्य तरीके से implement करता है.
  • Rama जटिल deployment को सरल बनाता है और monitoring को एकीकृत करके development और maintenance लागत को काफी कम करता है.

GN⁺ की राय

  • डेटाबेस की global mutable state की समस्या कोड की जटिलता और त्रुटि की संभावना बढ़ाती है, और यह वह समस्या है जिसका डेवलपर्स अक्सर सामना करते हैं.
  • Rama पारंपरिक डेटाबेस की सीमाओं को पार करते हुए backend development की जटिलता कम करने का एक नया दृष्टिकोण प्रस्तुत करता है.
  • यह लेख डेटाबेस और backend systems की जटिलता कम करना चाहने वाले डेवलपर्स के लिए रोचक और उपयोगी जानकारी प्रदान करता है.

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

1 टिप्पणियां

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

  • आपको एक ऐसा subsystem इस्तेमाल करना चाहिए जो source of truth को दर्शाए, और दूसरा subsystem जो उस source से निकले कई index stores को implement करे। यह event sourcing और materialized views का संयोजन है।

    • event sourcing और materialized views: source of truth को दर्शाने वाले सिस्टम और उस पर आधारित index stores को अलग करके मैनेज करना ही समाधान है।

  • हम read model और write model को अलग करते हैं: write model ("source of truth") पारंपरिक relational domain model से बना होता है, और लगभग हर command ऐसे events बनाती है जो shared domain event queue में publish किए जाते हैं। read model उन workers से बनता है जो events consume करके views बनाते हैं।

    • read/write model separation: write model relational domain model से बना होता है, और commands events बनाकर उन्हें domain event queue में publish करती हैं। read model events को consume करके views बनाता है।

  • data change होने पर materializing तब फ़ायदा दे सकता है जब product को एक काम बहुत तेज़ी से करना हो। लेकिन जब आपको complex transactions चाहिए हों या अलग तरह से संगठित data की ज़रूरत वाली नई feature जोड़नी हो, तब समस्या आती है।

    • data materializing की सीमाएँ: किसी एक काम के लिए optimize किए गए मामलों में यह उपयोगी है, लेकिन complex transactions या नई data structures की ज़रूरत वाली features जोड़ते समय समस्याएँ आ सकती हैं।

  • यह दावा करना कि यह "Twitter-scale Mastodon client" से साबित हो गया है, वास्तव में तब तक संभव नहीं है जब तक आप सच में 4 करोड़ daily users वाली website नहीं चला रहे हों।

    • scale का महत्व: वास्तविक बड़े user environment को simulate करना असंभव है, इसलिए ऐसा दावा करना मुश्किल है।

  • बेहतर approach event sourcing और materialized views का संयोजन है।

    • event sourcing और materialized views का संयोजन: यह complexity बढ़ाता है, लेकिन इसे बेहतर approach के रूप में पेश किया गया है।

  • कोई एक data model सभी use cases को support नहीं कर सकता।

    • data model की विविधता: एक ही data model से सभी use cases को support करना असंभव है।

  • मुझे databases से कोई शिकायत नहीं है।

    • database की वैधता: databases से कोई शिकायत नहीं है; वे अब भी उपयोगी tools हैं।

  • क्या concurrency, isolation, constraints जैसी अवधारणाएँ गायब हैं? क्या "query topology" सच में developer environment के लिए बेहतर है?

    • query topology पर सवाल: concurrency, isolation, constraints जैसी महत्वपूर्ण अवधारणाएँ गायब हैं, और query topology के developer environment में बेहतर होने के दावे पर सवाल उठाया गया है।

  • Rama के बारे में ELI5 चाहिए। docs उलझाऊ हैं, और "paradigm shift" या "platform" जैसे buzzwords मत इस्तेमाल करें।

    • Rama के लिए आसान व्याख्या का अनुरोध: Rama के बारे में सरल, स्पष्ट explanation माँगी गई है और buzzwords से बचने को कहा गया है।

  • event sourcing (+ materialized views और indexes) का मतलब RDBMS को फेंक देना नहीं है। आप दोनों को साथ में इस्तेमाल कर सकते हैं।

    • event sourcing और RDBMS का सह-अस्तित्व: event sourcing और materialized views को RDBMS के साथ इस्तेमाल किया जा सकता है; दोनों एक-दूसरे के विरोधी नहीं हैं।

पृष्ठभूमि ज्ञान:

  • इवेंट सोर्सिंग (Event Sourcing): सिस्टम के state changes को events के रूप में रिकॉर्ड करने वाला design pattern, जिससे उन्हें replay करके सिस्टम का state फिर से बनाया जा सकता है.
  • मटेरियलाइज़्ड व्यूज़ (Materialized Views): database query results को physically store करके data read performance बेहतर करने की तकनीक.
  • RDBMS(Relational Database Management System): relational databases को manage करने वाला system.