अझै पनि फिल्म "हाम्रो सीक्रेट ब्रह्माण्ड: सेलको हिडन लाइफ" बाट

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

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

थप रूपमा, रूसी र विदेशी दुवै नियामकहरूको आवश्यकता बढ्दै गएको छ।

वर्तमान आवश्यकताहरू पूरा गर्न र भविष्यको स्तरवृद्धिको लागि आधारशिला राख्नको लागि, हामीले टारन्टुलमा आधारित लगानी व्यवसाय कोर विकास गरेका छौं।

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

प्रागितिहास

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

थप रूपमा, प्रणालीहरूको कोड आधार पहिले नै पुरानो भइसकेको छ, किनभने केही उत्पादनहरू मध्य-1990 मा उत्पन्न भएका थिए। र केहि क्षेत्रहरूमा यसले विकास प्रक्रियालाई सुस्त बनायो, र त्यहाँ कार्यसम्पादन समस्याहरू थिए।

नयाँ समाधानका लागि आवश्यकताहरू

व्यवसायहरूले महसुस गरेका छन् कि प्राविधिक रूपान्तरण थप विकासको लागि महत्त्वपूर्ण छ। हामीलाई कार्यहरू दिइएको थियो:

1. एकल, छिटो भण्डारण र एकल डेटा मोडेलमा सबै व्यापार डेटा सङ्कलन।
2. हामीले यो जानकारी गुमाउनु वा परिवर्तन गर्नु हुँदैन।
3. यो डाटा संस्करण गर्न आवश्यक छ, किनकि कुनै पनि क्षणमा नियामकले अघिल्लो वर्षका लागि तथ्याङ्कहरू सोध्न सक्छ।
4. हामीले केही नयाँ, फैशनेबल DBMS मात्र ल्याउनु हुँदैन, तर व्यापार समस्याहरू समाधान गर्न प्लेटफर्म सिर्जना गर्नुपर्छ।

थप रूपमा, हाम्रा आर्किटेक्टहरूले आफ्नै सर्तहरू सेट गर्छन्:

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

हामीले मानक मार्ग अनुसरण गर्यौं: हामीले आवश्यकताहरू तयार गर्यौं र खरिद विभागलाई सम्पर्क गर्यौं। त्यहाँबाट हामीले कम्पनीहरूको सूची प्राप्त गर्‍यौं जुन, सामान्यतया, हाम्रो लागि यो गर्न तयार छन्। हामीले समस्याको बारेमा सबैलाई भन्यौं, र ती मध्ये छ वटाबाट समाधानको मूल्याङ्कन प्राप्त गर्‍यौं।

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

हामीले कसरी सबै कुराको परीक्षण गर्यौं र कति समय लाग्यो भनेर म तपाईंलाई बताउँदिन, म केवल संक्षेप गर्नेछु: लोड परीक्षणहरूमा उत्कृष्ट प्रदर्शन Mail.ru समूह विकास टोलीको Tarantool मा आधारित प्रोटोटाइप समाधानद्वारा देखाइएको थियो। हामीले सम्झौतामा हस्ताक्षर गरेर विकास सुरु गर्‍यौं। त्यहाँ Mail.ru समूहबाट चार व्यक्तिहरू थिए, र Alfa-Bank बाट तीन विकासकर्ताहरू, तीन प्रणाली विश्लेषकहरू, एक समाधान आर्किटेक्ट, एक उत्पादन मालिक र एक Scrum मास्टर थिए।

अर्को म तपाइँलाई हाम्रो प्रणाली कसरी बढ्यो, यो कसरी विकसित भयो, हामीले के गर्यौं र वास्तवमा किन यो बारे बताउनेछु।

विकास

