मार्टिन क्लेपमैन के साथ बड़ा साक्षात्कार: "वितरित डेटा सिस्टम के भविष्य का पता लगाना"

डॉ मार्टिन क्लेपमैन कैंब्रिज विश्वविद्यालय में वितरित प्रणालियों में एक शोधकर्ता हैं, और अत्यधिक प्रशंसित "डिजाइनिंग डेटा-इंटेंसिव एप्लिकेशन" (ओ रेली मीडिया, 2017) के लेखक हैं।

केविन स्कॉट, माइक्रोसॉफ्ट में सीटीओ ने एक बार कहा था : “इस पुस्तक को सॉफ्टवेयर इंजीनियरों के लिए पढ़ना चाहिए। "डिजाइनिंग डेटा-इंटेंसिव एप्लिकेशन एक दुर्लभ संसाधन है जो डेवलपर्स को स्मार्ट निर्णय लेने और डेटा इंफ्रास्ट्रक्चर और सिस्टम को लागू करने में मदद करने के लिए सिद्धांत और व्यवहार को जोड़ता है।"

मार्टिन के मुख्य अनुसंधान हितों में सहयोग सॉफ्टवेयर, सीआरडीटी और वितरित एल्गोरिदम का औपचारिक सत्यापन शामिल है। पहले वह एक सॉफ्टवेयर इंजीनियर और लिंक्डइन और रैपॉर्टिव सहित कई इंटरनेट कंपनियों में एक उद्यमी थे, जहां उन्होंने बड़े पैमाने पर डेटा इन्फ्रास्ट्रक्चर पर काम किया।

वादिम टायस्को ( @incubos ) Odnoklassniki में एक प्रमुख सॉफ्टवेयर इंजीनियर है जो कोर प्लेटफॉर्म टीम में काम करता है। वादिम के वैज्ञानिक और इंजीनियरिंग हितों में वितरित सिस्टम, डेटा वेयरहाउस और सॉफ़्टवेयर सिस्टम का सत्यापन शामिल हैं।

सामग्री:

• व्यवसाय से शैक्षणिक अनुसंधान की ओर बढ़ना;
  
• "डिजाइनिंग डेटा-गहन अनुप्रयोगों" की चर्चा;
  
• कृत्रिम प्रचार और आक्रामक विपणन के खिलाफ सामान्य ज्ञान;
  
• सीएपी प्रमेय और अन्य उद्योग की गलतियों के नुकसान;
  
• विकेंद्रीकरण के लाभ;
  
• ब्लॉकचैन, डाट, आईपीएफएस, फिल्कोइन, वेबआरटीसी;
  
• नई CRDTs। इसाबेल के साथ औपचारिक सत्यापन;
  
• इवेंट सोर्सिंग। निम्न स्तर का दृष्टिकोण। XA लेन-देन
  
• Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  
• उस सभी साधनों को वास्तविक जीवन में कैसे लागू किया जाए;
  
• मार्टिन की वार्ता और हाइड्रा सम्मेलन के लक्षित दर्शक।
  

---

व्यवसाय से अकादमिक अनुसंधान के लिए आगे बढ़ रहा है

वादिम : पहला सवाल जो मैं आपसे पूछना चाहता हूं वह वास्तव में मेरे लिए महत्वपूर्ण है। आपने Go Test It और Rapportive की स्थापना की, और आप कुछ समय के लिए लिंक्डइन पर बड़े पैमाने पर डिजाइन और इंजीनियरिंग कर रहे थे। फिर आपने औद्योगिक इंजीनियरिंग से अकादमिया में जाने का फैसला किया। क्या आप उस निर्णय के लिए प्रेरणा की व्याख्या कर सकते हैं? आपने क्या प्राप्त किया है और आपको क्या त्याग करना पड़ा है?

मार्टिन : यह एक बहुत ही दिलचस्प प्रक्रिया रही है। जैसा कि आप पर इशारा कर रहे हैं, बहुत से लोग उस दिशा में स्विच नहीं बनाते हैं। बहुत सारे लोग शिक्षा से उद्योग में जाते हैं, लेकिन इतने सारे वापस नहीं। जो समझ में आता है, क्योंकि मुझे अकादमिया में वापस जाने के लिए काफी बड़े वेतन में कटौती करनी पड़ी। लेकिन मैं वास्तव में अनुसंधान के बारे में जो प्यार करता हूं वह उन विषयों पर काम करने की स्वतंत्रता है जो मुझे दिलचस्प लगते हैं और मुझे लगता है कि महत्वपूर्ण हैं, भले ही उन विषयों को अगले 6 महीनों या उसके भीतर व्यावसायिक रूप से व्यवहार्य उत्पाद न मिले। बेशक, एक कंपनी में आपके द्वारा बनाए गए सामान को एक उत्पाद में बदलने की आवश्यकता होती है जिसे किसी न किसी रूप में बेचा जा सकता है। दूसरी ओर, अब मैं जिन चीजों पर काम कर रहा हूं, वे ऐसे विषय हैं जो वास्तव में भविष्य के लिए महत्वपूर्ण हैं कि हम सॉफ्टवेयर कैसे बनाते हैं और इंटरनेट कैसे काम करता है। लेकिन हम वास्तव में इन विषयों को अभी तक अच्छी तरह से नहीं समझ पाए हैं और वाणिज्यिक उत्पादों का निर्माण शुरू कर रहे हैं: हम अभी भी यह जानने की कोशिश कर रहे हैं कि बुनियादी तौर पर इन तकनीकों को किस तरह की जरूरत है। और चूंकि यह मौलिक शोध है, इसलिए मैंने महसूस किया कि किसी विश्वविद्यालय में ऐसा करना बेहतर है क्योंकि किसी कंपनी में करने की कोशिश करना, क्योंकि एक विश्वविद्यालय में मैं उन चीजों पर काम करने के लिए स्वतंत्र हूं जो शायद एक और दस वर्षों के लिए व्यावसायिक रूप से व्यवहार्य नहीं हो सकती हैं, और यह ठीक है। जब आप शोध में हों तो बहुत अधिक समय क्षितिज के साथ काम करना ठीक है।

---

"डिजाइनिंग डेटा-गहन अनुप्रयोग"

वादिम : हम निश्चित रूप से आपके वर्तमान अनुसंधान हितों पर वापस पहुंचेंगे। इस बीच चलो अपनी नवीनतम पुस्तक Designing Data-Intensive Applications के बारे में बात करते हैं। मैं आपकी किताब का बहुत बड़ा प्रशंसक हूं और मेरा मानना ​​है कि यह आधुनिक वितरित प्रणालियों के निर्माण के लिए सबसे अच्छे मार्गदर्शकों में से एक है। आपने आज तक लगभग सभी उल्लेखनीय उपलब्धियों को कवर किया है।

मार्टिन : धन्यवाद, मुझे खुशी है कि आप इसे उपयोगी पाते हैं।

वादिम : सिर्फ उन अशुभ पाठकों के लिए जो अभी तक आपकी पुस्तक नहीं पढ़े हैं, क्या आप आजकल वितरित सिस्टम के क्षेत्र में कई प्रमुख उपलब्धियों का नाम बता सकते हैं?

