🍼 🔔 🦉 हाईलाड ++, अनास्तासिया त्सिम्बल्युक, स्टानिस्लाव टसेलोवल्निकोव (सेबरबैंक): कैसे एएए बन गया ⛺️ ☪️ 🏷️

अगला हाईलोअड ++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में होगा।
विवरण और टिकट यहां देखें । हाईलाड ++ साइबेरिया 2019. हॉल "क्रास्नोयार्स्क"। 25 जून, दोपहर 2 बजे। सार और प्रस्तुति ।

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

हम एक मेटाडेटा प्रबंधन प्रणाली के निर्माण के उदाहरण पर बताएंगे कि कैसे कम समय में एक औद्योगिक स्केलेबल प्रणाली का निर्माण किया जाए, जिसमें डेटा का भंडारण और प्रसार शामिल है।

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

हम आपको बताएंगे कि यह हमारी टीम में कैसे काम करता है: हम किन नियमों का पालन करते हैं, हम किन साधनों का उपयोग करते हैं, हमें किन कठिनाइयों का सामना करना पड़ा है और हम कैसे उन्हें पार पाते हैं।

अनास्तासिया त्सम्बल्युक (इसके बाद - एसी): - मेरा नाम नास्त्य है, और यह स्टास है!

Stas Tselovalnikov (इसके बाद - SC): - सभी को नमस्कार!

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

SC: - नास्ता, एमडीए क्या है?

AC: - Stas, मुझे लगता है कि हम आसानी से इस पर आगे बढ़ेंगे। अधिक सटीक रूप से, मैं प्रस्तुति के अंत में इस बारे में थोड़ी बात करूंगा। पहले हमारे बारे में बात करते हैं:

मैं खुद को औद्योगिक आईटी समाधानों में तालमेल के एक साधक के रूप में वर्णन कर सकता हूं।

SC: - और मैं?

SberData टीम क्या करती है?

एसी: - और आप सिर्फ एक औद्योगिक मास्टोडन हैं, क्योंकि आप प्रोम में एक से अधिक समाधान लाए हैं!

SC: - वास्तव में, हम एक ही टीम में Sberbank में एक साथ काम करते हैं और SberData मेटाडेटा का प्रबंधन करते हैं:

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

बस ये कार्य मेटाडेटा द्वारा हल किए जाते हैं। वे हमें व्यावसायिक संदर्भ और डेटा के तकनीकी घटक को दिखाते हैं, अर्थात्, वे कहां दिखाई दिए, कैसे रूपांतरित हुए, न्यूनतम विवरण किस बिंदु पर है, मार्कअप अब है। यह डेटा का उपयोग शुरू करने और उस पर भरोसा करने के लिए पहले से ही पर्याप्त है। यह ठीक कार्य मेटाडेटा हल है।

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

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

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

मॉडल मेटाडेटा प्रबंधन प्रणाली

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

व्यापार शब्दावली स्तर।
तार्किक मॉडल का स्तर।
भौतिक मॉडल का स्तर।
पर्यावरण की वह स्थिति जो हमें औद्योगिक वातावरण के उलट होने के कारण मिली।

और यह सब लगातार होना चाहिए।

एसी: - हाँ, वास्तव में। लेकिन यहाँ मैं किसी भी तरह से एक सरल तरीके से समझाऊंगा, क्योंकि मैं इस बात को बाहर नहीं करता हूं कि विषय क्षेत्र अस्पष्ट और समझ में नहीं आता है ... एक

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

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

भौतिक मॉडल के बारे में है जब यह कठोर प्रोग्रामर की बारी है, आर्किटेक्ट जो वास्तव में समझते हैं कि इन वस्तुओं को कैसे उतारा जाए - किस तालिका में रखा जाए, कौन से फ़ील्ड बनाएं, किस इंडेक्स को लटकाएं ...

पर्यावरण की स्थिति एक तरह का कास्ट है। यह एक कार से एक गवाही की तरह है। एक प्रोग्रामर कभी-कभी मशीन को एक बात बताना चाहता है, लेकिन वह गलत समझती है। बस पर्यावरण की स्थिति हमें मामलों की वास्तविक स्थिति दिखाती है, और हम लगातार हर चीज की तुलना करते हैं; और हम समझते हैं कि प्रोग्रामर ने जो कहा और पर्यावरण की वास्तविक स्थिति के बीच अंतर है।

मेटाडेटा का वर्णन करने के लिए मामला

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

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

वह कहता है: "सुनो, यहाँ तुम्हें पूरी कहानी को अलग-अलग खातों में संस्थाओं के रूप में विभाजित किया गया है, और उनके पास एक विशेषता है - औसत संतुलन।"

