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

 (blog.redplanetlabs.com)
2 पॉइंट द्वारा GN⁺ 2024-01-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • backend complexity की वजह किसी खास product की खामी से ज्यादा यह है कि databases की लंबे समय से बनी हुई conceptual structure application design को लगातार constrain करती रही है
  • Database global mutable state की तरह behave करता है, और fixed data model, सीमित schema, normalization और denormalization के तनाव का बोझ developers पर डालता है
  • प्रस्तावित विकल्प event sourcing और materialized views को जोड़कर source data और indexed views को अलग करता है, और indexes को data model नहीं बल्कि durable data structures की तरह treat करता है
  • Red Planet Labs का Rama depots, ETL, PStates, query topologies के जरिए data ingestion, processing, indexing, queries के साथ deployment और monitoring को एक platform में जोड़ता है
  • Twitter scale पर Mastodon reimplementation के case में Rama 10k lines और 9 person-months में implement हुआ, जबकि comparison में Twitter consumer product में 1M lines और लगभग 200 person-years लगे बताए गए

डेटाबेस जटिलता की शुरुआत

  • समस्या का focus किसी खास database product के API, operational difficulties, या arbitrary limits पर नहीं, बल्कि आज तक कायम रही collective conceptual structure पर है
  • जब कोई बेहतर तरीका सामने आता है, तभी मौजूदा तरीके की समस्याएं साफ दिखती हैं; विकल्प के रूप में event sourcing और materialized views के combination को पेश किया गया है

Global mutable state के रूप में database

  • Programmers सीखते हैं कि global variables का इस्तेमाल minimum रखें, लेकिन database भी मूल रूप से global mutable state ही है
  • Database कुछ मायनों में सामान्य global variables से भी ज्यादा मुश्किल होता है
    • Interactions कई systems में फैली होती हैं, इसलिए state के बारे में reasoning कठिन हो जाती है
    • State durable होती है, इसलिए bug ठीक करने पर भी corrupted data अपने-आप recover नहीं होता
    • Corruption का exact scope समझना या उसे पूरी तरह correct करना कई बार मुश्किल होता है
    • Backup पर वापस जाना या backup के कुछ हिस्सों को merge करना optimal solution नहीं है
  • Event sourcing और materialized views इस्तेमाल करने पर source log से views दोबारा calculate किए जा सकते हैं, जिससे corrupted index state को ठीक करने की गुंजाइश बनती है

Fixed data model की सीमाएं

  • Databases key/value, document, relational, column-oriented, graph जैसे data models के इर्द-गिर्द design किए जाते हैं
  • एक single data model सभी use cases support नहीं कर पाता, इसलिए companies अक्सर कई databases साथ में इस्तेमाल करती हैं
  • Index के लिए ज्यादा general abstraction data model नहीं, बल्कि data structure है
    • Key/value: map
    • Document: map of maps
    • Relational: map of maps, secondary indexes अतिरिक्त map होते हैं
    • Column-oriented: map of sorted maps
  • Durable data structures disk पर store होते हैं, बहुत बड़े हो सकते हैं, और nested data structures भी express कर सकते हैं
  • Indexes को data structures के combination के रूप में specify करने से मौजूदा data models के अलावा और भी विविध index forms बनाए जा सकते हैं
  • Application domain model को database के हिसाब से मोड़ने के बजाय, अगर storage का shape domain model के हिसाब से किया जा सके, तो foundational complexity घटती है

Normalization और denormalization का तनाव

  • Relational database users आखिरकार normalization और denormalization के बीच choice का सामना करते हैं
  • Normalized storage सच का स्पष्ट source बनाता है और inconsistency की संभावना घटाता है, लेकिन joins बढ़ने से query cost बढ़ सकती है
  • Performance के लिए वही information कई तरीकों से store की जाए, तो bug होने पर data inconsistency पैदा हो सकती है
  • RDBMS architecture सच के source और fast queries के लिए index storage को उसी datastore में मिला देता है
  • समाधान एक ऐसा structure है जो दोनों roles को अलग करे
    • एक subsystem source of truth को represent करता है
    • दूसरा subsystem उस source से जितने चाहें index stores materialize करता है
    • अगर दूसरा system source data से indexes दोबारा calculate कर सकता है, तो inconsistencies correct की जा सकती हैं