मार्टिन : ठीक है, एक विशेष तकनीक की व्याख्या करने के लिए पुस्तक का लक्ष्य इतना अधिक नहीं है; लक्ष्य आपको विभिन्न प्रणालियों के संपूर्ण परिदृश्य के लिए एक मार्गदर्शिका देने के बजाय है जो डेटा को संग्रहीत और प्रसंस्करण के लिए उपयोग किया जाता है। बहुत सारे अलग-अलग डेटाबेस, स्ट्रीम प्रोसेसर, बैच प्रोसेसिंग टूल, सभी प्रकार के प्रतिकृति उपकरण और इतने पर हैं, और अवलोकन प्राप्त करना वास्तव में कठिन है। यदि आप किसी विशेष एप्लिकेशन को बनाने की कोशिश कर रहे हैं, तो यह जानना बहुत मुश्किल है कि आपको किस डेटाबेस का उपयोग करना चाहिए, और आप जिस समस्या को हल करने का प्रयास कर रहे हैं, उसके लिए कौन से उपकरण सबसे उपयुक्त हैं। मौजूदा कंप्यूटिंग किताबों की एक बहुत ही संतोषजनक तरीके से उस समस्या का जवाब नहीं दिया। मैंने पाया कि यदि आप उदाहरण के लिए कैसेंड्रा पर एक पुस्तक पढ़ रहे हैं, तो यह आपको बताएगा कि कैसंड्रा अद्भुत क्यों है, लेकिन यह आम तौर पर आपको उन चीजों के बारे में नहीं बताएगा जिनके लिए यह एक अच्छा फिट नहीं है। इसलिए मैं इस पुस्तक में वास्तव में क्या करना चाहता था, मुख्य प्रश्नों की पहचान करना था जो आपको अपने आप से पूछने की आवश्यकता है कि क्या आप किसी तरह के बड़े पैमाने पर सिस्टम बनाने की कोशिश कर रहे हैं। और उन सवालों के जवाब देने के माध्यम से आप यह पता लगाने में मदद कर सकते हैं कि कौन सी प्रौद्योगिकियां उपयुक्त हैं और आप जिस विशेष समस्या को हल करने की कोशिश कर रहे हैं, उसके लिए कम उपयुक्त हैं - क्योंकि, सामान्य रूप से, कोई भी ऐसी तकनीक नहीं है जो हर चीज के लिए एकदम सही हो। और इसलिए, पुस्तक विभिन्न सेटिंग्स में विभिन्न तकनीकों के पेशेवरों और विपक्षों का पता लगाने में आपकी मदद करने की कोशिश कर रही है।

---

कृत्रिम प्रचार और आक्रामक विपणन के खिलाफ सामान्य ज्ञान

वादिम : वास्तव में, अक्सर - यदि हमेशा नहीं - अतिव्यापी कार्यों, सुविधाओं और डेटा मॉडल के साथ कई प्रौद्योगिकियां हैं। और आप उन सभी मार्केटिंग buzzwords पर विश्वास नहीं कर सकते। इंटर्ल्स सीखने के लिए आपको श्वेत पत्र पढ़ने की आवश्यकता है, और यह समझने के लिए कि यह कैसे काम करता है, यह जानने के लिए स्रोत कोड को पढ़ने का भी प्रयास करें।

मार्टिन : और मैंने पाया कि आपको अक्सर लाइनों के बीच पढ़ना पड़ता है क्योंकि अक्सर प्रलेखन वास्तव में आपको यह नहीं बताता है कि किन चीजों के लिए एक विशेष डेटाबेस बेकार है। सच्चाई यह है कि हर डेटाबेस किसी तरह के काम के बोझ को चूसता है, सवाल सिर्फ यह जानने का है कि वे कौन से हैं। तो हां, कभी-कभी आपको ऑप्स लोगों के लिए तैनाती के दिशानिर्देशों को पढ़ना होगा और सिस्टम को रिवर्स करने की कोशिश करनी चाहिए कि वास्तव में सिस्टम क्या चल रहा है।

वादिम : क्या आपको नहीं लगता कि एक ही समस्या के लिए विभिन्न समाधानों की तुलना करने के लिए उद्योग में सामान्य शब्दावली या मापदंड का अभाव है? इसी तरह की चीजों को अलग-अलग नामों से बुलाया जाता है, कुछ चीजों को छोड़ दिया जाता है जो हमेशा स्पष्ट और स्पष्ट रूप से बताई जानी चाहिए, जैसे लेनदेन की गारंटी। आपको क्या लगता है?

मार्टिन : हाँ, मुझे लगता है कि हमारे उद्योग में एक समस्या यह है कि अक्सर, जब लोग किसी विशेष उपकरण के बारे में बात करते हैं, तो हर चीज के बारे में बहुत प्रचार होता है। जो समझ में आता है, क्योंकि उपकरण विभिन्न कंपनियों द्वारा बनाए जाते हैं, और जाहिर है कि वे कंपनियां अपने उत्पादों को बढ़ावा देना चाहती हैं, और इसलिए उन कंपनियों को लोगों को सम्मेलनों में यह बताने के लिए भेजा जाएगा कि उनका उत्पाद कितना अद्भुत है। यह एक तकनीक की बात के रूप में प्रच्छन्न होगा, लेकिन अनिवार्य रूप से यह अभी भी एक बिक्री गतिविधि है। एक उद्योग के रूप में, हम वास्तव में कुछ उत्पाद के फायदे और नुकसान के बारे में अधिक ईमानदारी के साथ कर सकते हैं। और उस हिस्से को एक सामान्य शब्दावली की आवश्यकता होती है, क्योंकि अन्यथा आप बस एक समान स्तर पर चीजों की तुलना नहीं कर सकते हैं। लेकिन एक साझा शब्दावली से परे हमें उन चीजों के बारे में तर्क करने के तरीकों की आवश्यकता है जो कुछ प्रौद्योगिकियां अच्छी या बुरी हैं।

---

कैप प्रमेय और अन्य उद्योग गलतियों के नुकसान

वादिम : मेरा अगला प्रश्न काफी विवादास्पद है। क्या आप अपने करियर के दौरान उस उद्योग में किसी बड़ी गलती का नाम ले सकते हैं, जिस पर आप अड़ गए हैं शायद ओवरवैल्यूड टेक्नोलॉजी या व्यापक रूप से प्रचलित समाधानों से हमें बहुत पहले छुटकारा मिल जाना चाहिए था? यह एक बुरा उदाहरण हो सकता है, लेकिन JSON की तुलना HTTP / 1.1 बनाम HTTP / 2 से अधिक कुशल gRPC से की जा सकती है। या कोई वैकल्पिक दृष्टिकोण है?

मार्टिन : मुझे लगता है कि कई मामलों में बहुत अच्छे कारण हैं कि एक तकनीक एक चीज क्यों करती है और दूसरी नहीं। इसलिए मैं चीजों को गलत कहने में बहुत संकोच करता हूं, क्योंकि ज्यादातर मामलों में यह व्यापार-बंद का सवाल है। HTTP / 2 पर HTTP / 1.1 बनाम प्रोटोकॉल बफ़र्स पर JSON के आपके उदाहरण में, मुझे लगता है कि वास्तव में दोनों पक्षों के लिए काफी उचित तर्क हैं। उदाहरण के लिए, यदि आप प्रोटोकॉल बफ़र्स का उपयोग करना चाहते हैं, तो आपको अपने स्कीमा को परिभाषित करना होगा, और एक स्कीमा एक अद्भुत बात हो सकती है क्योंकि यह दस्तावेज़ में मदद करता है कि संचार क्या चल रहा है। लेकिन कुछ लोग स्कीमा को परेशान करते हैं, खासकर अगर वे विकास के शुरुआती चरणों में हैं और वे बहुत बार डेटा प्रारूप बदल रहे हैं। तो आपके पास यह है, व्यापार-नापसंद का सवाल है; कुछ स्थितियों में एक बेहतर है, दूसरों में बेहतर है।

