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

मार्टिन क्लेपमैन, कैम्ब्रिज विश्वविद्यालय में CRDT पर काम करने वाले और एल्गोरिदम के औपचारिक सत्यापन में शोधकर्ता हैं। 2017 में प्रकाशित उनकी पुस्तक डिजाइनिंग डेटा-इंटेंसिव एप्लिकेशन डेटा संग्रहण और प्रसंस्करण में एक बेस्टसेलर बन गई है।

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

अकादमिक अनुसंधान शुरू करने से पहले, मार्टिन ने उद्योग में काम किया और दो सफल स्टार्टअप की स्थापना की: रैपॉर्टिव (2012 में लिंक्डइन द्वारा खरीदा गया) और गो टेस्ट इट (रेडगेट द्वारा खरीदा गया)।

यह हैबरपोस्ट मार्टिन के साथ एक विस्तृत साक्षात्कार है। नमूना चर्चा विषय:

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

साक्षात्कार का संचालन वादिम टायस्को ( @incubos ) द्वारा किया गया था - जो ओडनोक्लास्नेन प्लेटफ़ॉर्म कंपनी की टीम में एक प्रमुख डेवलपर था। वादिम के वैज्ञानिक और इंजीनियरिंग हित वितरित सिस्टम और डेटा वेयरहाउस के साथ-साथ सॉफ्टवेयर सिस्टम के सत्यापन से संबंधित हैं।

व्यवसाय से लेकर अकादमिक शोध तक

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

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

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

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

मार्टिन : धन्यवाद, मुझे खुशी है कि यह काम आया।

वादिम : यह संभावना नहीं है कि हमारे पाठक अभी तक इससे परिचित नहीं हैं, लेकिन सिर्फ मामले में, वितरित सिस्टम के क्षेत्र में सबसे महत्वपूर्ण उपलब्धियों पर चर्चा करते हैं, जिनके बारे में आप लिख रहे हैं।

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

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

सामान्य ज्ञान बनाम कृत्रिम प्रचार और उपकरण विज्ञापन

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

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

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

अनावश्यक कैप सिद्धांत और अन्य उद्योग गलतियाँ

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

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

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

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

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

वादिम : डेटा-इंटेंसिव एप्लिकेशन विकसित करने में सबसे तीव्र समस्याएं क्या हैं? सबसे सक्रिय रूप से कौन से विषय हैं? जहाँ तक मुझे पता है, आप विकेंद्रीकृत कंप्यूटिंग और विकेंद्रीकृत डेटा वेयरहाउसिंग के समर्थक हैं।

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

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

वादिम : चूंकि आपने ब्लॉकचेन का उल्लेख किया था, तो क्या आप हमें विकेंद्रीकृत प्रणालियों के क्षेत्र में होनहार या प्रसिद्ध तकनीकों के बारे में नहीं बता सकते थे? मैं खुद आईपीएफएस के साथ खेला था, लेकिन आपके पास इस क्षेत्र में बहुत अधिक अनुभव है।

मार्टिन : वास्तव में, मैं ऐसी तकनीकों का सक्रिय रूप से पालन नहीं करता हूं। मैं IPFS के बारे में थोड़ा पढ़ता हूं, लेकिन मैंने इसे स्वयं उपयोग नहीं किया है। हमने डाट के साथ थोड़ा काम किया, जो आईपीएफएस की तरह एक विकेन्द्रीकृत भंडारण तकनीक है। अंतर यह है कि Filecoin cryptocurrency IPFS से बंधा हुआ है, और इसका उपयोग डेटा भंडारण के लिए भुगतान करने के लिए किया जाता है, और कोई ब्लॉकचेन डाट से बंधा नहीं है। Dat आपको केवल P2P के आधार पर कई मशीनों के डेटा को दोहराने की अनुमति देता है, और जिस प्रोजेक्ट पर हम काम कर रहे थे, उसके लिए Dat बहुत बढ़िया है। हमने उपयोगकर्ताओं के लिए एक दस्तावेज़, डेटा या डेटाबेस पर सहयोग करने के लिए सॉफ़्टवेयर लिखा है, और इस डेटा में प्रत्येक परिवर्तन उन सभी को भेजा जाता है जिनके पास डेटा की एक प्रति है। ऐसी प्रणाली में, P2P सिद्धांत के अनुसार Dat का उपयोग किया जा सकता है, ताकि यह नेटवर्क स्तर पर ऑपरेशन को सुनिश्चित करे, अर्थात NAT Traversal और फायरवॉल से गुजरना, जो एक कठिन काम है। इसके शीर्ष पर, हमने CRDT से एक स्तर लिखा, जिसकी मदद से कई लोग एक दस्तावेज़ या डेटासेट को संपादित कर सकते हैं और जिससे संपादन को जल्दी और आसानी से साझा करना संभव हो गया। मुझे लगता है कि एक समान प्रणाली IPFS के शीर्ष पर लिखी जा सकती है, जबकि फिल्कोइन की अनदेखी और केवल पी 2 पी प्रतिकृति का उपयोग करना।

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

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

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