इसके बाद वास्तुकार आता है और कहता है: “हम कानूनी संस्थाओं को ऋण का प्रदर्शन करेंगे। तदनुसार, हम व्यक्तिगत खातों की एक भौतिक तालिका बनाएंगे, हम व्यक्तिगत खातों पर दैनिक शेष राशि की भौतिक तालिका बनाएंगे (क्योंकि वे व्यापारिक दिन के समापन पर हर दिन प्राप्त होते हैं)। और महीने में एक बार समय सीमा पर हम अनुरोध के अनुसार औसत (मासिक शेष राशि की तालिका) की गणना करेंगे। "

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

मेटाडेटा स्तर पर पंजीकरण और भंडारण

एसी: - हमारे साथ सब कुछ कैसे संग्रहीत किया जाता है? यह उदाहरण का एक सुपर-सरलीकृत रूप है जिसे स्टास ने पहले चित्रित किया था! यह सब हमारे साथ कैसे होगा?

वास्तव में, यह ग्लोसरी ऑब्जेक्ट में एक लाइन, टर्म्स ऑब्जेक्ट में एक, एंटिटीज में एक, एट्रीब्यूट्स में एक, और इसी तरह एक लाइन होगी। ऊपर दिए गए आंकड़े में, प्रत्येक आयत हमारे नियंत्रण प्रणाली में एक वस्तु है, जो इस या उस जानकारी को वहां संग्रहीत करता है।

धीरे-धीरे आपको शब्दावली से परिचित कराने के लिए, मैं आपसे निम्नलिखित बातों पर ध्यान देने के लिए कहता हूं ... मेटाडेटा प्रबंधन वस्तु क्या है? शारीरिक रूप से, यह एक तालिका के रूप में प्रस्तुत किया जाता है, लेकिन वास्तव में, कुछ जानकारी वहाँ शर्तों, शब्दावलियों, संस्थाओं, विशेषताओं आदि पर संग्रहीत होती है। यह शब्द, "वस्तु," हम अपनी प्रस्तुति में उपयोग करना जारी रखेंगे।

अनुसूचित जाति: - यहां यह कहा जाना चाहिए कि प्रत्येक घन हमारे सिस्टम में सिर्फ एक टेबल है जहां हम मेटाडेटा स्टोर करते हैं, और हम इसे कंट्रोल ऑब्जेक्ट कहते हैं।

मेटाडेटा आवश्यकताएँ

प्रवेश द्वार पर हमारे पास क्या था? प्रवेश द्वार पर हमें काफी दिलचस्प आवश्यकताएं मिलीं। उनमें से बहुत सारे थे, लेकिन यहां हम तीन मुख्य दिखाना चाहते हैं:

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

डिफ़ॉल्ट रूप से - वर्तमान स्थिति;
तिथि के अनुसार;
संशोधन संख्या द्वारा।

दूसरी आवश्यकता अधिक दिलचस्प थी: हमें बताया गया था कि वे हमारे साथ वस्तुओं पर काम कर सकते हैं, लेकिन उन्हें जावा में बहुत अधिक कार्यक्रम करना होगा, लेकिन वे नहीं चाहते हैं। उन्होंने सुझाव दिया कि हम एक साथ 100 वस्तुओं (या 10) को मिलाते हैं, और हमें इस व्यवसाय को संभालना चाहिए (क्योंकि हम कर सकते हैं)। मिक्सिंग का क्या मतलब है? उदाहरण के लिए, 10 कॉलम आए। उनके पास तालिका पहचानकर्ता के लिए एक लिंक है, लेकिन हमारे पास तालिका स्वयं नहीं है - यह JSON की पूंछ पर आया था। "आप सोचते हैं और प्रक्रिया करते हैं - यह आवश्यक है कि आप कर सकते हैं"!

बढ़ती रुचि के क्रम में - तीसरा: "हम न केवल उस एपीआई का उपयोग करने में सक्षम होना चाहते हैं जो आप हमें बनाएंगे, बल्कि खुद को समझना चाहते हैं ..." और एक अनियंत्रित क्रम में कहते हैं: "हमें इस ऑब्जेक्ट से संघ को तीसरे ऑब्जेक्ट के माध्यम से दें। और अपने सिस्टम को स्वयं समझें कि यह सब कैसे करना है, डेटाबेस से पूछें और परिणाम JSON में वापस करें। "

प्रवेश द्वार पर हमारी ऐसी कहानी थी।

अनुमानित अनुमान

AC: - हमारी अनुमानित गणना के अनुसार, इस पूरी अवधारणा को लागू करने के लिए, प्रत्येक कंट्रोल ऑब्जेक्ट को सात इंटरफेस में भाग लेने के लिए आवश्यक है: सरल (सरल), ऑब्जेक्ट-बाय-राइट / रीड एंड डिलीट के लिए ...

तीन और - यूनिवर्सल राइट / रीड / डिलीट, टी के लिए। यही है, कि हम इसे किसी भी क्रम में फेंक सकते हैं और सूप सेट को सिस्टम में कैसे ट्रांसफर कर सकते हैं, और वह यह पता लगाएगी कि किस क्रम में डिलीट, पुट, रीड करना है।