वास्तविक गलतियों के संदर्भ में, जो मुझे लगता है कि बस खराब हैं, केवल बहुत कम संख्या में चीजें हैं। एक राय है कि मेरे पास है कि कैप प्रमेय मौलिक रूप से खराब है और सिर्फ उपयोगी नहीं है। जब भी लोग डिजाइन निर्णयों को सही ठहराने के लिए CAP प्रमेय का उपयोग करते हैं, मुझे लगता है कि अक्सर वे या तो गलत व्याख्या कर रहे हैं कि CAP वास्तव में क्या कह रहा है, या एक तरह से स्पष्ट कह रहा है। एक प्रमेय के रूप में सीएपी में एक समस्या है कि यह वास्तव में सिर्फ स्पष्ट कह रहा है। इसके अलावा, यह सिर्फ एक बहुत ही संकीर्ण रूप से परिभाषित स्थिरता मॉडल के बारे में बात करता है, जिसका नाम रैखिककरण है, और एक बहुत ही संकीर्ण रूप से परिभाषित उपलब्धता मॉडल है, जो है: आप चाहते हैं कि हर प्रतिकृति पूरी तरह से पढ़ने और लिखने के लिए उपलब्ध हो, भले ही वह किसी अन्य प्रतिकृति के साथ संवाद न कर सके। ये उचित परिभाषाएं हैं, लेकिन वे बहुत संकीर्ण हैं, और कई अनुप्रयोग बस आवश्यकता के मामले में नहीं पड़ते हैं कि निरंतरता की परिभाषा या उपलब्धता की परिभाषा ठीक है। और उन सभी अनुप्रयोगों के लिए जो उन शब्दों की एक अलग परिभाषा का उपयोग करते हैं, CAP प्रमेय आपको कुछ भी नहीं बताता है। यह महज एक खाली बयान है। ताकि, मुझे लगता है, एक गलती है।

और जब हम शेख़ी मार रहे हैं, अगर आप मुझसे गलतियों का नाम पूछ रहे हैं, तो एक और बड़ी गलती जो मुझे टेक इंडस्ट्री में दिख रही है, वह है क्रिप्टोकरेंसी की माइनिंग, जो मुझे लगता है कि इस तरह की बिजली का अपव्यय है। मैं सिर्फ इस बात की थाह नहीं लगा सकता कि लोग क्यों सोचते हैं कि यह एक अच्छा विचार है।

वादिम : सीएपी प्रमेय की बात करें तो, एपी या सीपी जैसी चीजों के संदर्भ में, कई भंडारण तकनीक वास्तव में ट्यून करने योग्य हैं। आप जिस मोड में काम करते हैं, उसे चुन सकते हैं।

मार्टिन : हाँ। इसके अलावा, कई प्रौद्योगिकियां हैं जो सीएपी प्रमेय की सख्त परिभाषा के तहत न तो सुसंगत हैं और न ही उपलब्ध हैं। वे सचमुच पी हैं! सीपी नहीं, सीए नहीं, एपी नहीं, सिर्फ पी। कोई नहीं कहता है, क्योंकि यह बुरा लगेगा, लेकिन ईमानदारी से, यह पूरी तरह से उचित डिजाइन निर्णय हो सकता है। कई प्रणालियां हैं जिनके लिए वास्तव में पूरी तरह से ठीक है। यह वास्तव में कारणों में से एक है कि मुझे क्यों लगता है कि कैप चीजों के बारे में बात करने का एक ऐसा अनछुआ तरीका है: क्योंकि डिजाइन स्पेस का एक बड़ा हिस्सा है कि यह बस कैप्चर नहीं करता है, जहां सॉफ्टवेयर के लिए पूरी तरह से उचित अच्छे डिजाइन हैं कि यह बस आप के बारे में बात करने की अनुमति नहीं है।

---

विकेंद्रीकरण के लाभ

वादिम : आज डेटा-सघन अनुप्रयोगों के बारे में बात करते हुए, अन्य प्रमुख चुनौतियाँ, अनसुलझी समस्याएँ या हॉट रिसर्च विषय आपके नाम पर क्या हो सकते हैं? जहाँ तक मुझे पता है, आप विकेंद्रीकृत संगणना और भंडारण के एक प्रमुख प्रस्तावक हैं।

मार्टिन : हाँ। मेरे शोध के पीछे एक शोध यह है कि फिलहाल हम सर्वर और केंद्रीकरण पर बहुत अधिक निर्भर हैं। यदि आप सोचते हैं कि ARPANET से विकसित होने पर इंटरनेट को मूल रूप से उस दिन वापस कैसे डिज़ाइन किया गया था, तो यह एक बहुत ही लचीले नेटवर्क के रूप में बनाया गया था, जहाँ कई अलग-अलग मार्गों से पैकेट भेजे जा सकते थे, और वे अभी भी गंतव्य को प्राप्त करेंगे। और अगर एक परमाणु बम एक विशेष अमेरिकी शहर को मारता है, तो बाकी नेटवर्क अभी भी काम करेगा क्योंकि यह सिस्टम के असफल हिस्सों के आसपास का मार्ग होगा। यह एक शीत युद्ध डिजाइन था।

और फिर हमने सब कुछ बादल में डालने का फैसला किया, और अब मूल रूप से सब कुछ AWS के डेटासेंटर में से एक के माध्यम से जाना है, जैसे कि हम-पूर्व -1 वर्जीनिया में कहीं। हमने नेटवर्क के विभिन्न हिस्सों के विकेंद्रीकरण का उपयोग करने में सक्षम होने के इस आदर्श को दूर कर लिया है, और हमने इन सर्वरों में डाल दिया है जो सब कुछ पर निर्भर करता है, और अब यह बहुत केंद्रीकृत है। तो मैं विकेंद्रीकरण में दिलचस्पी रखता हूं, कुछ शक्ति को स्थानांतरित करने और उन सर्वरों से दूर डेटा पर नियंत्रण करने और अंतिम उपयोगकर्ताओं पर वापस जाने के अर्थ में।

एक बात जो मैं इस संदर्भ में जोड़ना चाहता हूं, वह यह है कि विकेंद्रीकरण के बारे में बात करने वाले बहुत से लोग क्रिप्टोकरेंसी जैसी चीजों के बारे में बात कर रहे हैं, क्योंकि वे विकेंद्रीकरण के एक ऐसे रूप का भी प्रयास कर रहे हैं जिससे नियंत्रण एक बैंक और केंद्रीय नेटवर्क जैसे केंद्रीय प्राधिकरण से दूर हो जाता है सहयोगी नोड्स के। लेकिन यह वास्तव में विकेंद्रीकरण की तरह नहीं है जिसकी मुझे दिलचस्पी है: मुझे लगता है कि ये क्रिप्टोकरेंसी वास्तव में अभी भी बेहद केंद्रीकृत हैं, इस अर्थ में कि यदि आप एक बिटकॉइन लेनदेन करना चाहते हैं, तो आपको इसे बिटकॉइन नेटवर्क पर बनाना होगा - आप बिटकॉइन के नेटवर्क का उपयोग करना है, इसलिए सब कुछ उस विशेष नेटवर्क पर केंद्रीकृत है। जिस तरह से इसे बनाया गया है, वह इस अर्थ में विकेंद्रीकृत है कि इसमें एक भी नियंत्रण नोड नहीं है, लेकिन एक पूरे के रूप में नेटवर्क इस बात में बहुत केंद्रीकृत है कि आपको जो भी लेनदेन करना है वह इस नेटवर्क के माध्यम से करना होगा। आप इसे किसी और तरीके से नहीं कर सकते। मुझे लगता है कि यह अभी भी केंद्रीकरण का एक रूप है।

