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

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

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

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

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

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

पृष्ठभूमि

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

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

नए समाधान के लिए आवश्यकताएँ

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

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

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

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

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

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

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

आगे मैं आपको बताऊंगा कि हमारा सिस्टम कैसे विकसित हुआ, कैसे विकसित हुआ, हमने क्या किया और वास्तव में ऐसा क्यों हुआ।

डिज़ाइन

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

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

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

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

सत्यापन के बाद, डेटा को सहेजा जाना चाहिए। हम इसे vshard का उपयोग करके करते हैं (हमारे पास शार्ड की भू-फैली हुई प्रतिकृतियां हैं)।

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

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

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

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

फिर हमने देखा कि हमारे निर्णय में कई भूमिकाएँ स्पष्ट थीं। भूमिका एक प्रकार से कार्यों का समूहक है। आमतौर पर, भूमिकाओं में अलग-अलग उपकरण उपयोग प्रोफ़ाइल होती हैं:

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

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

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

परीक्षण

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

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

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

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

हालाँकि, जो चीज़ हमें सबसे अधिक पसंद है वह है लोड टेस्टिंग; हम इसे सबसे महत्वपूर्ण मानते हैं और इसे नियमित रूप से करते हैं।

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

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

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

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

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

इसके विपरीत, स्टोरेज सर्वर पर, प्रोसेसर लोड बढ़ गया, लेकिन कनेक्शन प्रोसेस करने वाले सर्वर की तुलना में बहुत धीमा।

और मेमोरी की खपत लोड किए गए डेटा की मात्रा के सीधे अनुपात में बढ़ी।

सेवाएं

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

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

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

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

पुरानी प्रणालियाँ

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

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

नए सुधार

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

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

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

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

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

निष्कर्ष

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

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

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

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

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

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

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

स्रोत: www.habr.com