हामीले आफैलाई सोधेको पहिलो प्रश्न हाम्रो हालको प्रणालीबाट डाटा कसरी प्राप्त गर्ने भन्ने थियो। हामीले निर्णय गर्यौं कि HTTP हाम्रो लागि एकदम उपयुक्त छ, किनभने सबै हालका प्रणालीहरूले HTTP मा XML वा JSON पठाएर एक अर्कासँग सञ्चार गर्छन्।

हामी Tarantool मा निर्मित HTTP सर्भर प्रयोग गर्छौं किनभने हामीलाई SSL सत्रहरू समाप्त गर्न आवश्यक छैन, र यसको प्रदर्शन हाम्रो लागि पर्याप्त छ।

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

रूपान्तरण पछि, डाटा हामीले सिर्जना गरिरहेको मोडेलको अनुपालनको लागि जाँच गर्नुपर्छ। हामीले लामो समयको लागि मोडेल कस्तो हुनुपर्छ र यसलाई वर्णन गर्न कुन भाषा प्रयोग गर्ने भनेर छलफल गर्‍यौं। हामीले Apache Avro छनोट गर्यौं किनभने भाषा सरल छ र यसमा Tarantool बाट समर्थन छ। मोडेल र अनुकूलन कोडको नयाँ संस्करणहरू दिनको कुनै पनि समयमा, लोड अन्तर्गत वा बिना, दिनको धेरै पटक सञ्चालनमा राख्न सकिन्छ, र धेरै चाँडै परिवर्तनहरू अनुकूलन गर्न सकिन्छ।

प्रमाणीकरण पछि, डाटा बचत गर्नुपर्छ। हामी यो vshard प्रयोग गरेर गर्छौं (हामीसँग शार्डहरूको भू-वितरित प्रतिकृतिहरू छन्)।

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

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

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

प्रमाणीकरण प्रणाली लागू गरियो।

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

• T-Connect: आगमन जडानहरू ह्यान्डल गर्दछ, CPU सीमित, कम मेमोरी खपत, स्टेटलेस।
• IB-Core: यसले Tarantool प्रोटोकल मार्फत प्राप्त गरेको डेटालाई रूपान्तरण गर्छ, अर्थात्, यो तालिकाहरूसँग सञ्चालन हुन्छ। यसले राज्य भण्डारण गर्दैन र मापनयोग्य छ।
• भण्डारण: केवल डाटा भण्डारण गर्दछ, कुनै तर्क प्रयोग गर्दैन। यो भूमिकाले सरल इन्टरफेसहरू लागू गर्दछ। स्केलेबल vshard लाई धन्यवाद।

त्यो हो, भूमिकाहरू प्रयोग गरेर, हामीले क्लस्टरका विभिन्न भागहरूलाई एकअर्काबाट अलग गर्यौं, जुन एकअर्काबाट स्वतन्त्र रूपमा मापन गर्न सकिन्छ।

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

परीक्षण गर्दै

परियोजनाको शुरुवातदेखि नै, हामीले परीक्षण संचालित विकास कार्यान्वयन गर्ने प्रयास गर्ने निर्णय गर्यौं। हामी टारान्टुल/ट्याप फ्रेमवर्क प्रयोग गरेर लुआमा एकाइ परीक्षणहरू लेख्छौं, र Pytest फ्रेमवर्क प्रयोग गरेर Python मा एकीकरण परीक्षणहरू। एकै समयमा, हामी दुबै विकासकर्ताहरू र विश्लेषकहरूलाई एकीकरण परीक्षण लेखनमा संलग्न गर्छौं।

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

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

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

यद्यपि, हामीलाई सबैभन्दा मनपर्ने कुरा लोड परीक्षण हो; हामी यसलाई सबैभन्दा महत्त्वपूर्ण मान्दछौं र यसलाई नियमित रूपमा लिन्छौं।

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

हामी धेरै दुखी थियौं। हामी सर्भर लोड हेर्छौं, तर तिनीहरू निष्क्रिय छन्।

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