एक क्रिप्टोक्यूरेंसी के मामले में यह केंद्रीयकरण अपरिहार्य हो सकता है, क्योंकि आपको दोहरे खर्च से बचने के लिए सामान करने की आवश्यकता होती है, और ऐसा करना एक नेटवर्क के बिना मुश्किल है जो कि लेन-देन के बारे में आम सहमति प्राप्त करता है जो कि हुआ है और जो नहीं हुआ है। और यह वही है जो Bitcoin नेटवर्क करता है। लेकिन कई एप्लिकेशन हैं जिन्हें ब्लॉकचेन जैसी चीज की आवश्यकता नहीं है, जो वास्तव में सिस्टम के आसपास बहने वाले डेटा के अधिक लचीले मॉडल के साथ सामना कर सकते हैं। और यह विकेंद्रीकृत प्रणाली का प्रकार है जिसकी मुझे सबसे अधिक दिलचस्पी है।

वादिम : क्या आप ब्लॉकचेन के अलावा विकेंद्रीकृत प्रणालियों के क्षेत्र में किसी भी आशाजनक या अनिर्धारित प्रौद्योगिकी का नाम दे सकते हैं? मैं कुछ समय से IPFS का उपयोग कर रहा हूं।

मार्टिन : आईपीएफएस के लिए, मैंने इसे थोड़ा सा देखा है, हालांकि मैंने वास्तव में इसका इस्तेमाल खुद नहीं किया है। हमने डाट प्रोजेक्ट के साथ कुछ काम किया है, जो कुछ हद तक आईपीएफएस के समान है, यह एक विकेंद्रीकृत भंडारण प्रौद्योगिकी भी है। अंतर यह है कि IPFS में Filecoin है , जो एक cryptocurrency है, इसे भंडारण संसाधनों के भुगतान के तरीके के रूप में संलग्न किया गया है, जबकि Dat के पास कोई ब्लॉकचैन नहीं है - यह पूरी तरह से एक P2P तरीके से कई मशीनों में डेटा की प्रतिकृति बनाने का एक तरीका है।

जिस प्रोजेक्ट पर मैं काम कर रहा हूं, उसके लिए डाट काफी अच्छी तरह से फिट रहा है, क्योंकि हम सहयोग सॉफ़्टवेयर का निर्माण करना चाहते थे जिसमें कई अलग-अलग उपयोगकर्ता प्रत्येक दस्तावेज़ या डेटाबेस को संपादित कर सकते थे, और उस डेटा में कोई भी बदलाव किसी को भी भेजा जाएगा। और जिनके पास इस डेटा की एक प्रति होनी चाहिए। हम इस प्रतिकृति को एक P2P तरीके से करने के लिए Dat का उपयोग कर सकते हैं, और Dat सभी नेटवर्किंग स्तर के सामान की देखभाल करता है, जैसे NAT traversal और फ़ायरवॉल के माध्यम से प्राप्त करना - पैकेट को एक छोर से दूसरे छोर तक ले जाना काफी मुश्किल समस्या है । और फिर हमने CRDTs का उपयोग करते हुए उसके ऊपर एक परत बनाई, जो कई लोगों को कुछ दस्तावेज़ या डेटासेट संपादित करने और एक कुशल तरीके से उन संपादन का आदान-प्रदान करने की अनुमति देने का एक तरीका है। मुझे लगता है कि आप शायद IPFS पर भी इस तरह का निर्माण कर सकते हैं: आप शायद Filecoin पहलू को नजरअंदाज कर सकते हैं और बस P2P प्रतिकृति पहलू का उपयोग कर सकते हैं, और यह शायद काम भी करेगा।

वादिम : निश्चित रूप से, हालांकि IPFS का उपयोग करने से कम जवाबदेही हो सकती है, क्योंकि WebRTC अंतर्निहित Dat P2P नोड्स को सीधे जोड़ता है, और IPFS वितरित हैश टेबल चीज की तरह काम करता है।

मार्टिन : खैर, WebRTC स्टैक के एक अलग स्तर पर है, क्योंकि यह ज्यादातर दो लोगों को एक साथ जोड़ने के लिए है, जो वीडियो कॉल कर रहे हैं; वास्तव में, अभी हम इस साक्षात्कार के लिए जिस सॉफ्टवेयर का उपयोग कर रहे हैं, वह अच्छी तरह से WebRTC का उपयोग कर सकता है। और WebRTC आपको एक डेटा चैनल देता है जिसका उपयोग आप मनमाने ढंग से द्विआधारी डेटा भेजने के लिए कर सकते हैं, लेकिन उसके ऊपर एक पूर्ण प्रतिकृति प्रणाली का निर्माण अभी भी काफी काम का है। और यह कुछ ऐसा है जो Dat या IPFS पहले से करता है।

आपने जवाबदेही का उल्लेख किया है - यह निश्चित रूप से सोचने वाली एक बात है। कहते हैं कि आप अगले Google डॉक्स को विकेंद्रीकृत तरीके से बनाना चाहते थे। Google डॉक्स के साथ, आपके द्वारा किए जाने वाले परिवर्तनों की इकाई एकल कीस्ट्रोक है। आपके द्वारा अपने कीबोर्ड पर टाइप किया जाने वाला हर एक अक्षर वास्तविक समय में आपके सहयोगियों को भेजा जा सकता है, जो तेजी से वास्तविक समय के सहयोग के दृष्टिकोण से महान है। लेकिन इसका मतलब यह भी है कि एक बड़े दस्तावेज़ को लिखने के दौरान आपके पास इन एकल-चरित्र संपादनों के सैकड़ों हजारों जमा हो सकते हैं, और अभी इनमें से बहुत सारी तकनीकें इस तरह के संपादन डेटा को संपीड़ित करने में बहुत अच्छी नहीं हैं। आप उन सभी संपादनों को रख सकते हैं जो आपने कभी अपने दस्तावेज़ में बनाए हैं, लेकिन भले ही आप हर एक कीस्ट्रोके के लिए सिर्फ सौ बाइट भेजें, जो आप बनाते हैं और आप के साथ थोड़ा बड़ा दस्तावेज़ लिखते हैं, कहते हैं, 100,000 कीस्ट्रोक, आप अब अचानक एक दस्तावेज़ के लिए 10 एमबी डेटा है जो सामान्य रूप से केवल कुछ दस किलो किलोबाइट होगा। इसलिए हमारे पास डेटा की मात्रा के लिए यह बहुत बड़ा ओवरहेड है, जिसे आसपास भेजने की आवश्यकता है, जब तक कि हम परिवर्तनों को संपीड़ित करने और पैकेजिंग करने में अधिक चतुर न हों।