एक और बात - एक पदानुक्रम बनाने के लिए ताकि हम सिस्टम को इंगित कर सकें - "हमें ऑब्जेक्ट से ऑब्जेक्ट पर वापस दें"; और यह नेस्टेड वस्तुओं का एक पेड़ देता है।

कार्यान्वयन जटिलता

एससी: - इस कहानी की शुरुआत के समय हमारे पास आई तकनीकी आवश्यकताओं के अलावा, हमें अतिरिक्त कठिनाइयाँ हुईं।

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

एसी: - यह बहुत ही अशांति है जिसे शुरुआत में घोषित किया गया था।

SC: - अगला ...

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

तीसरा विकास की एक बड़ी राशि है। नास्त्य ने अपनी स्लाइड में दिखाया कि जब हमने क्या और कैसे करना है, इसकी आवश्यकताओं को देखा, तो हमने महसूस किया: 1 वस्तु को सात एपीआई (या तो इसके लिए, या सात एपीआई में भागीदारी) की आवश्यकता होती है। इसका मतलब है कि अगर हमारे पास एक हफ्ते में 6 पैच (6 ऑब्जेक्ट, मॉडल, 42 एपीआई) हैं ...

मानक दृष्टिकोण

एसी: - हां, वास्तव में प्रति सप्ताह 42 एपीआई सिर्फ हिमशैल का टिप है। हम अच्छी तरह से जानते हैं कि यह सुनिश्चित करने के लिए कि ये ४२ एपीआई काम करते हैं, हमें इसकी आवश्यकता है:

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

स्वाभाविक रूप से, पहली चीज़ जो हमारे साथ हुई (शुरुआत में हमने आपको एक अनुमानित चित्र दिखाया) - हमारे पास लगभग 35 ऑब्जेक्ट थे। उनके साथ कुछ किया जाना था, यह सब घटाया जाना था, और बहुत कम समय था। और हमारे पास जो पहला विचार आया, वह था कि बैठकर, अपनी आस्तीन ऊपर रोल करें और कोडिंग शुरू करें।

कुछ दिनों के लिए इस मोड में काम करने के बाद भी (हमारी तीन टीमें थीं), हम इस तरह के चमकते तापमान पर पहुंचे ... हर कोई घबरा गया ... और हमें एहसास हुआ कि हमें एक अलग दृष्टिकोण की जरूरत है।

कस्टम दृष्टिकोण

हम ध्यान देने लगे कि हम क्या कर रहे हैं। इस दृष्टिकोण का विचार हमेशा हमारी आंखों के सामने रहा है, क्योंकि हम बहुत लंबे समय से मेटाडेटा में लगे हुए हैं। किसी भी तरह, यह हमारे लिए नहीं है ...

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

यही है, एक बार भ्रमित होने के लिए पर्याप्त है - एक टेम्पलेट बनाएं, और फिर मौजूदा और नई दोनों वस्तुओं के लिए इस सभी जानकारी का उपयोग करें। यहां हम एक और अवधारणा पेश करते हैं - #META_META। मैं समझाऊंगा कि क्यों, ताकि आपको भ्रमित न करें।

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

इतिहास और संशोधन सुनिश्चित करने के लिए तंत्र

SC: - आपने हमारे भाषण के बाकी हिस्सों को संक्षेप में प्रस्तुत किया है। हम और अधिक विस्तार से बताएंगे।

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

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

इसकी एक आईडी है - "7", एक नाम - carry_note, एक लिंक id_table 73, और एक फ़ील्ड - 255। हम समय बिंदु से प्राथमिक और वैकल्पिक कुंजी एक फ़ील्ड (प्रकार की तारीख) में दर्ज करते हैं, जहां से यह प्रविष्टि वैध - मान्य-ऑफफ्रॉम हो जाती है। और एक और क्षेत्र - किस तारीख तक यह रिकॉर्ड वैध (valid_to) है। इस मामले में, वे डिफ़ॉल्ट रूप से भरे हुए हैं - यह स्पष्ट है कि यह प्रविष्टि हमेशा सिद्धांत रूप में मान्य है। और यह तब तक होता है जब तक हम बदलना चाहते हैं, कहते हैं, क्षेत्र की लंबाई।
जैसे ही हम ऐसा करना चाहते हैं, हम valid_to रिकॉर्ड को बंद कर देते हैं (हम जिस टाइमस्टैम्प पर घटना को ठीक करते हैं) को ठीक करते हैं। उसी समय, हम एक नया रिकॉर्ड ("300") बनाते हैं। यह नोटिस करना आसान है कि इस स्थिति में, यदि आप वैलिड_फॉम और वैध_ के बीच "लड़ाई" (बीच में) से कुछ समय बिंदु से डेटाबेस को देखते हैं, तो हम उस समय एक भी रिकॉर्ड प्राप्त करेंगे, लेकिन प्रासंगिक। और एक ही समय में, हमने एक साथ कुछ संशोधन लॉग रखा:

इसमें हमने संशोधन दर्ज किए जो अनुक्रम (अनुक्रम) आईडी में बढ़ रहे हैं, और समय बिंदु जो इस संशोधन आईडी से मेल खाती है। इसलिए हम पहली मांग को बंद करने में सक्षम थे।

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

बैच अद्यतन

SC: - मेरे लिए दूसरी आवश्यकता थोड़ी अधिक रोचक थी। ईमानदारी से, जब यह प्रवेश द्वार पर आया, तो सबसे पहले मैं सिर्फ एक स्तूप में घुस गया। लेकिन फैसला आया है!

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

हमें पुनरावर्ती पदानुक्रमित प्रश्नों के तंत्र का उपयोग करने का एक तरीका मिला - यह सुनिश्चित करने के लिए है कि पूर्व निर्माण द्वारा अच्छी तरह से ज्ञात संपर्क। हमने इसे निम्नानुसार किया है: यहाँ हमारे उत्पादन कोड का एक टुकड़ा है:

इस बिंदु पर (एक लाल अंडाकार में परिक्रमा कोड का एक खंड) मुख्य बिंदु है जो एक विचार देता है। और यहाँ वस्तु एक विदेशी कुंजी द्वारा लिंक की गई दूसरी वस्तु से जुड़ी है, जो सिस्टम में है।

समझने के लिए: यदि कोई ओरेकल में कोड लिखता है, तो All_columns, All_all_ टेबल, All_constraint टेबल हैं - यह शब्दकोश है जिसे स्क्रिप्ट द्वारा संसाधित किया गया है (जैसे ऊपर स्लाइड में दिखाए गए हैं)।

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

उदाहरण के लिए, एक क्षेत्र - यह कैसा दिख सकता है? यह प्लेटफ़ॉर्म कोड है: oracle KP।, उत्पादन। केपी, my_scheme। केपी, my_table। केपी, आदि, जहां केपी क्षेत्र कोड है। तो ऐसा एक डिस्क्रिप्टर होगा।

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

वास्तव में, जैसा कि स्टास ने दिखाया, इस श्रृंखला की लंबाई 8-9 वस्तुओं तक पहुंचती है। उपयोगकर्ता, मानक दृष्टिकोण का उपयोग करते हुए, इन सभी ऑपरेशनों को बारी-बारी से करने की आवश्यकता है (ये सभी 9 ऑपरेशन) और उनके आदेश को स्पष्ट रूप से समझते हैं ताकि कोई त्रुटि न हो।

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

SC: - एक विवरणक! हैंडल जो हमने उस स्लाइड (पिछले) पर इंगित किया था।
और इस स्लाइड पर, बहुत समाधान दिया गया है:

डिस्क्रिप्टर का उपयोग सिस्टम में एक प्रकार के मेमनोनिक क्षेत्र के रूप में किया जाता है जो मौजूद नहीं है, लेकिन आईडी को बदल देता है। उस समय, जब पहली बार में सिस्टम समझता है कि तालिका सम्मिलित करना आवश्यक है - सम्मिलित करें, यह आईडी प्राप्त करेगा; और पहले से ही सम्मिलित और स्तंभ के लिए SQL क्वेरी उत्पन्न करने के चरण में, यह आईडी पर काम करेगा। उपयोगकर्ता भाप स्नान नहीं कर सकता है: "संभाल और निष्पादित करें!"। सिस्टम करेगा।

आवेदन प्रवेश बिंदु

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

आइए हम आपको विसर्जित करने के लिए बहुत शुरुआत करते हैं ... सिस्टम में मेटाडेटा को यहां कैसे प्रस्तुत किया जाएगा?

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

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

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

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

एसी: - अब हम इस बारे में बहस नहीं करेंगे। समय सीमा समाप्त होने से दो हफ्ते पहले, मैं इस तथ्य के साथ रहा कि मेरे हाथों पर ये तीन विधियां थीं (पिछली स्लाइड पर बाईं तरफ) जिसने सार्वभौमिक संरचना (उसी स्लाइड पर दाईं ओर) में हेरफेर किया।

मेरा पहला विचार बस एपीआई स्तर पर सब कुछ लपेटने और उपयोगकर्ता के पास जाने के लिए था, यह कहते हुए: “क्या शानदार बात है! तुम कुछ भी कर सकते हो! किसी भी ऑब्जेक्ट, या यहां तक कि कोई नहीं को स्थानांतरित करें। कूल, हाँ "?!

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

स्पेक। एक प्रस्ताव

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

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

SC:- इसका मतलब कहाँ है? आपके और मेरे पास मेटामेटा है, जो वास्तविक समय मोड में कर्नेल प्रदान करता है। वास्तविक समय निष्पादन में कर्नेल SQL क्वेरी उत्पन्न करता है जो डेटाबेस के साथ संचार करता है। सब कुछ है, न कि सिर्फ आपको क्या चाहिए। वस्तुओं के बीच संबंध भी हैं।

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