सीमित schema और domain representation

  • Database में store किए जा सकने वाले values के types product के हिसाब से काफी अलग होते हैं
    • कुछ databases केवल byte array जैसे blob allow करते हैं
    • कुछ databases integers, floating point, strings, dates जैसे कई types allow करते हैं
  • Domain objects के अंदर की nested information को सीधे query या aggregate करने लायक first-class representation के रूप में store करना दुर्लभ है
  • Database implementation language और application language अलग होने से interoperability मुश्किल होती है, और Postgres के लिए protobuf extension जैसे extensions भी झंझटभरे और सीमित होते हैं
  • ORM domain representation और database representation को map करता है, लेकिन abstraction leak होकर समस्याएं पैदा कर सकती है
  • अगर data को ideal domain representation से अलग तरीके से index करना पड़े, तो adapter code चाहिए, और efficiently की जा सकने वाली queries भी सीमित हो सकती हैं

जटिल deployment और à la carte model

  • पूरा backend केवल database से नहीं बनता; database, processing systems, monitoring tools, schedulers जैसे कई tools साथ में चाहिए होते हैं
  • बड़े backend में दर्जनों tools को combine करना पड़ सकता है, और application update migration, code update, infrastructure changes के orchestration में बदल जाता है
  • Production readiness के लिए पर्याप्त telemetry चाहिए, लेकिन हर tool का collection method अलग होता है, इसलिए उन्हें एक monitoring dashboard में लाना भी अलग engineering task बन जाता है
  • आज का dominant development approach हर architecture part के लिए best tool चुनकर जोड़ने वाले à la carte model के करीब है
  • अलग-अलग design किए गए tools को साथ चलाने का काम अपने-आप में बड़ा होता है, और fixed data model व limited schema की वजह से tools को application के अनुकूल बनाने के बजाय application को tools के अनुकूल बनाना पड़ता है
  • Backend composition के लिए कोई cohesive model नहीं था, इसलिए à la carte model जम गया; cohesive model में abstraction, automation और reuse की गुंजाइश बढ़ती है

Backend को देखने का सरल model

  • Backend के मुख्य functions हैं नया data receive करना और उस data पर पूछे गए सवालों का जवाब देना
  • सबसे general query को backend द्वारा receive किए गए पूरे data पर function चलाने के रूप में express किया जा सकता है
    • query = function(all data)
  • असल दुनिया में dataset 10PB हो सकता है और query response milliseconds में चाहिए हो सकता है, इसलिए practical system में indexes जरूरी हैं
  • Indexes जोड़ने पर model को ऐसे express किया जाता है
    • indexes = function(data)
    • query = function(indexes)
  • मौजूदा backends इस model के components को कई narrow tools में बांटकर implement करते हैं
    • RDBMS backend data और indexes के लिए RDBMS इस्तेमाल करता है, और extra indexing के लिए ElasticSearch जैसा अलग database इस्तेमाल कर सकता है
    • Computation अक्सर API server handlers या queue/worker based background jobs में की जाती है
    • बड़े backend Cassandra, MongoDB, Neo4j, Kafka, Hadoop, Storm, Kafka Streams जैसे tools combine कर सकते हैं
  • निष्कर्ष यह है कि अगर कोई tool सभी components को integrated और general-purpose तरीके से implement कर सके, तो ऊपर बताई गई complexity से बचा जा सकता है