किसी के द्वारा टाइप किए गए हर चरित्र की पूरी सूची भेजने के बजाय, हम शायद दस्तावेज़ की वर्तमान स्थिति भेज सकते हैं, और उसके बाद हम कोई भी अपडेट भेजते हैं जो तब से हुआ है। लेकिन इनमें से बहुत से सहकर्मी-सहकर्मी सिस्टम के पास अभी तक उन राज्य स्नैपशॉट को करने का एक तरीका नहीं है जो Google डॉक्स जैसी किसी चीज़ के लिए उनका उपयोग करने के लिए पर्याप्त कुशल होंगे। यह वास्तव में एक ऐसा क्षेत्र है जिस पर मैं सक्रिय रूप से काम कर रहा हूं, किसी पाठ दस्तावेज़ जैसी किसी चीज़ के लिए विभिन्न उपयोगकर्ताओं को सिंक्रनाइज़ करने के लिए बेहतर एल्गोरिदम खोजने की कोशिश कर रहा हूं, जहां हम हर एक कीस्ट्रोके को नहीं रखना चाहते हैं क्योंकि यह बहुत महंगा होगा, और हम चाहते हैं नेटवर्क बैंडविड्थ का अधिक कुशल उपयोग करना।

---

नई CRDTs। इसाबेल के साथ औपचारिक सत्यापन

वादिम : क्या आप उस कीस्ट्रोके डेटा को पर्याप्त रूप से संपीड़ित करने में कामयाब रहे हैं? क्या आपने नए CRDT या कुछ इसी तरह का आविष्कार किया है?

मार्टिन : हाँ। अभी तक हमारे पास केवल इसके लिए प्रोटोटाइप हैं, यह अभी तक पूरी तरह से लागू नहीं हुआ है, और हमें अभी भी यह मापने के लिए कुछ और प्रयोग करने की आवश्यकता है कि वास्तव में यह कितना प्रभावी है। लेकिन हमने कुछ संपीड़न योजनाएं विकसित की हैं जो बहुत ही आशाजनक हैं। अपने प्रोटोटाइप में मैंने इसे प्रति संपादन लगभग 1.7 बाइट्स से घटाकर 1.7 एडिट प्रति ओवरहेड की तरह किया। और यह एक बहुत अधिक उचित पाठ्यक्रम है। लेकिन जैसा कि मैं कहता हूं, ये प्रयोग अभी भी जारी हैं, और संख्या अभी भी थोड़ी बदल सकती है। लेकिन मुझे लगता है कि नीचे की रेखा यह है कि अभी भी अनुकूलन के लिए बहुत जगह है, इसलिए हम अभी भी इसे बहुत बेहतर बना सकते हैं।

वादिम : तो यह आपकी बात हाइड्रा सम्मेलन में होगी , क्या मैं सही हूं?

मार्टिन : हां, बिल्कुल। मैं CRDTs, सहयोगी सॉफ्टवेयर और उस संदर्भ में आने वाली कुछ समस्याओं के क्षेत्र का त्वरित परिचय दूंगा। फिर मैं कुछ शोधों का वर्णन करूँगा जो हम इस क्षेत्र में कर रहे हैं। यह काफी मजेदार है क्योंकि हम जो शोध कर रहे हैं वह विभिन्न चिंताओं की एक पूरी श्रृंखला में किया गया है। बहुत ही लागू पक्ष पर, हमें इन एल्गोरिदम का जावास्क्रिप्ट कार्यान्वयन मिला है, और हम इसका उपयोग सॉफ्टवेयर के वास्तविक टुकड़ों के निर्माण के लिए कर रहे हैं, उस सॉफ़्टवेयर का उपयोग करने की कोशिश कर रहे हैं यह देखने के लिए कि यह कैसे व्यवहार करता है। स्पेक्ट्रम के दूसरे छोर पर, हम इन एल्गोरिदम को सही साबित करने के लिए औपचारिक तरीकों से काम कर रहे हैं, क्योंकि इनमें से कुछ एल्गोरिदम काफी सूक्ष्म हैं और हम यह सुनिश्चित करना चाहते हैं कि जो सिस्टम हम बना रहे हैं वह वास्तव में सही हो, अर्थात वे हमेशा एक सुसंगत स्थिति में पहुंचते हैं। अतीत में बहुत सारे एल्गोरिदम रहे हैं जो वास्तव में ऐसा करने में विफल रहे हैं, जो कि बस गलत थे, जो कि कुछ धार के मामलों में, वे स्थायी रूप से असंगत बने रहेंगे। और इसलिए, इन समस्याओं से बचने के लिए जो एल्गोरिदम अतीत में पड़ा है, हम अपने एल्गोरिदम को सही साबित करने के लिए औपचारिक तरीकों का उपयोग कर रहे हैं।

वादिम : वाह। क्या आप वास्तव में प्रमेय प्रूफ का उपयोग करते हैं, जैसे कि कॉक या इसाबेल या कुछ और?

मार्टिन : बिल्कुल, हम उस के लिए इसाबेल का उपयोग कर रहे हैं।

सितंबर में द स्ट्रेंज लूप सम्मेलन में आप मार्टिन की बात "इसाबेल के साथ वितरित प्रणालियों के सही प्रमाण" में शामिल हो सकते हैं।

वादिम : बहुत अच्छा लगता है! क्या वे प्रमाण प्रकाशित होने वाले हैं?

मार्टिन : हां, हमारे सबूत का पहला सेट पहले से ही सार्वजनिक है। हमने डेढ़ साल पहले प्रकाशित किया था: यह CRDTs को सत्यापित करने के लिए एक ढांचा था, और हमने उस ढांचे के भीतर तीन विशेष CRDTs का सत्यापन किया, जिनमें से एक मुख्य RGA ( रिप्लाइड ग्रोथेबल एरे ) था, जो सहयोगी पाठ संपादन के लिए CRTT है। हालांकि यह बहुत जटिल नहीं है, यह काफी सूक्ष्म एल्गोरिथ्म है, और इसलिए यह एक अच्छा मामला है जहां सबूत की आवश्यकता होती है, क्योंकि यह सिर्फ यह देखने से स्पष्ट नहीं है कि यह वास्तव में सही है। और इसलिए प्रमाण हमें अतिरिक्त निश्चितता देता है कि यह वास्तव में सही है। हमारे पिछले काम मौजूदा CRDTs के एक जोड़े को सत्यापित करने पर था, और इस क्षेत्र में हमारा सबसे हालिया काम हमारे नए डेटा मॉडल के लिए हमारे अपने CRDTs के बारे में है जो हम विकसित कर रहे हैं, और हमारे अपने CRDTs को भी सही साबित कर रहे हैं।

वादिम : एल्गोरिथम के वर्णन की तुलना में प्रमाण कितना बड़ा है? क्योंकि यह कभी-कभी एक समस्या हो सकती है।