स्पेक। OAS + हैंडलबार्स

तो, यह

देखना आसान है कि क्या युक्ति शामिल है: आप OAS और हैंडलबार वेबसाइट पर जा सकते हैं (स्लाइड के नीचे) और देखें कि इसमें क्या होना चाहिए - इसमें एंडपॉइंट का सेट, विधियों का एक सेट और अंत में मॉडल हैं। कोड समय-समय पर दोहराया जाता है। प्रत्येक वस्तु के लिए, हमें लिखना होगा, डाल देना चाहिए। हटाना; वस्तुओं के समूह के लिए, हमें इसे और इसी तरह लिखना चाहिए।

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

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

आवेदन कोड। स्वैगर कोडजेन + हैंडलबार्स

यह सब हमने एनकोड किया, रिकॉर्ड किया, एक युक्ति बनाई। सब कुछ बहुत अच्छा और अच्छा था। हमें प्रत्येक वस्तु के लिए सभी 7 संभावित परिदृश्य मिले।

इसे उपयोगकर्ता को दिया। उसने कहा: “वाह! ठंडा! अब हम इसका इस्तेमाल करना चाहते हैं! ” क्या समस्या है, फिर से?

हमारे पास एक युक्ति है जो प्रत्येक विधि का विस्तार से वर्णन करती है, इसके साथ क्या करना है, किन वस्तुओं में हेरफेर करना है। और तीन मानक कर्नेल विधियाँ हैं जो ऊपर वर्णित तालिका को इनपुट के रूप में लेते हैं।

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

यह सब व्यवहार में लाने के लिए, हमें "नाममात्र" परिवर्तनों की आवश्यकता थी ...

रूपांतरण

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

यह उल्लेखनीय रूप से उत्पन्न होता है: सभी वर्ग विवरण हैं, सभी समापन बिंदु वर्णन हैं ... - यह काम करता है। आप इसे स्थानीय रूप से चला सकते हैं - यह काम करेगा। मुसीबत एक है: यह स्टब्स लौटाता है - प्रत्येक विधि वेतन वृद्धि नहीं है।

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

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

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

SC: - मैं आपको एक सेकंड के लिए रोक दूंगा, क्योंकि मैं पहले से ही खो जाना शुरू कर रहा हूं। मैं आपसे "क्या मैं इसे सही ढंग से समझता हूं" की शैली में पूछेंगे ...

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

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

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

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

ट्यूनिंग मेटामेटा

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

केवल हमने कुछ छोटी चीजें वहां जोड़ दीं - प्रकार, प्रारूप, स्वीकार्य मूल्यों की सूची, पैटर्न, उदाहरण। यह उपयोगकर्ताओं को भी प्रसन्न करता है - वे पहले से ही स्पष्ट रूप से समझते हैं कि क्या डाला जा सकता है, क्या नहीं। हम उपयोगकर्ता को एक क्लाइंट विरूपण साक्ष्य भी प्रदान करते हैं, जो हमें हमारी सेवा के साथ संचार करते समय त्रुटियों को पकड़ने की अनुमति देता है (ठीक प्रारूप द्वारा, पहले से ही संकलन चरण में)।

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

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

परिणाम

SC: - यह शांत है, लेकिन बहुत सी थ्योरी है। क्या आप कुछ व्यावहारिक उदाहरण दे सकते हैं?

एसी: - हां, मैंने इसे विशेष रूप से तैयार किया है। सम्मेलन के लिए जाने से पहले, शुक्रवार शाम को, कार्य दिवस की समाप्ति से 5 मिनट पहले, स्टास ने मुझसे कहा: “ओह, देखो! मैंने एक मॉडल पैच जारी किया - कितना शांत! हमारी सेवा को अद्यतन करना अच्छा होगा। ” पैच में केवल दो ऑब्जेक्ट थे, लेकिन मैं समझता हूं कि पुराने दृष्टिकोण के साथ मुझे भ्रमित होना होगा और 7 एपीआई लिखना या जोड़ना होगा।

तुरंत ही मुझे यह सब जादू का काम करने के लिए एक बटन पर क्लिक करना पड़ा। मैं विशेष रूप से

उस स्थान पर लाल परिक्रमा करता हूं जहां जादू होने वाला है: मैं बटन पर क्लिक करता हूं ... ये बेशक स्क्रीनशॉट हैं, लेकिन वास्तव में सब कुछ इस तरह से काम करता है:

हमारे पास एक नया तरीका है (दोनों के बीच), जो पहले से ही डेटा देता है, जिसके द्वारा हम पदानुक्रम में संपूर्ण संरचना, सभी नेस्टेड ऑब्जेक्ट को क्वेरी कर सकते हैं:

और यह सब काम करता है! मैंने कोड की एक भी लाइन नहीं लिखी है।

सारांश