नई CRDT, इसाबेल में औपचारिक सत्यापन

वादिम : क्या आप हमें इसके बारे में और बता सकते हैं? क्या आप 100x से अधिक डेटा कम्प्रेशन प्राप्त करने में सफल रहे हैं? क्या आप नई संपीड़न तकनीकों या विशेष CRDTs के बारे में बात कर रहे हैं?

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

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

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

वादिम : क्या आप इस प्रणाली के लिए कोक या इसाबेल जैसे प्रमेय प्रमाणों का उपयोग करते हैं?

मार्टिन : हाँ, इसाबेल ।

संपादकों ने ध्यान दिया: मार्टिन द स्ट्रेंज लूप में इसाबेल के बारे में एक बात पढ़ेंगे ।

वादिम : क्या आप इस साक्ष्य को प्रकाशित करने की योजना बना रहे हैं?

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

वादिम : एल्गोरिथम के कोड आकार की तुलना में औपचारिक प्रमाण की मात्रा कितनी अधिक है? इसे लेकर कई बार मुश्किलें आती हैं।

मार्टिन : वास्तव में काफी मुश्किलें हैं, हमें सबूतों के साथ बहुत काम करना होगा। : 60 , , 800 . , 12 . , . , . , . . , .

: , ? ?

: , . , . : TCP, Git . , , . , . . , .

Event sourcing, , XA-

: , . , event sourcing. , - . event sourcing ? - , .

: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .

event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.

, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .

: . , , , , .

: , , JSON (, PostgreSQL ) . , . . , .

: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .

: , , , — ?

: . , , , , , 404, .

: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .

: , Multiversion Concurrency Control .

: , . XA-, , , . , , . , , . XA . , , . .

: , - .

: , . , , , . , . - , . , . - , : , , , . . , .

: , . , . - , , , - .

: . . , , . , .

: , . event sourcing. , , , . , . , , , . , , , , , . ?

: , . , , . , , , , . . , . , , .

: , , , .

: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .

: . .

: .

: , , . , — , . .

Hydra 2019,

: , Hydra? , , , .

: , , , , « » « ». . . , , - ; , , , , .

: , , , ? . , , ?

: , . , . , . - . , - , - . , . : , . — , — . , , , .

: . ? , - , , ?

: . . , . , , , . - — . , , . : . , , Slack , . , , . , , , .

: .

: , .

: , !

मैं आपको याद दिलाता हूं कि यह एक पूर्व-दर्ज साक्षात्कार है। जब आप टिप्पणी लिखते हैं, तो याद रखें कि मार्टिन उन्हें नहीं पढ़ेंगे। हम केवल कुछ सबसे दिलचस्प संदेश दे सकते हैं। यदि आप वास्तव में लेखक के साथ बात करना चाहते हैं, तो वह सेंट पीटर्सबर्ग में 11-12 जुलाई, 2019 को होने वाले हाइड्रा 2019 सम्मेलन में एक प्रस्तुति "वितरित सहयोग के लिए उपयोगकर्ता उपकरणों में डेटा समन्वयित" करेगा। टिकट आधिकारिक वेबसाइट पर खरीदे जा सकते हैं।