मार्टिन : हाँ, यह एक समस्या है - सबूत अक्सर बहुत काम आते हैं। मुझे लगता है कि हमारे नवीनतम उदाहरण में ... दरअसल, मुझे कोड पर एक त्वरित नजर डालनी चाहिए। एल्गोरिथ्म और डेटा संरचनाओं का वर्णन कोड की लगभग 60 लाइनें हैं। तो यह काफी छोटा एल्गोरिथ्म है। इसका प्रमाण 800 से अधिक रेखाएँ हैं। इसलिए हमें प्रमाण और कोड के बीच लगभग 12: 1 का अनुपात मिला है। और यह दुर्भाग्य से काफी विशिष्ट है। प्रमाण बड़ी मात्रा में अतिरिक्त काम है। दूसरी ओर, एक बार हमारे पास सबूत होने के बाद, हमने एल्गोरिथम की शुद्धता में बहुत मजबूत निश्चितता प्राप्त की है। इसके अलावा, हम खुद को, मनुष्य के रूप में, एल्गोरिथ्म को बेहतर तरीके से समझते हैं। अक्सर मुझे लगता है कि इसे औपचारिक रूप देने की कोशिश करने के माध्यम से, हम उस चीज़ को समझने की कोशिश करते हैं जिसे हम पहले से बेहतर करने की कोशिश कर रहे हैं। और यह अपने आप में वास्तव में इस कार्य से एक उपयोगी परिणाम है: सबूत के अलावा हम एक गहरी समझ हासिल करते हैं, और यह अक्सर बेहतर कार्यान्वयन बनाने के लिए बहुत उपयोगी है।

वादिम : क्या आप कृपया अपनी बातों के लक्षित दर्शकों का वर्णन कर सकते हैं कि यह कितना कट्टर है? प्रारंभिक ज्ञान क्या है जिसकी आपको दर्शकों से अपेक्षा है?

मार्टिन : मैं अपनी वार्ता को यथासंभव पहले के ज्ञान की आवश्यकता के साथ सुलभ बनाना पसंद करता हूं, और मैं हर किसी को समान स्तर तक उठाने की कोशिश करता हूं। मैं बहुत सारी सामग्री को कवर करता हूं, लेकिन मैं कम आधार पर शुरू करता हूं। मैं लोगों से कुछ सामान्य वितरित प्रणालियों के अनुभव की उम्मीद करूंगा: आप टीसीपी का उपयोग करके नेटवर्क पर कुछ डेटा कैसे भेजते हैं, या शायद यह एक मोटा विचार है कि गिट कैसे काम करता है, जो इन चीजों के लिए काफी अच्छा मॉडल है। लेकिन यह आप की जरूरत है, वास्तव में है। फिर, हम जो काम कर रहे हैं, उसे समझना वास्तव में बहुत मुश्किल नहीं है। मैं सब कुछ समझाता हूं उदाहरण के लिए, चित्रों का उपयोग करके सब कुछ स्पष्ट करना। उम्मीद है, हर कोई साथ पालन करने में सक्षम होगा।

---

इवेंट सोर्सिंग। निम्न स्तर का दृष्टिकोण। XA लेन-देन

वादिम : वास्तव में बहुत अच्छा लगता है। दरअसल, हमारे पास कुछ समय है और मैं आपके हाल के लेखों में से एक के बारे में ऑनलाइन इवेंट प्रोसेसिंग के बारे में चर्चा करना चाहूंगा। आप इवेंट सोर्सिंग के विचार के महान समर्थक हैं, क्या यह सही है?

मार्टिन : हाँ, ज़रूर।

वादिम : आजकल यह दृष्टिकोण गति प्राप्त कर रहा है, और विश्व स्तर पर सभी तरह के फायदों के लिए, लॉग के संचालन का आदेश दिया गया है, कई इंजीनियर इसे हर जगह तैनात करने का प्रयास करते हैं। क्या आप कुछ ऐसे मामलों का वर्णन कर सकते हैं जहाँ इवेंट सोर्सिंग सबसे अच्छा विकल्प नहीं है? बस इसके दुरुपयोग को रोकने और दृष्टिकोण के साथ ही संभव निराशा।

मार्टिन : स्टैक की दो अलग-अलग परतें हैं जिनके बारे में हमें पहले बात करनी है। इवेंट सोर्सिंग, जैसा कि ग्रेग यंग और कुछ अन्य लोगों द्वारा प्रस्तावित किया गया है, डेटा मॉडलिंग के लिए एक तंत्र के रूप में इरादा है, वह यह है: यदि आपके पास एक डेटाबेस स्कीमा है और आप इसका नियंत्रण खोना शुरू कर रहे हैं क्योंकि बहुत सारे अलग-अलग टेबल हैं और वे ' सभी को अलग-अलग लेन-देन द्वारा संशोधित किया जा रहा है - फिर इवेंट सोर्सिंग इस डेटा मॉडल में बेहतर स्पष्टता लाने का एक तरीका है, क्योंकि ईवेंट व्यवसाय स्तर पर क्या हो रहा है, इसे बहुत ही सीधे व्यक्त कर सकते हैं। उपयोगकर्ता ने क्या कार्रवाई की है? और फिर, उस कार्रवाई के परिणाम विभिन्न तालिकाओं और इतने पर अद्यतन हो सकते हैं। वास्तव में, आप इवेंट सोर्सिंग के साथ क्या कर रहे हैं क्या आप एक्शन (ईवेंट) को इसके प्रभावों से अलग कर रहे हैं, जो कहीं न कहीं बहाव के साथ होता है।

मैं थोड़ा अलग कोण से इस क्षेत्र में आया हूं, जो कि अत्यधिक स्केलिंग सिस्टम बनाने के लिए काफ्का जैसी प्रणालियों का उपयोग करने का एक निम्न-स्तरीय बिंदु है। यह दृश्य इस अर्थ में समान है कि यदि आप कफ़्का जैसी किसी चीज़ का उपयोग कर रहे हैं तो आप घटनाओं का उपयोग कर रहे हैं, लेकिन इसका मतलब यह नहीं है कि आप आवश्यक रूप से इवेंट सोर्सिंग का उपयोग कर रहे हैं। और इसके विपरीत, आपको इवेंट सोर्सिंग करने के लिए काफ्का का उपयोग करने की आवश्यकता नहीं है; आप एक नियमित डेटाबेस में ईवेंट सोर्सिंग कर सकते हैं, या आप एक विशेष डेटाबेस का उपयोग कर सकते हैं जो विशेष रूप से ईवेंट सोर्सिंग के लिए डिज़ाइन किया गया था। तो ये दो विचार समान हैं, लेकिन न तो दूसरे की आवश्यकता है, उनके पास केवल कुछ ओवरलैप है।

काफ़्का जैसी प्रणाली का उपयोग करने की इच्छा के मामले में अधिकतर स्केलेबिलिटी तर्क है: उस मामले में आपको बस इतना डेटा मिल रहा है कि आप इसे वास्तविक रूप से एकल-नोड डेटाबेस पर संसाधित नहीं कर सकते हैं, इसलिए आपको इसे कुछ में विभाजित करना होगा रास्ता, और काफ्का की तरह एक इवेंट लॉग का उपयोग करने से आपको कई मशीनों पर काम करने का अच्छा तरीका मिलता है। यह स्केलिंग सिस्टम के लिए एक अच्छा, राजसी तरीका प्रदान करता है। यदि आप कई अलग-अलग भंडारण प्रणालियों को एकीकृत करना चाहते हैं तो यह विशेष रूप से उपयोगी है। इसलिए, उदाहरण के लिए, आप न केवल अपने संबंधपरक डेटाबेस को अपडेट करना चाहते हैं, बल्कि यह भी कहेंगे, जैसे कि एलीस्टेखर्च, या कैम्केड या कैडिस जैसी कैशिंग प्रणाली या ऐसा कुछ, और आप चाहते हैं कि एक ईवेंट हो। इन सभी विभिन्न प्रणालियों पर प्रभाव को अद्यतन करना, तब काफ्का जैसी कोई चीज बहुत उपयोगी है।