SC: - सबसे पहले, तथ्य क्या है? हमने सबसे जटिल तर्क को प्रबंधित किया, जो हमारे प्रोग्रामरों को सबसे अधिक समय लगेगा, 100% गतिशील कर्नेल कोड में पैक करने के लिए जो वस्तुओं के साथ काम कर सकते हैं - जो कि हैं और जो होंगे:

दूसरे, हमने एप्लिकेशन सर्वर स्तर पर सफलता प्राप्त की (जहां यह संभव नहीं है) कोड पीढ़ी के कारण प्रोग्रामिंग से बचने के लिए - वही बटन जो आपने प्रदर्शित किया था:

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

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

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

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

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

SC: - जब आप इस सवाल का जवाब देंगे तो मैं पूरी रिपोर्ट का इंतजार कर रहा हूं। आइए मेरी पसंदीदा स्लाइड्स पर चलते हैं।

फेसला। प्रक्रिया। इससे पहले

एसी: - “प्रक्रिया। पहले "- यह हमारा गौरव है, क्योंकि हम बहुत कार्यक्रम करते थे, लगभग कुछ भी नहीं खाते थे - हम बहुत बुरे थे। मुझे प्रत्येक वस्तु के लिए इन सभी 5 चरणों का प्रदर्शन करना

था : यह बहुत दुखद था और हमें बहुत समय लगा। अब हमने इस खाद्य श्रृंखला को तीन लिंक तक कम कर दिया है, जिनमें से सबसे महत्वपूर्ण है बस वस्तु को सही ढंग से बनाना, और अधिक कुछ नहीं:

मेटामाटा को एक बटन (अपडेट) द्वारा लॉन्च किया जाता है, फिर परीक्षण। हम वर्तमान में यह सुनिश्चित करना चाह रहे हैं कि कुछ भी हमसे दूर न हो जाए, क्योंकि हमने हाल ही में इस दृष्टिकोण को लागू करना शुरू किया था। हम इस पूरी प्रक्रिया को नियंत्रित करने की कोशिश कर रहे हैं।

अनुमान के अनुसार, हमारे सभी सॉफ्टवेयर के विकास के लिए हमारे सभी श्रम लागत 6 गुना कम हो गए हैं।

अनुसूचित जाति:- खुद से, मैं ईमानदारी से कहना चाहता हूं कि नंबर 6 को उड़ाया नहीं गया है, यह रूढ़िवादी भी है। वास्तव में, दक्षता और भी अधिक है।

भविष्य की योजनाएं

आपने हमारी योजनाओं पर ध्यान देने के लिए रिपोर्ट के अंत में पूछा। सबसे पहले, ऐसा लगता है कि हमें न केवल एक पूर्ण, बल्कि एक अलग और बॉक्सिंग समाधान प्राप्त करना होगा। इन तकनीकों को पास में कहीं लगाया जा सकता है, जहाँ उपयुक्त हो। मैं एक तैयार उत्पाद प्राप्त करना चाहूंगा जिसे विकसित किया जाएगा, और जिसे हम Sberbank की ओर से पेश कर पाएंगे।

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

नंबर 6 और मामला जो नास्त्य लाया - वे ईमानदार हैं। यह वास्तव में शुक्रवार को था, जब हमें दस्तावेज (विमान, यात्रा, आदि) प्राप्त करने की आवश्यकता थी। आसन्न टीम को सोमवार को परीक्षण के लिए निर्धारित किया गया था, और हमें इस पैच को जारी करने की आवश्यकता थी, न कि लोगों को सेट करने के लिए। इसने काम कर दिया! यह एक वास्तविक मामला है।

मुझे खुशी होगी अगर यह आपके किसी काम आ सके। यदि आपके कोई प्रश्न हैं, तो हम उपलब्ध हैं। और रिपोर्ट के बाद, यहाँ भी कुछ समय है। पूछना। हमें आपकी मदद करने में ख़ुशी होगी!

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

ये सभी उपकरण सार्वजनिक डोमेन में हैं - आप पहले से ही googling शुरू कर सकते हैं और समझ सकते हैं कि उनका उपयोग कैसे किया जाए। मुझे यकीन है कि उनका उपयोग करने से आपके जीवन को आसान, बेहतर, और आम तौर पर नए, महत्वाकांक्षी, शांत कार्यों के लिए खाली समय मिलेगा। धन्यवाद!

प्रशन

दर्शकों से प्रश्न (बाद में - ए): - क्या मैं सही ढंग से समझता हूं कि सब कुछ ढेर हो गया है क्योंकि आप एक रिलेशनल डेटाबेस का उपयोग करते हैं? यह मुझे लगता है कि यदि आप दस्तावेज़-उन्मुख डेटाबेस की ओर देखते हैं, तो यह सब समाधान आपके लिए बहुत आसान होगा जितना मैं अभी देख रहा हूं।

