👣 👏🏻 🧙🏿 एक मोनोलिथ की कहानी। भाग २ 🤱 🚙 👾

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

पिछले लेख का एक संक्षिप्त सारांश

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

स्रोत डेटा

इसलिए, हमारे पास प्रवेश द्वार पर:

एक ही डेटा के कई स्रोत;
विभिन्न प्रसव के तरीके (फायरबर्ड, बस, एफ़टीपी, रेस्टापी);
एक ही वस्तुओं की अलग संरचना;
डेटा संरचना में निरंतर परिवर्तन;
विभिन्न प्रारूप (डेटाबेस, XML, JSON में कच्चा डेटा)।

उपभोक्ता की दृष्टि से:

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

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

और सब कुछ लगातार बदल रहा है, जोड़ा, हटा दिया गया है।

और परिवर्तन की इस अंतहीन धारा में न डूबने के लिए, निर्यात वास्तुकला विकसित करते समय, हमें कई मुख्य क्षेत्रों पर ध्यान केंद्रित करना था:

डेटा स्रोत;
वितरण के तरीके;
एल्गोरिदम प्रसंस्करण;
उपभोक्ता डेटा प्रारूप।

हम विभिन्न स्रोतों और डेटा प्रारूपों से सार करते हैं

विभिन्न स्रोत निम्नलिखित कठिनाइयों का परिचय देते हैं:

वे विभिन्न स्वरूपों में एक ही डेटा देते हैं;
किसी एक डोमेन ऑब्जेक्ट को कम करने के लिए आवश्यक संस्थाओं या विशेषताओं का एक अलग सेट है।

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

इंटरफ़ेस उदाहरण:

public interface ISource : IDisposable { ISourceReader GetDeletedRows(); ISourceReader GetInsertedOrUpdatedRows(); byte[] GetDataVersion(); } public interface ISourceReader : IDisposable { bool Read(); object this[string columnName] { get; } }

फर्मों को प्राप्त करने के कार्यान्वयन का एक उदाहरण:

 internal class FirmSetSource : ISource { public ISourceReader GetDeletedRows() { if(_lastDataVersion == null) return null; var query = DataContext.ExecuteObject<EsbFirmDeleted>(_lastDataVersion); return new DeletedIdsSourceReader<long>( query.Select(x => x.Id).GetEnumerator()); } public ISourceReader GetInsertedOrUpdatedRows() { return new EnumeratorSourceReader(typeof(FirmSet), GetNewOrChangedRows().GetEnumerator()); } public virtual byte[] GetDataVersion() { return DataContext.ExecuteObject<EsbFirm>().Max(x => x.RowVersion); } }

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

डोमेन मॉडल

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

हम डेटा वितरण की विधि से सार करते हैं

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

इस चिड़ियाघर में एकरूपता लाने के लिए, हम एक और डेटाबेस जोड़ेंगे, जिसमें हम सभी स्रोतों से सभी डेटा को मर्ज करेंगे।

आपको ऐसी तस्वीर मिलती है।

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

इसके अलावा, ISource के माध्यम से निर्यात ने DGPP या EMDB से शहर डेटा को अपने स्थिर सिंक डेटाबेस में खींच लिया और इसे अपने डोमेन मॉडल में बदल दिया।

तब यह केवल उन्हें संसाधित करने और उपभोक्ता प्रारूपों में अपलोड करने के लिए बना रहता है।

डेटा तैयारी एल्गोरिदम से सार

और यहाँ एक और कठिनाई पैदा होती है। सबसे पहले, विभिन्न उपभोक्ता अपने प्रारूपों में डेटा चाहते हैं। इसके अलावा, वे अलग-अलग डेटा सेट चाहते हैं। और उपांग में, ऑफ़लाइन डेटा जितना संभव हो उतना कॉम्पैक्ट और संरचित होना चाहिए ताकि उन्हें जल्दी से पढ़ा जा सके। नतीजतन, हमें द्विआधारी प्रारूप मिलते हैं जो अंतिम उत्पादों की टीमों द्वारा विकसित किए जाते हैं। और ये वे लोग हैं जो पूरी तरह से अलग प्रौद्योगिकी स्टैक पर काम करते हैं। हमारे पास .NET बैकएंड और कभी-कभी जावा विकसित करने के लिए परिचित और प्रिय हैं, उनके पास मुख्य रूप से C ++ और अजगर है।

सामान्य तौर पर, प्रौद्योगिकी का एक चिड़ियाघर।

तीव्र विकास के भोर में, जब हमारे पास केवल DGPP (पिछला लेख देखें ) और 2GIS का पीसी संस्करण था, अंतिम डेटा का प्रारूप एक बिनर था, जिसे C ++ में लिखी गई एक विशेष लाइब्रेरी द्वारा तैयार किया गया था और एक COM ऑब्जेक्ट से लपेटा गया था। यह विषम कोड के एकीकरण से प्रतीत नहीं होगा। हम संदर्भ कनेक्ट करते हैं, .NET इंटरफ़ेस उत्पन्न होता है - और इसे हटा दिया। और पहली बार हमने किया।

लेकिन, हमेशा की तरह, कुछ समस्याएं सामने आईं।

हमारा डेटा तेजी से बढ़ने लगा। नए प्रकार के डेटा दिखाई दिए, मास्को जैसे नए बड़े शहर।
X64-bit OS सक्रिय रूप से फैलने लगा।
COM में समस्याओं को किसी तरह डिबग किया जाना चाहिए।

अंक के माध्यम से चलते हैं।

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

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

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

परिणामस्वरूप, हमारी मूल .NET प्रक्रिया पूरी तरह से किसी भी सीपीयू बन गई। तृतीय-पक्ष कोड में कोई स्मृति लीक या महत्वपूर्ण त्रुटियां अब इसे प्रभावित नहीं करती हैं। निर्यात ने डेटा तैयार किया, इसे एक मध्यवर्ती फ़ाइल पर अपलोड किया, इसे उपयोगिता के लिए खिलाया और परिणाम भी एक फ़ाइल के रूप में प्राप्त किया। तृतीय-पक्ष टीमों के लोगों ने अपनी एल्गोरिदम को अपनी भाषाओं (C ++ या पायथन) में लिखा और निर्यात शुरू करने की आवश्यकता के बिना उनकी मशीन पर त्रुटियों के मामले में वास्तविक डेटा पर उन्हें डीबग कर सकते थे।

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

मध्यवर्ती पाठ प्रारूप उदाहरण

परिणाम

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

इंटरफेस के पीछे डेटा स्रोतों तक पहुंच का विवरण छिपाया;
मध्यवर्ती भंडारण का उपयोग करके डेटा वितरण चैनलों से सार;
अपना स्थिर डोमेन बनाएं और मूल डेटा को इसमें परिवर्तित करें;
प्रक्रियाओं में डेटा प्रोसेसिंग के व्यक्तिगत चरणों और अन्य भाषाओं में कोड का इस्तेमाल किया।

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

एक मोनोलिथ की कहानी। भाग २