आपके द्वारा पूछे गए प्रश्न के संदर्भ में (ऐसी कौन-सी स्थितियां हैं, जिनमें मैं इस इवेंट सोर्सिंग या इवेंट लॉग अप्रोच का उपयोग नहीं करूंगा) - मुझे लगता है कि इसे सटीक रूप से कहना मुश्किल है, लेकिन अंगूठे के एक नियम के रूप में मैं कहूंगा: जो भी सबसे सरल है उसका उपयोग करें । यही है, जो भी उस डोमेन के सबसे करीब है जिसे आप लागू करने का प्रयास कर रहे हैं। और इसलिए, यदि आप जिस चीज़ के नक्शे को बहुत अच्छे से रिलेशनल डेटाबेस पर लागू करने की कोशिश कर रहे हैं, जिसमें आप सिर्फ सम्मिलित करते हैं और कुछ पंक्तियों को अपडेट और हटाते हैं, तो बस एक रिलेशनल डेटाबेस का उपयोग करें और सम्मिलित करें और कुछ पंक्तियों को अपडेट और हटाएं। संबंधपरक डेटाबेस के साथ कुछ भी गलत नहीं है और उनका उपयोग कर रहे हैं जैसा कि वे हैं। उन्होंने हमारे लिए लंबे समय तक ठीक काम किया है और वे ऐसा करना जारी रखते हैं। लेकिन अगर आप खुद को उस स्थिति में पा रहे हैं, जहां आप वास्तव में उस तरह के डेटाबेस का उपयोग करने के लिए संघर्ष कर रहे हैं, उदाहरण के लिए क्योंकि डेटा मॉडल की जटिलता हाथ से बाहर हो रही है, तो यह एक घटना सोर्सिंग जैसी किसी चीज़ पर स्विच करने के लिए समझ में आता है दृष्टिकोण।

और इसी तरह, निचले स्तर (स्केलेबिलिटी) पर, यदि आपके डेटा का आकार ऐसा है कि आप इसे एक मशीन पर पोस्टग्रेक्यूक्यू में डाल सकते हैं - तो यह शायद ठीक है, बस एक मशीन पर पोस्टग्रेक्यूएल का उपयोग करें। लेकिन अगर आप उस बिंदु पर हैं जहां कोई रास्ता नहीं है कि एक एकल मशीन आपके भार को संभाल सकती है, तो आपको एक बड़ी प्रणाली में स्केल करना होगा, फिर यह काफ्का जैसी अधिक वितरित प्रणालियों पर ध्यान देना शुरू कर देगा। मुझे लगता है कि यहां सामान्य सिद्धांत यह है: जिस विशेष कार्य के लिए आप हल करने का प्रयास कर रहे हैं, उसके लिए सबसे सरल है इसका उपयोग करें।

वादिम : यह वास्तव में अच्छी सलाह है। जैसा कि आपका सिस्टम विकसित करता है, आप विकास की दिशा, सभी प्रश्नों, पैटर्न और डेटा प्रवाह की सटीक भविष्यवाणी नहीं कर सकते।

मार्टिन : वास्तव में, और उन प्रकार की स्थितियों के लिए संबंधपरक डेटाबेस अद्भुत हैं, क्योंकि वे बहुत लचीले हैं, खासकर यदि आप JSON समर्थन को शामिल करते हैं जो अब उनके पास है। PostgreSQL में अब JSON के लिए बहुत अच्छा समर्थन है। यदि आप एक अलग तरीके से क्वेरी करना चाहते हैं तो आप बस एक नया सूचकांक जोड़ सकते हैं। आप बस स्कीमा को बदल सकते हैं और एक अलग संरचना में डेटा के साथ चल सकते हैं। और इसलिए यदि डेटा सेट का आकार बहुत बड़ा नहीं है और जटिलता बहुत बड़ी नहीं है, तो संबंधपरक डेटाबेस अच्छी तरह से काम करते हैं और लचीलेपन का एक बड़ा सौदा प्रदान करते हैं।

वादिम : आइए इवेंट सोर्सिंग के बारे में थोड़ा और बात करें। आपने कई उपभोक्ताओं के साथ एक दिलचस्प उदाहरण का उल्लेख किया है जो काफ्का या इसी तरह की चीज़ों पर आधारित एक कतार से घटनाओं का उपभोग करते हैं। कल्पना करें कि नए दस्तावेज़ प्रकाशित हो जाते हैं, और कई सिस्टम ईवेंट का उपभोग कर रहे हैं: एलीस्टेक खोज पर आधारित एक खोज प्रणाली, जो दस्तावेजों को खोज योग्य बनाती है, एक कैशिंग प्रणाली जो उन्हें मेम्केड के आधार पर कुंजी-मूल्य कैश में डालती है, और एक रिलेशनल डेटाबेस सिस्टम है जो कुछ तदनुसार टेबल। एक दस्तावेज़ एक कार बेचने की पेशकश या एक रियल्टी विज्ञापन हो सकता है। ये सभी उपभोग प्रणाली एक साथ और समवर्ती रूप से काम करती हैं।

मार्टिन : तो आपका सवाल यह है कि आप इस तथ्य से कैसे निपटते हैं कि यदि आपके पास ये कई उपभोक्ता हैं, तो उनमें से कुछ को अपडेट किया जा सकता है, लेकिन अन्य ने अभी तक अपडेट नहीं देखा है और अभी भी थोड़ा पीछे हैं?

वादिम : हां, बिल्कुल। एक उपयोगकर्ता आपकी वेबसाइट पर आता है, एक खोज क्वेरी में प्रवेश करता है, कुछ खोज परिणाम प्राप्त करता है और एक लिंक पर क्लिक करता है। लेकिन उसे 404 HTTP स्टेटस कोड मिलता है क्योंकि डेटाबेस में ऐसी कोई इकाई नहीं है, जो अभी तक दस्तावेज़ का उपभोग और उसे जारी रखने में सक्षम नहीं है।

मार्टिन : हां, यह वास्तव में एक चुनौती है। आदर्श रूप में, आप जो चाहते हैं, वह है कि हम इन विभिन्न भंडारण प्रणालियों में "कारण स्थिरता" कहेंगे। यदि एक सिस्टम में कुछ डेटा होते हैं, जो आप पर निर्भर करते हैं, तो अन्य सिस्टम जो आप देखते हैं, उन पर निर्भरता भी होगी। दुर्भाग्य से, अलग-अलग स्टोरेज प्रौद्योगिकियों में उस तरह की कार्य-क्षमता की स्थिरता वास्तव में बहुत कठिन है, और यह वास्तव में इवेंट सोर्सिंग की गलती नहीं है, क्योंकि कोई फर्क नहीं पड़ता कि आप किस दृष्टिकोण या किस प्रणाली का उपयोग करके विभिन्न विभिन्न प्रणालियों को अपडेट भेजते हैं, हमेशा किसी प्रकार के समसामयिक मुद्दों के साथ समाप्त हो सकता है।

मेमकाटेड और एलीस्टेखर्च दोनों के लिए डेटा लिखने के आपके उदाहरण में, भले ही आप दो सिस्टमों को एक साथ लिखने की कोशिश करते हों, आपके पास नेटवर्क में थोड़ी देरी हो सकती है, जिसका अर्थ है कि वे उन अलग-अलग प्रणालियों पर थोड़ा अलग समय पर आते हैं, और थोड़ा अलग समय के साथ संसाधित हो। और इसलिए कोई व्यक्ति जो उन दो प्रणालियों में पढ़ रहा है, एक असंगत स्थिति देख सकता है। अब, कुछ शोध परियोजनाएँ हैं जो कम से कम उस प्रकार की सामंजस्यता को प्राप्त करने की दिशा में काम कर रही हैं, लेकिन यह अभी भी मुश्किल है, यदि आप एलीटेसर्च या मेमकाटेड या शेल्फ से कुछ का उपयोग करना चाहते हैं।