SC: - वास्तव में नहीं। जब हमने ग्लोरीरी स्तर पर काम करने वाले लोगों और प्रोमडर को जाने वाली मकड़ी के बारे में बात की थी, तो इन कहानियों और जांचों को पढ़ता है - वास्तव में, इस शब्दावली के लिए जिम्मेदार क्षेत्र के साथ तालिका प्रोम पर होती है । उन्होंने हमारी सेवा से कहा: "दोस्तों, आपके पास एक REST API होना चाहिए। आप कैसे करते हैं यह आपकी समस्या है। यहां अनुमत तकनीकों की एक सूची है - इस सूची में से कुछ का उपयोग करें (यह वही है जो हम Sberbank में उपयोग कर सकते हैं)। ”

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

यहां हमें कुछ और बात करनी चाहिए। एक अधिक जटिल कहानी: हम समायोजन / प्रमाणन डेटा सेट के साथ एक मॉडल पैच जारी करेंगे, और वहां 6 ऑब्जेक्ट हैं। और अनिवार्य रूप से, आपको एपीआई के इस सज्जन सेट को प्रदान करने के लिए, आपको काम करने के लिए तीन महीने (ऑफहैंड) की आवश्यकता है। इसमें हमें डेढ़ सप्ताह लगेगा। इन तकनीकों को लागू किए बिना, इन परिस्थितियों में जीवित रहना असंभव था। हम बस इस तरह की सेवा नहीं देंगे!

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

A: - मेरा एक दूसरा प्रश्न है। और जीवन से उपयोग का एक उदाहरण क्या है? मैं समझता हूं कि सैद्धांतिक रूप से ऐसा लगता है कि आप कम से कम पूरी दुनिया का वर्णन अपने META_META ऑब्जेक्ट के साथ कर सकते हैं ... लेकिन जीवन में, आप इसका उपयोग कैसे करते हैं? इसे कैसे लागू किया जाता है इसे देखते हुए (सब कुछ एक दूसरे में डाल दिया जाना चाहिए), इसे धीमा करना चाहिए!

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

ए: - मैं एक अधिक विशिष्ट उदाहरण पर भरोसा कर रहा था।

ए: - मुझे बताओ, कृपया, यह आपकी आवश्यकताओं में लिखा गया था कि आपको जटिल संरचनात्मक प्रश्न (सम्मिलित हों और इस तरह) करने की आवश्यकता है। यह किस भाषा में लागू किया गया है, या क्या आप इसे किसी तरह तार्किक रूप से वर्णित करते हैं?

अनुसूचित जाति:- REST एपीआई के माध्यम से प्रवेश, सबसे अधिक बार यह जावा है, हालांकि यह किसी भी भाषा हो सकता है। हमारी सेवा प्रकाशित हुई है (dhttps, https से पूछें - आपको JSON वापस मिल जाएगी)। हमारे द्वारा दिखाए गए कोड के टुकड़े SQL हैं। यह समझने के लिए कि इसे किस क्रम में संसाधित किया जाना चाहिए, हमने DBMS शब्दकोशों पर कुछ एसक्यूएल ट्यूनिंग की और इसे भौतिक प्रतिनिधित्व के रूप में एक अलग योजना में पार्क किया। तदनुसार, जब एक मॉडल पैच जारी किया जाता है, तो "ताज़ा किया गया दृश्य" बटन क्लिक किया जाता है (+ फ़ील्ड दिखाई देते हैं)। लेकिन वास्तव में हमारा कोड जावा और ओरेकल है।

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

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

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

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

SC: - हमारे पास एक प्रोटोकॉल है - दो अपडेट मोड हैं। उनमें से एक में आप झंडा लगा सकते हैं "वह सब लागू करें जो आप कर सकते हैं।" कुछ सॉफ्टवेयर है जो एक्सेल JSON में कनवर्ट करता है - 10 हजार लाइनें हो सकती हैं। और आप, सख्ती से बोल रहे हैं, दो लाइनें अमान्य (त्रुटि) हो सकती हैं। और या तो आप कहते हैं: "सब कुछ लागू करें जो आप कर सकते हैं"; या "केवल तभी लागू करें जब पूरी कहानी में एक भी त्रुटि नहीं होगी।" उदाहरण के लिए, अभिन्न स्थिति रोलबैक होगी। वास्तव में, एक सम्मिलित डेटाबेस के लिए किया जाता है, लेकिन प्रतिबद्ध नहीं कहा जाता है।

त्रुटि के मामले में - यह रोलबैक कहता है, यह प्रोटोकॉल में है; आप वैसे भी प्रोटोकॉल प्राप्त करते हैं। आपको प्रत्येक पंक्ति पर एक स्थिति मिलती है, और आपके पास एक अलग क्षेत्र में एक पहचानकर्ता है - या तो एक संख्या (ऑब्जेक्ट आईडी), या कुछ वैकल्पिक कुंजी, या दोनों। प्रोटोकॉल यह समझना संभव बनाता है कि मेरे अनुरोध का क्या हुआ।