मलाई फेरि व्याख्या गरौं। स्रोतहरू फरक तरिकाले प्रयोग गर्ने भूमिकाहरूमा विभाजनको कारणले गर्दा, जडानहरू र डेटा रूपान्तरण प्रशोधनका लागि जिम्मेवार हाम्रा भूमिकाहरूले प्रोसेसर मात्र लोड गर्छ, र कडा रूपमा लोडसँग समानुपातिक।

यस अवस्थामा, मेमोरी केवल आगमन जडानहरू र अस्थायी वस्तुहरू प्रशोधन गर्न प्रयोग गरिएको थियो।

यसको विपरित, भण्डारण सर्भरहरूमा, प्रोसेसर लोड बढ्यो, तर जडानहरू प्रक्रिया गर्ने सर्भरहरू भन्दा धेरै ढिलो।

र मेमोरी खपत डाटाको मात्राको प्रत्यक्ष अनुपातमा बढ्यो।

सेवाहरू

हाम्रो नयाँ उत्पादन विशेष गरी एप्लिकेसन प्लेटफर्मको रूपमा विकास गर्न, हामीले यसमा सेवाहरू र पुस्तकालयहरू प्रयोग गर्नका लागि एउटा कम्पोनेन्ट सिर्जना गरेका छौं।

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

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

हामी भण्डारणको लागि मात्र होइन, तर कम्प्युटिङको लागि पनि प्लेटफर्म हुन चाहन्थ्यौं। र हामीसँग पहिले नै प्रतिकृतिहरू र शार्डहरूको गुच्छा भएको हुनाले, हामीले एक प्रकारको वितरित कम्प्युटिङ लागू गर्‍यौं र यसलाई नक्सा कम भन्यौं, किनभने यो मूल नक्सा घटाउने जस्तै भयो।

पुरानो प्रणालीहरू

हाम्रा सबै लिगेसी प्रणालीहरूले हामीलाई HTTP मार्फत कल गर्न र GraphQL प्रयोग गर्न सक्दैनन्, यद्यपि तिनीहरूले प्रोटोकललाई समर्थन गर्छन्। त्यसकारण, हामीले एउटा संयन्त्र सिर्जना गर्यौं जसले डेटालाई यी प्रणालीहरूमा दोहोर्याउन अनुमति दिन्छ।

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

नयाँ सुधारहरू

तपाईलाई याद छ, व्यापारिक दृष्टिकोणबाट, हामीले एसिन्क्रोनस रेकर्डिङ गर्यौं। तर त्यसपछि तिनीहरूले महसुस गरे कि यो पर्याप्त हुनेछैन, किनभने त्यहाँ प्रणालीहरूको एक वर्ग छ जुन तुरुन्तै सञ्चालनको स्थितिको बारेमा प्रतिक्रिया प्राप्त गर्न आवश्यक छ। त्यसैले हामीले हाम्रो GraphQL विस्तार गर्यौं र उत्परिवर्तनहरू थप्यौं। तिनीहरू संगठित रूपमा डेटासँग काम गर्ने अवस्थित प्रतिमानमा फिट हुन्छन्। हाम्रो लागि, यो प्रणालीको अर्को वर्गको लागि पढ्ने र लेख्ने दुवैको एकल बिन्दु हो।

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

सबै कार्य समयतालिकामा चलाउन आवश्यक छैन। केही रिपोर्टहरू मागमा पढ्न आवश्यक छ। यो आवश्यकता आउने बित्तिकै, स्यान्डबक्समा एउटा कार्य सिर्जना गरिन्छ र कार्यान्वयनको लागि धावकलाई पठाइन्छ। केहि समय पछि, प्रयोगकर्ताले एक एसिन्क्रोनस प्रतिक्रिया प्राप्त गर्दछ कि सबै कुरा गणना गरिएको छ र रिपोर्ट तयार छ।

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

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

निष्कर्षमा

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

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

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

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

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

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

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

स्रोत: www.habr.com