यहां एक अच्छा समाधान यह होगा कि आप खोज सूचकांक और कैश और डेटाबेस दोनों के अनुरूप स्नैपशॉट के साथ, संकल्पनात्मक रूप से प्रस्तुत करें। यदि आप एक संबंधपरक डेटाबेस के भीतर काम कर रहे हैं, तो आपको स्नैपशॉट अलगाव कहा जाता है, और स्नैपशॉट अलगाव की बात यह है कि यदि आप डेटाबेस से पढ़ रहे हैं, तो ऐसा लगता है कि जैसे आपने पूरी की अपनी निजी प्रति प्राप्त कर ली है डेटाबेस। कुछ भी आप डेटाबेस में देखते हैं, आपके द्वारा क्वेरी किया गया कोई भी डेटा स्नैपशॉट के अनुसार उस समय की स्थिति जैसा होगा। इसलिए भले ही डेटा बाद में किसी अन्य लेनदेन द्वारा बदल दिया गया हो, आप वास्तव में पुराने डेटा को देखेंगे, क्योंकि वह पुराना डेटा एक सुसंगत स्नैपशॉट का हिस्सा है।

और इसलिए अब, उस मामले में जहां आपको एलिटेसर्च और मेमकाटेड मिला है, वास्तव में आप जो आदर्श रूप से चाहते हैं वह दो प्रणालियों में एक सुसंगत स्नैपशॉट है। लेकिन दुर्भाग्य से, न तो मेम्केच्ड और न ही रेडिस और न ही एलिटिक्स खोज में उन प्रकार के स्नैपशॉट बनाने के लिए एक कुशल तंत्र है जिन्हें विभिन्न भंडारण प्रणालियों के साथ समन्वित किया जा सकता है। प्रत्येक भंडारण प्रणाली सिर्फ अपने लिए सोचती है और आम तौर पर आपको हर कुंजी का नवीनतम मूल्य प्रस्तुत करती है, और इसमें डेटा को देखने और पुराने संस्करण को पेश करने की यह सुविधा नहीं है, क्योंकि डेटा का सबसे हाल का संस्करण अभी तक नहीं है संगत।

मेरे पास वास्तव में एक अच्छा जवाब नहीं है कि समाधान क्या दिखेगा। मुझे डर है कि समाधान को इस तरह की चीज़ में भाग लेने वाले किसी भी संग्रहण सिस्टम में कोड परिवर्तन की आवश्यकता होगी। इसलिए इसे एलीस्टेकर्च और रेडिस और मेम्केच्ड और किसी भी अन्य सिस्टम में बदलाव की आवश्यकता होगी। और उन्हें पॉइंट-इन-टाइम स्नैपशॉट के लिए किसी प्रकार का तंत्र जोड़ना होगा जो कि काफी सस्ता हो, जिसे आप हर समय उपयोग कर सकते हैं, क्योंकि आप प्रति सेकंड कई बार स्नैपशॉट चाहते होंगे - यह सिर्फ एक बार नहीं है -दिन का स्नैपशॉट, यह बहुत बारीक है। और इस समय अंतर्निहित प्रणालियां विभिन्न भंडारण प्रणालियों में इस प्रकार के स्नैपशॉट करने में सक्षम होने के संदर्भ में नहीं हैं। यह वास्तव में एक दिलचस्प शोध विषय है। मुझे उम्मीद है कि कोई व्यक्ति इस पर काम करेगा, लेकिन मैंने अभी तक उस समस्या के बारे में कोई ठोस जवाब नहीं दिया है।

वादिम : हाँ, हमें किसी प्रकार के साझा मल्टीवेरियन कॉनएरेन्सी कंट्रोल की आवश्यकता है ।

मार्टिन : बिल्कुल, वितरित लेनदेन प्रणालियों की तरह। XA वितरित लेन-देन से आपको वहां कुछ रास्ते मिलेंगे, लेकिन दुर्भाग्य से XA, जैसा कि खड़ा है, वास्तव में बहुत अच्छी तरह से अनुकूल नहीं है क्योंकि यह केवल तभी काम करता है जब आप लॉकिंग-आधारित संगामिति नियंत्रण का उपयोग कर रहे हों। इसका मतलब है कि यदि आप कुछ डेटा पढ़ते हैं, तो आपको उस पर एक लॉक लेना होगा ताकि आपके पास उस लॉक के दौरान कोई भी उस डेटा को संशोधित न कर सके। और उस तरह के लॉकिंग-आधारित संगामिति नियंत्रण में भयानक प्रदर्शन होता है, इसलिए आजकल कोई भी प्रणाली वास्तव में इसका उपयोग नहीं करती है। लेकिन अगर आपके पास वह लॉकिंग नहीं है तो आपको XA वितरित लेनदेन जैसी प्रणाली में आवश्यक अलगाव व्यवहार नहीं मिलेगा। तो शायद जो हमें चाहिए वह वितरित लेनदेन के लिए एक नया प्रोटोकॉल है जो स्नैपशॉट अलगाव को अलग-अलग प्रणालियों में अलगाव तंत्र के रूप में अनुमति देता है। लेकिन मुझे नहीं लगता कि मैंने ऐसा कुछ भी देखा है जो अभी तक लागू हो।

वादिम : हां, मुझे उम्मीद है कि कोई इस पर काम कर रहा है।

मार्टिन : हाँ, यह वास्तव में महत्वपूर्ण होगा। उदाहरण के लिए, microservices के संदर्भ में, उदाहरण के लिए: जिस तरह से लोग प्रचार करते हैं कि आपको microservices का निर्माण करना चाहिए, यह है कि प्रत्येक microservice का अपना भंडारण, अपना स्वयं का डेटाबेस है, और आपके पास एक सेवा सीधे दूसरे सेवा के डेटाबेस तक पहुँचने के लिए नहीं है, क्योंकि जो सेवा के इनकैप्सुलेशन को तोड़ देगा। इसलिए, प्रत्येक सेवा केवल अपने स्वयं के डेटा का प्रबंधन करती है।

उदाहरण के लिए, आपके पास उपयोगकर्ताओं को प्रबंधित करने के लिए एक सेवा है, और इसमें उपयोगकर्ताओं के लिए एक डेटाबेस है, और बाकी सभी जो उपयोगकर्ता के बारे में कुछ जानना चाहते हैं, उन्हें उपयोगकर्ता सेवा के माध्यम से जाना होगा। एनकैप्सुलेशन के दृष्टिकोण से यह अच्छा है: आप उदाहरण के लिए अन्य सेवाओं से डेटाबेस स्कीमा का विवरण छिपा रहे हैं।

But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.

Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.

Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.

Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?

Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.

Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.

Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.

What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.

Vadim : It's a different point of view to building systems.

Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.

---

Professional growth and development

Vadim : Do you think that conferences like Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.

Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to think about the systems they are building.

Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?

Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.

So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.

Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?

Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.

A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.

Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.

Martin : No problem, yeah, it's been nice talking to you.

Vadim : Let's meet at the conference .