Rama की बनावट और Mastodon case

  • Rama इन principles के आधार पर design किया गया backend development platform है
  • Red Planet Labs ने 15 अगस्त को Rama को “the 100x development platform” tagline के साथ announce किया
  • Cost reduction example के रूप में Mastodon को Twitter scale पर reimplement करने का काम पेश किया गया
    • 100M bots प्रति सेकंड 3,500 बार post करते हैं
    • Average fanout 403 है
    • Twitter के equivalent consumer product में 1M lines और लगभग 200 person-years लगे, ऐसा comparison दिया गया
    • Rama implementation में 10k lines और 9 person-months लगे
    • Implementation open-source है और इसे complete, high-performance, production-ready बताया गया है
  • Comparison में बताया गया कि Twitter ने scale हासिल करने के लिए social graph database, in-memory timeline database जैसे specialized databases खुद बनाए, और उसका deployment इतना complex था कि सिर्फ Puppet configuration ही 1M lines से ज्यादा था
  • Rama based implementation ने हर subproblem के लिए नई specialized infrastructure बनाने के बजाय Rama के primitives को combine करके similar performance और scalability problems solve कीं
  • Mastodon implementation के performance numbers Twitter के figures के बराबर या उनसे बेहतर बताए गए हैं

Rama का programming model

  • Rama के concepts ऊपर दिए गए backend model से सीधे match करते हैं
    • Depots: arbitrary data रखने वाले distributed logs, जो data के equivalent हैं
    • PStates: partitioned state का short form, और indexes के equivalent हैं
    • ETLs: function(data) के equivalent हैं
    • Queries: function(indexes) के equivalent हैं
  • PStates को durable data structures के arbitrary combinations के रूप में जितनी जरूरत हो उतना बनाया जा सकता है
  • ETL और query को Turing-complete dataflow API से express किया जाता है, और computation को distributed तरीके से execute किया जा सकता है
  • Rama documentation में Java API tutorial देता है, और Clojure API भी है

Rama database complexity कैसे घटाता है

  • Rama के PStates database जैसी भूमिका निभाते हैं, लेकिन उन्हें केवल उस ETL topology में इस्तेमाल किया जा सकता है जो उस PState का owner है
    • सभी writes उसी ETL code में होती हैं, इसलिए state reasoning आसान हो जाती है
    • PStates event sourcing log के ऊपर materialized views की तरह काम करते हैं
    • Depot data source of truth है, इसलिए PState दोबारा calculate किया जा सकता है
  • Data model constraints को PStates को data structures के रूप में specify करके handle किया जाता है
    • Mastodon implementation सिर्फ profiles, statuses, timelines के लिए भी 33 PStates इस्तेमाल करता है
    • कोई PState 10 use cases handle करता है, तो कोई PState सिर्फ एक use case support करता है
  • PStates durable, partitioned, incrementally replicated properties रखते हैं
    • Incremental replication का मतलब है कि leader partition fail होने पर takeover के लिए दूसरा partition ready रहता है
    • Current leader में जो दिखता है, वह future leader में भी दिखेगा, इसकी guarantee होती है
  • Normalization और denormalization की problem depots और PStates को explicitly अलग करके handle की जाती है
  • Limited schema की problem domain representation को as-is इस्तेमाल करके कम की जाती है
    • hash map, list जैसे general data structures
    • Protocol Buffers
    • nested object definitions
    • जिन types को Rama नहीं जानता, उन्हें custom serializer register करके handle किया जाता है

Deployment, integration, monitoring

  • Rama applications को modules कहा जाता है, और module में कई depots, ETLs, PStates, query topologies हो सकते हैं
  • Rama module deployment, update और scaling के लिए built-in mechanisms देता है, और कहा गया है कि इनमें से हर काम terminal के one-liner से किया जाता है
  • Rama “all or nothing” tool नहीं है; इसे दूसरे systems के साथ integrate करना आसान बनाया गया है, ताकि मौजूदा architecture में gradual adoption हो सके
  • Integrated platform होने की वजह से यह अपनी monitoring भी करता है
    • Monitoring data collection
    • Processing
    • Indexing
    • Visualization
  • cluster UI telemetry module performance समझने, problems detect और diagnose करने, और scaling का समय तय करने में इस्तेमाल होती है