AC: - उपयोगकर्ता स्वयं इंगित करता है कि उसे किन विकल्पों में जाना चाहिए। हम कोर के किनारे इस पैरामीटर को पास करते हैं, और कोर पहले से ही सभी जादू का उत्पादन करता है, हमें इसका जवाब देता है, और हम इसकी व्याख्या करते हैं।

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

अनुसूचित जाति:"जैसा कि मैंने सवाल समझा, मैं जवाब देने की कोशिश करूंगा।" अधिकांश कार्यक्रम अब हमारे साथ संवाद करता है। जब एकीकरण बातचीत का तंत्र स्थापित किया जाता है, तो बहुत से लोग हमारे साथ कार्यक्रमों के रूप में संवाद नहीं करते हैं। बेशक, ऐसे मामले हैं जब लोग प्राथमिक स्पिल के लिए ला एक्सेलनिक भेजते हैं: हम उनसे JSON बनाते हैं, अपलोड करते हैं, लेकिन यह एक प्राथमिक सेटिंग का अधिक है।

और हमारे पास एक मोड है जब आपने 5,000 लाइनें भेजी थीं, जिनमें से 4,900 ने स्थिति के साथ लौटाया "मैंने संसाधित किया, मुझे कोई बदलाव नहीं मिला, मैंने कुछ भी नहीं किया।" लेकिन यह प्रोटोकॉल में परिलक्षित होता है और कोई त्रुटि नहीं है। यह एक तरफ अतिरेक है।

हमारे पास यह पूरी कहानी तीसरे, सामान्य रूप के लिए लगभग अनुमानित रूप से संग्रहीत है, जो सिर्फ अनावश्यक रूप से अतिरेक नहीं करता है, जिसका उपयोग कुछ असामान्य संरचनाओं के विपरीत किया जाता है, उदाहरण के लिए, दुकान खिड़कियों के लिए।

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

हमने कोड की कितनी पंक्तियों की वजह से मापा नहीं है: "क्या आपने सेवा के प्रश्न और इसकी स्थिरता को हल किया है या नहीं?" आप बिल्कुल नहीं लिख सकते हैं - मुख्य बात यह है कि यह काम करता है। इस अर्थ में, ऐसा करना हमारे लिए सरल और अधिक सुविधाजनक था।

मैं एक विशिष्ट विक्रेता नहीं लेता, लेकिन संबंधपरक डेटाबेस 20 वर्षों से विकसित हो रहा है! यह सिर्फ ऐसा नहीं है। उदाहरण के लिए, विंडोज पर वर्ड या एक्सेल - आप वहां उस कोड को प्रोग्राम नहीं करते हैं, जिसकी मदद से "असेंबलर" एक्सेस करता है और एक फाइल लिखने के लिए हार्ड ड्राइव के हेड्स को मूव करता है ... वही यहाँ है! हमने सिर्फ उन विकासों का उपयोग किया जो आरडीबीएमएस में थे, और यह सुविधाजनक था।

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

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

एसी:- हमारे पास ऑपरेशन के दो तरीके हैं। एक तब होता है जब डेवलपर्स स्वयं या टीमों को स्वयं REST सेवाओं के माध्यम से मेटाडेटा को सिस्टम में बुलेट करने के लिए मजबूर किया जाता है। ऑपरेशन का दूसरा तरीका यह है कि एक ही "वैक्यूम क्लीनर": हम खुद पर्यावरण में जाते हैं और वहां से सभी संभव मेटाडेटा लेते हैं। हम दिन में एक बार ऐसा करते हैं, और बस यह देखें कि डेवलपर्स ने हमें क्या भेजा है।

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

जैसा कि नस्त्या ने कहा, रिवर्स के साथ कहानी के बारे में (तकनीकी शब्दजाल में हम इसे "वैक्यूम क्लीनर" कहते हैं), हम औद्योगिक वातावरण में जाते हैं और कुछ डेटा पढ़ते हैं। अलग-अलग मामले हैं - हम बाद में चर्चा करने के लिए तैयार हैं, हम कई दिलचस्प कहानियां बताने के लिए तैयार हैं।

A: - मैं वित्तीय प्रौद्योगिकी के केंद्र से हूं। मैंने वहां एक परिचित शब्द देखा - मुख्य DACUM। हमारे मंच का अपना मेटाडेटा है। आप कैसे मित्र हैं - इस मामले में सीधे Oracle टेबल या हमारे मेटाडेटा के साथ? क्योंकि हमारे मामले में, ओरेकल टेबल के साथ दोस्त होना पूरी तरह से सांकेतिक नहीं है।

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

विज्ञापन का एक सा :)

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या अपने दोस्तों को सलाह देकर, $ 4.99 से डेवलपर्स के लिए क्लाउड VPS , एंट्री-लेवल सर्वरों का एक अनूठा एनालॉग , जो आपके लिए हमारे द्वारा आविष्कार किया गया था, का समर्थन करें: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?

हाईलाड ++, अनास्तासिया त्सिम्बल्युक, स्टानिस्लाव टसेलोवल्निकोव (सेबरबैंक): कैसे एएए बन गया