डेटा-केंद्रित डिज़ाइन (2018)
(dataorienteddesign.com)- Data-Oriented Design का ऑनलाइन संस्करण उन पाठकों के लिए सार्वजनिक रूप से उपलब्ध सामग्री है जो डेटा-केंद्रित डिज़ाइन सीखना चाहते हैं, ताकि वे मुख्य विषयवस्तु को मुफ्त में देख सकें
- पूरी किताब के कुछ गैर-मुख्य अध्याय हटा दिए गए हैं, लेकिन इसे सीखने के लिए आवश्यक ज़रूरी सामग्री पर केंद्रित रखा गया है
- यह दस्तावेज़ LaTeX से HTML में स्वतः परिवर्तित किया गया है, इसलिए इसमें फ़ॉर्मैटिंग त्रुटियाँ, टूटी हुई इमेजें, और टूटे हुए source code listings हो सकते हैं
- टूटे हुए source code listings के लिए रेफ़रेंस कोड अलग GitHub repository में देखा जा सकता है
- पेपरबुक खरीदना बेहतर फ़ॉर्मैट में पढ़ने का एक तरीका है, और उन पाठकों के लिए ऑनलाइन संस्करण को बनाए रखने में भी मदद करता है जो इसे खरीद नहीं सकते
ऑनलाइन संस्करण की प्रकृति
- Data-Oriented Design डेटा-केंद्रित डिज़ाइन पर एक मुफ्त ऑनलाइन संक्षिप्त संस्करण के रूप में उपलब्ध है
- कुछ गैर-मुख्य अध्याय हटाए गए हैं, लेकिन सीखने की सामग्री के लिए ज़रूरी मुख्य प्रवाह शामिल है
- यह उन पाठकों के लिए उपयुक्त है जो डेटा को केंद्र में रखकर डिज़ाइन को देखने का दृष्टिकोण सीखना चाहते हैं
दस्तावेज़ रूपांतरण की गुणवत्ता और कोड संदर्भ
- ऑनलाइन दस्तावेज़ स्वतः जनरेट किया गया है, इसलिए कुछ फ़ॉर्मैटिंग अस्वाभाविक लग सकती है
- LaTeX से HTML में बदलने वाला टूल पूरी तरह परिपूर्ण नहीं है, इसलिए इमेजें या source code listings टूट सकते हैं
- यदि source code listings टूटे हों, तो संदर्भित कोड GitHub पर मिल सकता है
पेपरबुक और फ़ीडबैक
- पेपरबुक को ऑनलाइन संस्करण की तुलना में बेहतर फ़ॉर्मैट में पढ़ा जा सकता है
- पेपरबुक खरीदना उन पाठकों के लिए ऑनलाइन संस्करण को जारी रखने में मदद करता है जो खरीदने में सक्षम नहीं हैं
- फ़ीडबैक support@dataorienteddesign.com पर भेजा जा सकता है
1 टिप्पणियां
Hacker News की राय
high-performance और composable code लिखने के लिए मुझे मिली सबसे बेहतरीन सलाहों में से एक थी: “array of structs नहीं, struct of arrays को संभालो”, और इस लेख में भी उसकी गूंज काफ़ी महसूस होती है
बाद में समझ आया कि entity-component architecture सिर्फ़ गेम्स में ही नहीं, बल्कि business applications में भी अच्छी तरह फिट बैठती है
लेकिन कई enterprise developers रिकॉर्ड-सहेजने वाले CRUD मॉडल में इतने अभ्यस्त होते हैं कि row की बजाय column के हिसाब से सोचना उनके लिए मुश्किल होता है, और
publishedboolean field कोtrueकरने के बजाय entity ID कोpublishedtable में डालने का विचार उन्हें अक्सर स्वाभाविक नहीं लगताफिर भी, जब एक बार समझ आ जाता है कि यह तरीका कितनी आसानी से polymorphic रूप में फैल सकता है, तो मन करता है कि हर डेटा पर यही approach लागू करें। तब component data को cross-use करने के नए मौके बनते हैं, और यह सवाल उठने लगता है कि network interface की जन्मतिथि क्यों है, invoice पर IPv6 address क्यों जुड़ा है, बिल्ली DHCP pool में कैसे आ गई, limegreen क्यों delete हो गया, और Tuesday को 5 डॉलर वाली संरचना आखिर allowed क्यों है — और मज़े का आधा हिस्सा यही है
मैं इस दावे से सहमत नहीं हूँ कि यह तरीका object-oriented programming के साथ पूरी तरह असंगत है। मैंने Ruby के Active Record में भी यह approach इस्तेमाल की है, और वहाँ भी यह अच्छे से चला, जहाँ आमतौर पर “high-performance” जैसा शब्द आसानी से नहीं जोड़ा जाता। Ruby का object system C++/Java की तुलना में Smalltalk के ज़्यादा क़रीब है, इसलिए वह inheritance से ज़्यादा composition को मज़बूती से पसंद करता है, और इसी वजह से यह वहाँ खास तौर पर अच्छी तरह फिट बैठा
object-oriented languages में आम तौर पर user, blog post, financial transaction जैसी किसी एक “सोचने लायक इकाई” पर ध्यान दिया जाता है, उसे बाकी से अलग करके implement किया जाता है, फिर data को छिपाकर यह सोचा जाता है कि system के दूसरे हिस्सों के लिए कौन-से methods expose किए जाएँ। Encapsulation की धारणा बहुत मज़बूत होती है
data-oriented design में अलग-अलग domains का data accessible होना और subsystems का अपने काम के लिए ज़रूरी चीज़ें चुनकर इस्तेमाल करना ज़्यादा आम है। Java या Ruby इसे रोकते नहीं हैं, लेकिन programmer के लिए इसमें साफ़ मनोवैज्ञानिक बाधा होती है
इसमें R के data frame, Python के Pandas, और Julia के DataFrames.jl जैसे software support की भी चर्चा है, जो SoA को AoS की तरह access करने देते हैं
मुझे Snowflake बहुत पसंद है और लगता है कि वह दूसरे competitors का लंच छीन लेगा। यह भी दिलचस्प है कि Snowflake foreign keys को “support” तो करता है, लेकिन उन्हें enforce नहीं करता। दूसरे शब्दों में, Snowflake उतना ही “NoSQL” है जितना मैं बर्दाश्त कर सकता हूँ
दूसरा है encapsulation को छोड़ देना, data और उसे संभालने वाले methods को अलग करना, और पूरे app को इस आधार पर सोचना कि data उसमें कैसे बहता है, ताकि उसे समझना और बदलना आसान हो। सटीकता बढ़ाने के लिए immutable data structures और pure functions का इस्तेमाल किया जा सकता है
जिज्ञासु लोगों के लिए ECS का बहुत छोटा परिचय: https://dev.to/ovid/the-unknown-design-pattern-1l64
“क्या data layout किसी एक दृष्टिकोण से निकली एकल व्याख्या से परिभाषित होता है?” यह तकनीकी चयन और architecture के नज़रिए से सबसे महत्वपूर्ण सवाल हो सकता है। आमतौर पर इस सवाल का जवाब देने के लिए business और customer से बात करनी पड़ती है
अगर आपको पूरा भरोसा है कि data के लिए पूरे सिस्टम में इस्तेमाल होने वाला ठीक एक ही वैध “view” है, तो उसे code में स्थायी रूप से दर्ज करना भी समझदारी हो सकती है। अगर ज़रा भी संदेह है, तो relational style model ज़्यादा उपयुक्त होने की संभावना है। कई कंपनियां इस समस्या की game theory समझने के बाद आखिरकार SQL पर आकर टिकती हैं
सब लोग यह सोचते हैं कि आखिर क्यों ऐसा लगता है कि सभी एक बड़े SQL database से दूर चले गए हैं। “web scale” वाले edge case हैं जो write workload की vertical scalability को चुनौती दे सकते हैं, लेकिन मेरा मानना है कि F100 कंपनियों सहित ज़्यादातर कंपनियां उस स्तर तक पहुंचती ही नहीं हैं
इसका उस तरीके से कोई लेना-देना नहीं था जो किसी खास dataset को सबसे अच्छी तरह model करता हो या सर्वोत्तम performance देता हो; वजह पूरी तरह schema flexibility और schema migration failures के कारण पहले हो चुके outages का इतिहास था। NoSQL design में ऐसी समस्याएं नहीं आती थीं, और SQL database के फायदे भी rigid schema न होने वाले NoSQL के बड़े लाभ की भरपाई नहीं कर पाते थे
बेशक, key-value store का गलत इस्तेमाल करें तो performance और cost दोनों बुरी तरह बिगड़ सकते हैं। DynamoDB जैसे cloud platform पर मैंने बहुत से मामले देखे हैं जहां data को सही तरह structure न करने के कारण भारी scan चलाने पड़े और लागत बहुत बढ़ गई
पुरानी बड़ी कंपनियों में अक्सर ऐसा होता है कि अतीत में non-technical लोगों द्वारा बनवाए गए technical solutions जम जाते हैं और फिर उन्हें बनाए रखना पड़ता है। हमारे यहां operational database से शुरू होकर business type बदलने पर हर बार अलग पीढ़ी के data model तक पहुंचने वाली SQL data transformation की 5 परतें मौजूद हैं
layer जितनी बढ़ती जाती है, लोग पुरानी layer के ऊपर ही और जोड़ते जाते हैं। 10 साल पहले abstraction layer 2 के ऊपर बना application अगर अब layer 4 का data चाहता है, तो उस data को पुरानी layer में वापस धकेलने वाली script बना दी जाती है और काम चलता रहता है। आखिरकार यह परस्पर-निर्भर tables और views का एक विशाल ढेर बन गया, जो अजीब और गैर-सहज तरीकों से data पढ़ता है, और इसे साफ़ करने वाला project इतना महंगा माना गया कि उसे 2030 के दशक तक टाल दिया गया
लोग जब ऐसी समस्या देखते हैं तो यह सोचते हैं कि इसे कैसे टाला जा सकता था, यह समझ में आता है। लेकिन किसी कारण से software engineers पर ऐसी अनुशासित पद्धति लागू करना असंभव-सा लगता है, इसलिए किसी तरह spaghetti बनने की संभावना ही खत्म करनी पड़ती है। यहीं separation आता है। अगर आप दूसरे service का data पढ़ ही नहीं सकते, तो ऐसा spaghetti नहीं बन सकता जो दोनों तरफ की गति मार दे
application का vertical separation, कंपनी में कमजोर engineering discipline जैसी मानवीय समस्या का software-आधारित समाधान बन जाता है
मैंने हाल ही में एक open source framework जारी किया जो पूरी तरह data-oriented design पर आधारित है, और काफी लोगों ने कहा कि यह design उनके लिए बिल्कुल फिट बैठता है। सारा data एक जगह रखने से बहुत-सी चीजें सचमुच आसान हो जाती हैं
https://sql.ophir.dev
उस विशाल DB में बहुत-सा ऐसा अवशेष पड़ा रहता था जिसे कोई इस्तेमाल नहीं करता था, जिसका उद्देश्य किसी को पता नहीं था, लेकिन फिर भी यह पक्का नहीं था कि उसकी अब भी जरूरत है या नहीं; साथ ही read और write के लिए अलग-अलग optimization strategy चाहिए थीं
इसके अलावा, अगर teams को तेज़ी से काम करना था, तो उन्हें DBA के ticket का जवाब आने का इंतज़ार किए बिना database और data store पर ownership चाहिए थी
जब मैं पुरानी बड़ी कंपनियों में काम करता था, तब ज़्यादातर समस्याएं राजनीतिक और प्रशासनिक थीं। एक बड़ा SQL database कुशल हो सकता है, लेकिन जैसे ही उसका मालिक संगठन नई CTO strategy या किसी दूसरे प्रमुख business unit से असहमत होता है, समस्या खड़ी हो जाती है
और अगर इसके साथ इस model की कम resilience दिखाने वाला कोई outage भी जुड़ जाए, तो यह बहुत जल्दी राजनीतिक सिरदर्द बन जाता है, और तकनीकी समाधान भले सबको अब भी साफ़ दिखते हों, उन्हें आगे बढ़ाना मुश्किल हो जाता है
यह पूरी सलाह context-dependent है
games में सिर्फ़ column-based access मांगने वाले बहुत-से operations होते हैं; हर domain ऐसा नहीं होता। game जगत की best practices को दूसरे domains पर अंधाधुंध थोपने से बस सबकी ज़िंदगी मुश्किल होगी और ज़्यादातर systems बदतर बनेंगे
boolean struct fields bitset बन सकते हैं, nullable fields sparse या dense map बन सकते हैं, और pointer या reference fields pool को index करने वाले कम-चौड़ाई वाले integer arrays बन सकते हैं
जिन environments में CPU memory access पर बार-बार रुकता है, वहां ऐसे बदलावों के असर को कम करके नहीं आंका जा सकता। L3 cache और RAM latency के बीच का अंतर लगभग 10 गुना हो सकता है
अगर किसी program में performance ज़रा-सी भी समस्या है, तो यह तरीका अच्छे performance की गारंटी देने के प्रमुख उपायों में से एक हो सकता है
आधुनिक hardware पर आगे भी जिस चीज़ के scale होने की उम्मीद है, वह सिर्फ़ logical density है। SRAM और cache sizes अब नई lithography पर पहले की तरह अच्छी तरह scale नहीं होते, और RAM bandwidth भी काफी समय से बहुत नहीं बढ़ी है। मेरा मानना है कि per-core bandwidth शायद घटी भी हो। memory access काफी समय से bottleneck रही है
data-oriented design कुछ खास sub-systems के भीतर बहुत उचित है, लेकिन high-level gameplay code में, कुछ विशेष genres को छोड़कर, यह हमेशा ज़रूरी नहीं होता
मुझे लगता है कि Mike Acton का CppCon 2014 टॉक Data-Oriented Design and C++ अब तक के सबसे बेहतरीन programming talks में से एक है। ज़रूर देखने लायक है: https://youtu.be/rX0ItVEVjHc
पहले उन्होंने Unity DOTS को भी lead किया था, लेकिन अफ़सोस कि अभी Unity कुछ डगमगाती हुई लगती है। DOTS पर काम खुद भले अधूरा हो, लेकिन मज़बूत है
मैंने अपने करियर का ज़्यादातर हिस्सा web apps लिखने में बिताया है, लेकिन यह टॉक देखने के बाद मुझे समझ आया कि “कोई C क्यों इस्तेमाल करता है?”
Andrew Kelley ने एक उपयोगी और मज़ेदार टॉक दिया था, जिसमें उन्होंने बताया कि data-oriented design ने Zig compiler पर उनके काम को कैसे प्रभावित किया: https://vimeo.com/649009599
शुरुआती लोग भी शुरू से data-oriented तरीके से programming सीख सकते हैं
इस शैली को शुरुआती लोगों को सिखाने वाली किताबों में How to Design Programs और A Data-Centric Introduction to Computing शामिल हैं
https://htdp.org/
https://dcic-world.org/
मुझे इस किताब की एक online review मिली: https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...
“कई projects को परेशान करने और देर कराने वाला असली कारण यह ज़िद रही है कि optimization जल्दी नहीं करनी चाहिए। बाद के चरणों में optimization इतनी कठिन इसलिए हो जाती है क्योंकि बहुत-सा software इस तरह बनाया जाता है कि हर जगह object instances रख दिए जाते हैं, चाहे उनकी ज़रूरत हो या नहीं।”
साफ़ है कि कुछ applications में performance सबसे बड़ी प्राथमिकता होती है, और कुछ में नहीं। इससे यह सोचने का मन होता है कि performance-critical apps में early optimization भी ठीक हो सकती है। क्या इसे ऐसे पढ़ना सही होगा, यह जानने की उत्सुकता है
Data-Oriented Programming भी नाम की एक चीज़ है: https://www.manning.com/books/data-oriented-programming
मैं जानना चाहता हूँ कि क्या ये दोनों अवधारणाएँ एक ही हैं
data-oriented design शुरुआती लोगों के लिए अनुकूल है। क्योंकि इसमें लोगों और business को संभालने से ज़्यादा data modeling की शुद्धता की बात होती है
बचपन में किसी नए project का पहला कदम entity-relationship model बनाना होता था, और वही हर चीज़ की नींव बनता था
आजकल data model से शुरू करने से पहले, पहले problem और domain को समझा जाता है, फिर capabilities और उन्हें कैसे समूहित और सीमाबद्ध करना है, इस पर सोचा जाता है
फिर भी, लगता है कि यह लेख कहना चाहता है कि अगर आप शुरुआत से ही data requirements इकट्ठा करने पर ध्यान दें, तो business requirements पर अलग से चर्चा की ज़रूरत शायद कम हो सकती है
DoD इस्तेमाल करते समय एक मुख्य विचार यह है कि data को abstraction के पीछे छिपाया न जाए। रुख यह है कि कम होना बेहतर है
लेकिन परिचय लेख को जल्दी-जल्दी पढ़ने पर मुझे उल्टा एहसास हुआ। उसमें बहुत ज़्यादा बातें थीं और मुख्य विचारों को abstraction के पीछे छिपा दिया गया था। क्या सिर्फ़ मुझे यह विडंबना लगी कि वह अपनी ही सलाह पर अमल नहीं करता?
शुरुआती पैराग्राफ़ काफ़ी शानदार है। धाराप्रवाह लेखन और दिलचस्प विचार आपको आगे पढ़ते रहने पर मजबूर करते हैं
“डेटा ही वह सब कुछ है जो हमारे पास है। डेटा वह है जिसे हमें user experience बनाने के लिए रूपांतरित करना होता है। जब आप कोई document खोलते हैं, तब जो चीज़ लोड होती है वह भी data है। स्क्रीन पर दिखने वाले graphics, gamepad button की pulse, वह कारण जिससे speaker हवा में तरंगें पैदा करता है, level-up का तरीका, और वह तरीका जिससे दुश्मन आपकी जगह जानकर गोली चलाता है, ये सब data हैं। dynamite को फटने में लगा समय और spikes पर गिरने पर खोई गई rings की संख्या भी data है। खेल खत्म होने पर दिखने वाले खूबसूरत दृश्य के हर particle की मौजूदा position और velocity भी data है, और वह चीज़ जो disk से पढ़कर आपकी ज़िंदगी में आई, वह compiler को दिए गए source code, assembler द्वारा निर्देशित instructions, और decoded instructions से चलने वाली machine के transformations का नतीजा है।”
object-oriented abstraction वाली सोच से बाहर निकालने के लिए मंच तैयार करने वाले “ठंडे पानी के छींटे” की तरह यह उपयोगी हो सकता है। लेकिन इसके अलावा, यह उतना ही उपयोगी लगता है जितना कोई engineer यह कहे: “आसपास देखो! हर चीज़ atoms से बनी है! engineering मूल रूप से atoms को इधर-उधर करने का काम है!”
बात ग़लत नहीं है, लेकिन असल में engineering करने में इससे बहुत मदद नहीं मिलती