Learning और adoption path

  • Rama को और सीखने के लिए ये resources दिए गए हैं
  • Production में नई features बनाने, existing systems expand करने, या infrastructure simplify करने के लिए Rama इस्तेमाल करना चाहें, तो private beta के लिए apply कर सकते हैं
  • कहा गया है कि private beta users को Rama सीखने के साथ-साथ code writing, optimization और testing में भी support दिया जाएगा

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

1 टिप्पणियां

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

  • “जैसा कि बाद में समझाऊंगा, बेहतर तरीका event sourcing और materialized views है” — तो आखिर समाधान complexity बढ़ाना ही है? जाहिर है, ऐसा ही होगा

    • सही तरीके से किया जाए तो backend architecture उल्टे काफी सरल हो जाता है। छोटे scale के apps भी अक्सर Postgres और ElasticSearch जैसे कई databases इस्तेमाल करते हैं, और background jobs के लिए queue और workers साथ रखते हैं
      हमारा बनाया हुआ Twitter-scale Mastodon implementation इसका सीधा उदाहरण है। वही features scale पर बनाने के लिए Twitter को जितना code लिखना पड़ता, उससे सचमुच 100 गुना कम, और आधिकारिक Mastodon implementation से भी 40% से ज्यादा कम code है। ऐसा इसलिए नहीं कि उन्हीं tools के साथ दूसरी बार बनाने पर हमने बेहतर design किया, बल्कि इसलिए कि इसे मूल रूप से बेहतर abstraction पर बनाया गया था
    • complexity गायब नहीं होती, बस कहीं और चली जाती है। कई कामों में इस समाधान का trade-off खराब हो सकता है
      हालांकि एक निश्चित scale से आगे सब कुछ data engineering problem बन जाता है, और पूरे system के संदर्भ में यह तरीका अपेक्षाकृत सरल समाधान भी बन जाता है। “बस mySQL/SQLite/Postgres इस्तेमाल करो” वाली सलाह तब तक बेहतरीन है, जब तक वह valid न रहने वाला क्षण नहीं आ जाता
    • complexity और बढ़ेगी? लेखक ने तो इसे बहुत सरल बना दिया है। बस उनका product Rama इस्तेमाल कर लो
    • जिन सभी कंपनियों में मैंने काम किया, वहां event sourcing + materialized views ने भारी भ्रम, ज्यादा bugs और लंबे outages पैदा किए। MySQL या PostGres, या Redis/DynamoDB जैसे सरल समाधान, सभी बेहतर चले
      मुझे सच में लगता है कि अगर Martin Fowler का मूल event sourcing लेख कभी लिखा ही न गया होता, तो सबके लिए बेहतर होता। 99% मामलों में मुझे यह खराब idea लगता है
    • अगर program domain को मूलभूत complexity X चाहिए, तो वह complexity किसी न किसी तरह implement करनी ही होगी। आप इसे पहले से लिखे और production में proven दूसरों के code पर छोड़ सकते हैं, या खुद फिर से बना सकते हैं—दूसरा रास्ता ज्यादा समय ले सकता है और नतीजा भी खराब हो सकता है। कोई free lunch नहीं है

  • पता नहीं मैंने कुछ miss किया या नहीं, लेकिन लेख में concurrency, isolation, constraints जैसी concepts पूरी तरह छूटी हुई लगती हैं। और “query topology” declarative भी नहीं लगती और query planning/optimization की जिम्मेदारी लेखक पर डालती प्रतीत होती है—क्या इसे सच में बेहतर developer experience माना जा रहा है?

    • ये बातें documentation में काफी detail में cover की गई हैं। यह लेख backend development की complexity और Rama इससे कैसे निपटता है, इस बारे में है; Rama के हर पहलू को पूरी तरह समझाने वाला लेख नहीं है। सब कुछ समझाया जाए तो बहुत लंबा हो जाएगा। Rama में और गहराई से देखेंगे तो properties और guarantees बहुत मजबूत दिखेंगी
      और हां, Rama का query approach कहीं बेहतर तरीका है। जटिल query planner की जरूरत आमतौर पर data indexing के तरीके की सीमाओं से आती है, खासकर normalization और denormalization के बीच के तनाव से। Rama में query के लिए जरूरी shape में पहले से तैयार कई views को मजबूती से materialize करना आसान है
      Rama concepts को सहज तरीके से introduce करने वाला tutorial यहां है: https://redplanetlabs.com/docs/~/tutorial1.html

  • “कोई भी single data model सभी use cases को support नहीं कर सकता” इस बात पर, सैद्धांतिक रूप से ऐसा कोई domain या finite domains का समूह नहीं है जिसे चीज़ों के tuples और relationships से ठीक-ठीक model न किया जा सके
    व्यावहारिक रूप से किसी खास database/schema का scope आम तौर पर एक business या problem domain तक सीमित होता है, लेकिन अगर types गलत तरीके से overlap न करें तो यह भी कोई बड़ी समस्या नहीं है। नामों का बस ध्यान रखें तो web retailer और insurance company को एक ही schema में रखना भी पर्याप्त रूप से काम कर सकता है
    हर चीज़ को ठीक एक ही database में रखना एक superpower है। मैं इस पर इतना ज़ोर इसलिए देता हूँ क्योंकि इससे कई data stores में distributed transactions से बचा जा सकता है। जब पूरा business एक transaction system के अंदर होता है, तो semantics नाटकीय रूप से सरल हो जाते हैं

    • “हर चीज़ को एक ही database में रखना superpower है” वाली बात से खास तौर पर सहमत हूँ
      जब लोग सच में data का इस्तेमाल शुरू करते हैं, तो 1 million dollar का बड़ा DB server सस्ते databases की redundant array से कहीं ज्यादा सस्ता पड़ता है। Developers हों, analysts हों या management, सभी का समय बचता है; शायद कुछ DBAs अपवाद हो सकते हैं
    • बड़े databases कोई नई चीज़ नहीं हैं। अगर बात बस इतनी ही होती, तो पिछले 40 सालों से लोग लगातार यही करते रहते। लेकिन यह हमेशा काम नहीं करता था, और कभी-कभी तो अक्सर बहुत खराब साबित होता था
      भले ही सैद्धांतिक रूप से बात सिर्फ इतनी ही हो, एक और लगातार समस्या implementation है। आजकल ज्यादातर developers ठीक से नहीं समझते कि databases कैसे काम करते हैं और उन्हें कैसे इस्तेमाल करना चाहिए, इसलिए वे उनका बहुत खराब इस्तेमाल करते हैं। इसी वजह से इस सच्चाई से बचने के लिए NoSQL जैसे नए databases बनाए गए, ताकि कम दिमाग लगाना पड़े और बस glue code ज्यादा लिखना पड़े। वह भी भयानक नतीजा निकला
      जल्द ही रुझान फिर बदलेगा और “बस एक बड़ा database” फिर fashion में नहीं रहेगा, और “simplicity” का कोई और paradigm आ जाएगा। Microservices के समय की तरह, “एक बड़ा database” की जगह “बहुत सारे छोटे databases” को सरल माना जा सकता है। अगर इतिहास को नहीं समझेंगे तो उसे दोहराना ही पड़ेगा
    • यह कहना कि किसी use case को tuples और relationships से model किया जा सकता है, इसका मतलब यह नहीं कि database उस use case की performance requirements पूरी कर सकता है। अगर performance requirements पूरी नहीं होतीं, तो वह use case supported नहीं माना जाएगा
      यह general programming जैसा ही है, जहाँ कोई एक data structure या data structures का combination सभी use cases को support नहीं कर सकता। कभी map चाहिए, कभी list, set, combination, या फिर कुछ पूरी तरह अलग
    • “हर चीज़ को एक ही database में रखना superpower है” से सहमत हूँ। पिछली company में हर app के लिए अलग DB वाला cargo-cult microservices setup था, जो बिना किसी business benefit के बेवजह complex और महंगा हो गया था। Résumé भरने के लिए जरूर फायदा रहा होगा। जब तक मजबूरी न हो, चीज़ों को complex नहीं बनाना चाहिए
    • यह सपने जैसा और सचमुच खूबसूरत विचार है, लेकिन असल में काम नहीं करता। क्या कोई है जिसे इसमें सफलता मिली हो? चरम रूप से देखें तो इसका मतलब होगा कि पूरी दुनिया के लिए एक unified database और एक user permissions system चाहिए
      स्वाभाविक है कि data structures अलग-अलग होते हैं, performance भी चाहिए होती है, और यह इतना महत्वपूर्ण bottleneck बन जाता है कि आम लोग इसे छू नहीं सकते और हर change को बेहद सुरक्षित होना पड़ता है। Security भी है। अगर कोई development bug section से HR या executives-only finance section में जाने का तरीका ढूँढ ले तो क्या होगा? जिसने भी general-purpose ERM system implement किया है, वह जानता होगा कि unified system कितना कठिन और पीड़ादायक होता है
      हालांकि यह extreme case है। इस ideal को pursue करते हुए लोग कहाँ तक पहुँचे और उन्होंने कैसे किया, यह जानना चाहूँगा। मैंने कभी ऐसा business नहीं देखा जो एक ही system पर चलता हो। Personal knowledge management system का क्या? क्या उसमें सब कुछ fit हो जाता है? क्या अब भी quick work के लिए spreadsheets और free-form चीज़ों के लिए text files इस्तेमाल नहीं करते?

  • यह buzzwords की सूची जैसा दिखता है। दुनिया की सबसे बड़ी companies में से एक में कई साल databases के साथ काम किया है, लेकिन topology शब्द कभी नहीं सुना
    इससे अगर कुछ समय बचे भी, तो Java और यह framework सीखने में निकल जाएगा। Database में अपने आप में कोई समस्या नहीं है

    • Twitter scale पर समान functionality बनाते समय Twitter द्वारा लिखे गए code से 100 गुना कम code में बना production-ready Mastodon implementation मौजूद है, इसलिए “buzzwords की सूची” वाली टिप्पणी से सहमत होना मुश्किल है: https://github.com/redplanetlabs/twitter-scale-mastodon
    • मुझे यह ऐसे विज्ञापन का एक उदाहरण लगता है
      मैंने यहाँ text table बनाने की कोशिश की थी, लेकिन page display पूरी तरह बिगड़ गया, इसलिए screenshot के रूप में पोस्ट कर रहा हूँ: https://imgur.com/a/XtwSkyx

  • Rama को पाँच साल के बच्चे को समझाने जैसा बताना हो तो क्या कहेंगे? docs भी confusing लगे: https://redplanetlabs.com/docs/~/index.html
    “paradigm shift” या “platform” जैसे buzzwords हटाकर बताया जाए तो अच्छा होगा। अगर diagram चाहिए, तो मैं ऐसा लेख पढ़ना चाहूँगा जो और साफ़ तरीके से समझाए

    • यह एक backend development platform है जो किसी भी scale पर application की data ingestion, processing, indexing और query needs को handle कर सकता है। backend बनाने के लिए कई databases, processing systems, queues और schedulers को मिलाने के बजाय, Rama नाम के एक single platform के अंदर सब किया जा सकता है
      Rama cluster के रूप में चलता है, और कई applications उस cluster पर “modules” के रूप में deploy होते हैं। deep और detailed telemetry भी built-in है
      Rama का programming model event sourcing और materialized views है। Rama application बनाते समय आप जितने चाहें उतने indexes, जिस shape में चाहें, multiple persistent data structures के combinations के रूप में materialize करते हैं। indexes distributed dataflow API से materialize होते हैं
      Rama मौजूदा चीज़ों से इतना अलग है कि high-level explanation में मैं इतना ही बता सकता हूँ। basics सीखने के लिए सबसे अच्छा resource rama-demo-gallery है, जिसमें कई use cases पर Rama लागू करने के छोटे, complete और detailed comments वाले examples हैं। सभी scalable और fault-tolerant हैं: https://github.com/redplanetlabs/rama-demo-gallery
    • मेरी समझ में यह Kappa architecture, यानी event sourcing का एक variant है
      इसमें “Depot” नाम का append-only event log होता है, और उसके ऊपर arbitrary views बनाए जाते हैं जिन्हें “P-States” कहा जाता है। Rama software इन views के low-latency updates का वादा करता है। इसके ऊपर बनी applications views को query करती हैं और Depot में नए events/commands submit करती हैं
    • यह event sourcing database जैसा दिखता है। मूल रूप से direct writes के बजाय आप messages लिखते हैं, और उन messages के आधार पर update होने वाली read-only tables बना सकते हैं। कुछ domains में आज भी ऐसा करते हैं, लेकिन यह traditional database की तुलना में निश्चित रूप से ज़्यादा complex है
    • यह NoSQL की एक और कोशिश जैसा लगता है। “लेकिन इस बार अलग है!”

  • मैंने 1–10TB scale के live event datasets पर flexible materialized view engine बनाने का एक साल का project किया था, और दूसरे project पर जाने से पहले हमारा architecture भी मोटे तौर पर code को वहाँ भेजने के idea पर converge कर रहा था जहाँ index है
    Rama मुझे काफ़ी आकर्षक लगता है, लेकिन पूरी तरह irrational वजह से शायद JVM के कारण इसे adopt नहीं करूँगा। मुझे बस Java/JVM पसंद नहीं है। अच्छा होगा अगर यह architecture किसी दूसरे environment में port हो जाए

  • हमारे workplace में read model और write model अलग हैं। write model, यानी source of truth, invariants/constraints तक वाला traditional relational domain model है, और ORM से परिचित ज़्यादातर developers के लिए इसे reason करना मुश्किल नहीं लगता
    लगभग हर command एक event भी बनाता है और उसे shared domain event queue में publish करता है। read model में events consume करने वाले workers अपनी ज़रूरत के हिसाब से views बनाते हैं, और उन्हें फिर से बनाया भी जा सकता है। उदाहरण के लिए user management service source of truth है, और दूसरी services complex UI दिखाने के लिए view services की तरह user service और दूसरी services के events के आधार पर अपना read model/index बनाती हैं। इसके बिना भारी-भरकम joins या slow inter-service API calls की ज़रूरत पड़ती
    तकनीकी रूप से event replay संभव है। असल में platform code bug की वजह से हमने पिछले 3 साल के सारे events replay भी किए थे। लेकिन सच में इसकी ज़रूरत शायद ही कभी पड़ी। bugs की वजह से view दोबारा बनाना पड़ सकता है, लेकिन आम तौर पर इसे special scripts या SQL migrations जैसे ad-hoc program तरीके से handle करते हैं। हमारे architecture को ठीक-ठीक क्या कहा जाए, मुझे नहीं पता, और मैंने किसी को इसे “event sourcing” कहते नहीं सुना
    आखिरकार यह पुराना MySQL + RabbitMQ और थोड़ा glue code ही है। लेकिन इसे सही तरीके से करना transaction outbox, at-least-once delivery guarantee, eventual consistency, सही event processing order बनाए रखना, event data batching, DB management, event handlers के मर जाने पर handling आदि के कारण बिल्कुल मामूली नहीं है। जब हमारे पास पहले से production-proven, language-independent setup है और PHP व Go producers/consumers दोनों मौजूद हैं, तो Rama के बिना हम क्या miss कर रहे हैं, और ऊपर की समस्याओं को Rama कैसे solve करता है—यह जानना चाहूँगा। Rama Java side के लिए ज़्यादा tuned लगता है

    • लगता है आपने RDBMS का उपयोग करते हुए complexity manage करने का शानदार तरीका engineer किया है। Rama उसके ऊपर कुछ चीज़ें देता है
      Rama के indexes कहीं ज़्यादा flexible हैं। उदाहरण के लिए अगर 100 million elements वाला nested set चाहिए तो यह trivial है। user ID → follower ID set जैसा social graph index एक आम example है। granularity के हिसाब से तोड़ा गया time-series index, यानी entity → granularity → time bucket → statistics भी उतना ही आसान है
      Rama में store होने वाले data types पर कोई restriction नहीं है। Rama queries बहुत powerful हैं, और कुछ या पूरे indexes पर real-time on-demand distributed queries आसान हैं। application भर में deep और detailed telemetry भी built-in है, इसलिए उसे अलग से बनाने या manage करने की ज़रूरत नहीं
      deployment भी built-in है। आपके मौजूदा तरीके में application update worker code, schema migrations जैसे कई systems तक फैल सकता है, और खासकर अगर zero-downtime चाहिए तो यह काफ़ी कठिन engineering task बन जाता है। Rama computation और storage को end-to-end integrate करता है, इसलिए application release, update और scaling सब terminal की एक line से हो जाता है
      Rama कहीं ज़्यादा scalable है। यह features के perspective से Rama है, और Rama में code लिखते समय impedance mismatch न होना कितना बड़ा फर्क डालता है, इसे शब्दों में बताना मुश्किल है—इसे इस्तेमाल करके ही समझा जा सकता है। Rama JVM के लिए है, इसलिए किसी भी JVM language से इस्तेमाल किया जा सकता है, और अभी Java और Clojure APIs देता है
    • “customer address update” जैसी command क्या SQL run करने के बाद RDBMS trigger के ज़रिए RabbitMQ को event भेजती है, या ORM SQL भेजता है और RabbitMQ पर publish करता है?
      events कहाँ और किस format में store होते हैं? और detail में सुनना चाहूँगा
      अभी जो missing है, वह शायद पूरे ecosystem के लिए एक शानदार नाम है

  • बदलाव के समय डेटा को materialize करने से फायदा हो सकता है, जब product को एक काम बहुत तेज़ी से करना हो। लेकिन जैसे ही ऐसी complex transactions आती हैं जिन्हें atomic writes के साथ साथ में update करना होता है, या जैसे ही आप कोई नई feature जोड़ना चाहते हैं जिसमें डेटा को अलग तरीके से organize करना पड़े, तो मुश्किल खड़ी हो जाती है
    application बनाने वाले हिस्से में “बस एक index लगा दो” कहकर बात को हल्के में टाल देना भी बहुत असंतोषजनक है। index global state है, बस उसे एक layer नीचे ले जाया गया है

    • क्योंकि वह “बस एक layer नीचे ले जाया गया है”, निर्णायक बात यह है कि अब उसे सीधे manage करने की ज़रूरत नहीं रहती। आपको सिर्फ system को यह बताना है कि क्या index करना है। वह state या data नहीं, code है

  • यह document पढ़कर भी साफ़ नहीं होता कि target reader कौन है और यह क्या solve करना चाहता है: https://redplanetlabs.com/docs/~/why-use-rama.html#gsc.tab=0
    कोई real example लेकर, उसे RAMA से करने पर कितना आसान और efficient होता है, ऐसा transform करके दिखाना मददगार होगा

    • हमने कई examples public किए हैं
      पहला Twitter-scale Mastodon implementation है, जिसमें उसी चीज़ को scale पर बनाने के लिए Twitter द्वारा लिखे गए code की तुलना में 100 गुना कम code है। यह सिर्फ consumer product के आधार पर है। non-scalable Mastodon official implementation की तुलना में भी इसमें 40% से ज़्यादा कम code है: https://github.com/redplanetlabs/twitter-scale-mastodon
      rama-demo-gallery repository में भी Rama को बहुत अलग-अलग use cases पर लागू करने वाले छोटे, standalone और detail में commented examples हैं। इनमें user profile management, time-series analytics, और atomic व fault-tolerant bank transfers शामिल हैं: https://github.com/redplanetlabs/rama-demo-gallery

  • अगर आप सच में 4 करोड़ daily users वाली website नहीं चला रहे हैं, तो “Twitter-scale Mastodon client” से यह साबित हो गया है, ऐसा दावा करना सही नहीं लगता। real environment, उससे जुड़े code और infrastructure changes, असली users, network usage वगैरह को simulate करना संभव नहीं है