फिल्म "अवर सीक्रेट यूनिवर्स: द हिडन लाइफ ऑफ़ द सेल" का एक शॉट

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

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

इसके अलावा, रूसी और विदेशी दोनों नियामकों की आवश्यकताएं बढ़ रही हैं।

वर्तमान जरूरतों को पूरा करने और भविष्य के उन्नयन की नींव रखने के लिए, हमने टारनटूल पर आधारित निवेश व्यवसाय का मूल विकास किया है।

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

पृष्ठभूमि

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

इसके अलावा, सिस्टम का कोड आधार पहले से पुराना है, क्योंकि कुछ उत्पाद 1990 के दशक के मध्य में उत्पन्न हुए थे। और कुछ क्षेत्रों में, इसने विकास प्रक्रिया को धीमा कर दिया, उत्पादकता के साथ समस्याएं थीं।

नई समाधान आवश्यकताएँ

व्यवसाय ने महसूस किया कि आगे के विकास के लिए तकनीकी विकास महत्वपूर्ण है। हमें कार्य सौंपे गए थे:

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

इसके अलावा, हमारे आर्किटेक्ट्स ने अपनी शर्तें तय की:

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

हमने मानक तरीका अपनाया: आवश्यकताओं को तैयार किया और खरीद विभाग से संपर्क किया। वहां से हमें उन कंपनियों की सूची मिली, जो सामान्य तौर पर हमारे लिए ऐसा करने के लिए तैयार हैं। उन्होंने सभी को कार्य के बारे में बताया, और उनमें से छह ने समाधान का आकलन प्राप्त किया।

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

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

अगला, मैं इस बारे में बात करूंगा कि हमारा सिस्टम कैसे विकसित हुआ, यह कैसे विकसित हुआ, हमने क्या किया और क्यों किया।

विकास

सबसे पहले, हमने सोचा कि हमारे मौजूदा सिस्टम से डेटा कैसे प्राप्त किया जाए। हमने तय किया कि HTTP हमारे लिए काफी उपयुक्त है, क्योंकि सभी मौजूदा सिस्टम एक दूसरे के साथ संवाद करते हैं, HTTP पर XML या JSON भेजते हैं।

हम अंतर्निहित टारेंटूल HTTP सर्वर का उपयोग करते हैं, क्योंकि हमें SSL सत्र समाप्त करने की आवश्यकता नहीं है, और इसका प्रदर्शन हमारे लिए पर्याप्त है।

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

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

सत्यापन के बाद, डेटा सहेजा जाना चाहिए। हम vshard के साथ ऐसा करते हैं (हमारे पास शार्क की भू-स्थानिक प्रतिकृतियां हैं)।

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

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

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

एक प्रमाणीकरण प्रणाली लागू की।

तब उन्होंने देखा कि हमारे समाधान में कई भूमिकाएँ क्रिस्टलीकृत थीं। एक भूमिका एक प्रकार का एग्रीगेटर है। एक नियम के रूप में, भूमिकाओं में उपकरणों के उपयोग के विभिन्न प्रोफाइल हैं:

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

यही है, भूमिकाओं की मदद से, हम क्लस्टर के एक-दूसरे हिस्सों से अलग हो जाते हैं जिन्हें एक-दूसरे से स्वतंत्र रूप से जोड़ा जा सकता है।

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

परिक्षण

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

हम परीक्षण संचालित विकास कैसे लागू करते हैं?

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

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

हालांकि, हम सभी में से अधिकांश तनाव परीक्षण से प्यार करते हैं, हम इसे सबसे महत्वपूर्ण मानते हैं और नियमित रूप से इसका संचालन करते हैं।

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

हम बहुत दुखी थे। हम सर्वर लोड को देखते हैं, और वे निष्क्रिय हो जाते हैं।

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

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

इसके अलावा, मेमोरी का उपयोग केवल आने वाले कनेक्शन और अस्थायी वस्तुओं को संसाधित करने के लिए किया गया था।

इसके विपरीत, भंडारण सर्वर पर, प्रोसेसर लोड बढ़ता है, लेकिन कनेक्शन को संभालने वाले सर्वरों की तुलना में बहुत अधिक धीरे-धीरे।

और मेमोरी खपत डेटा की भरी हुई मात्रा के प्रत्यक्ष अनुपात में बढ़ी।

सेवाएं

हमारे नए उत्पाद को विशेष रूप से एक एप्लीकेशन प्लेटफॉर्म के रूप में विकसित करने के लिए, हमने इस पर सेवाओं और पुस्तकालयों को तैनात करने के लिए एक घटक बनाया।

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

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

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

पुरानी व्यवस्था

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

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

नए सुधार

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

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

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

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

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

निष्कर्ष

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

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

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

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

लुआ के साथ कुछ भी गलत नहीं है। कोई भी व्यक्ति इस पर लिखना सीख सकता है: एक जावा डेवलपर, एक जावास्क्रिप्ट डेवलपर, एक पायथन डेवलपर, एक फ्रंट-एंड या बैक-एंड। हमारे पास इस पर लिखने वाले विश्लेषक भी हैं।

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

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

टारनटूल के आधार पर हमने अल्फ़ा-बैंक के निवेश व्यवसाय की कोर कैसे की