अजूनही “अवर सिक्रेट युनिव्हर्स: द हिडन लाइफ ऑफ द सेल” या चित्रपटातून

गुंतवणूक व्यवसाय हा बँकिंग जगतातील सर्वात जटिल क्षेत्रांपैकी एक आहे, कारण तेथे केवळ कर्जे, कर्जे आणि ठेवी नाहीत तर सिक्युरिटीज, चलने, कमोडिटीज, डेरिव्हेटिव्ह्ज आणि संरचित उत्पादनांच्या स्वरूपात सर्व प्रकारच्या गुंतागुंत देखील आहेत.

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

याव्यतिरिक्त, रशियन आणि परदेशी दोन्ही नियामकांच्या गरजा वाढत आहेत.

सध्याच्या गरजा पूर्ण करण्यासाठी आणि भविष्यातील अपग्रेडसाठी पाया घालण्यासाठी, आम्ही टारनटूलवर आधारित गुंतवणूक व्यवसाय केंद्र विकसित केले आहे.

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

prehistory

2000 च्या सुरुवातीपासून कुठेतरी, आमच्या गुंतवणूक व्यवसायाचे क्षेत्र स्वतंत्रपणे विकसित झाले: एक्सचेंज ट्रेडिंग, ब्रोकरेज सेवा, चलन व्यापार, सिक्युरिटीजमध्ये ओव्हर-द-काउंटर ट्रेडिंग आणि विविध डेरिव्हेटिव्ह्ज. परिणामी, आम्ही कार्यक्षम विहिरींच्या जाळ्यात अडकलो आहोत. हे काय आहे? व्यवसायाच्या प्रत्येक ओळीची स्वतःची प्रणाली असते जी एकमेकांची कार्ये डुप्लिकेट करतात. प्रत्येक प्रणालीचे स्वतःचे डेटा मॉडेल असते, जरी ते समान संकल्पनांसह कार्य करतात: व्यवहार, साधने, प्रतिपक्ष, कोट इ. आणि प्रत्येक प्रणाली स्वतंत्रपणे विकसित होत असताना, तंत्रज्ञानाचे विविध प्राणीसंग्रहालय उदयास आले.

याव्यतिरिक्त, सिस्टमचा कोड बेस आधीपासूनच बराच जुना आहे, कारण काही उत्पादने 1990 च्या दशकाच्या मध्यात उद्भवली होती. आणि काही भागात यामुळे विकास प्रक्रिया मंदावली आणि कार्यप्रदर्शन समस्या निर्माण झाल्या.

नवीन समाधानासाठी आवश्यकता

व्यवसायांना हे लक्षात आले आहे की पुढील विकासासाठी तांत्रिक परिवर्तन अत्यावश्यक आहे. आम्हाला कार्ये दिली गेली:

1. सर्व व्यवसाय डेटा एकाच, जलद स्टोरेजमध्ये आणि एकाच डेटा मॉडेलमध्ये गोळा करा.
2. आम्ही ही माहिती गमावू किंवा बदलू नये.
3. डेटाची आवृत्ती करणे आवश्यक आहे, कारण कोणत्याही क्षणी नियामक मागील वर्षांची आकडेवारी विचारू शकतो.
4. आपण फक्त काही नवीन, फॅशनेबल डीबीएमएस आणू नये, तर व्यावसायिक समस्या सोडवण्यासाठी एक व्यासपीठ तयार केले पाहिजे.

याव्यतिरिक्त, आमचे आर्किटेक्ट त्यांच्या स्वतःच्या अटी सेट करतात:

1. नवीन सोल्यूशन एंटरप्राइझ-क्लास असणे आवश्यक आहे, म्हणजेच, काही मोठ्या कंपन्यांमध्ये त्याची चाचणी आधीच केली जाणे आवश्यक आहे.
2. सोल्यूशनचा ऑपरेटिंग मोड मिशन क्रिटिकल असावा. याचा अर्थ असा आहे की आपण एकाच वेळी अनेक डेटा सेंटरमध्ये उपस्थित असले पाहिजे आणि एका डेटा सेंटरच्या आउटेजपासून शांतपणे जगले पाहिजे.
3. प्रणाली क्षैतिजरित्या स्केलेबल असणे आवश्यक आहे. वस्तुस्थिती अशी आहे की आमच्या सध्याच्या सर्व प्रणाली केवळ उभ्या स्केलेबल आहेत आणि हार्डवेअर पॉवरच्या कमी वाढीमुळे आम्ही आधीच कमाल मर्यादा गाठत आहोत. म्हणून, तो क्षण आला आहे जेव्हा आपल्याकडे टिकून राहण्यासाठी क्षैतिजरित्या मापन करण्यायोग्य प्रणाली असणे आवश्यक आहे.
4. इतर गोष्टींबरोबरच, आम्हाला सांगण्यात आले की समाधान स्वस्त असावे.

आम्ही मानक मार्गाचा अवलंब केला: आम्ही आवश्यकता तयार केल्या आणि खरेदी विभागाशी संपर्क साधला. तिथून आम्हाला अशा कंपन्यांची यादी मिळाली जी सर्वसाधारणपणे आमच्यासाठी हे करण्यास तयार आहेत. आम्ही प्रत्येकाला समस्येबद्दल सांगितले आणि त्यापैकी सहा कडून उपायांचे मूल्यांकन प्राप्त केले.

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

आम्ही सर्व गोष्टींची चाचणी कशी केली आणि किती वेळ लागला हे मी तुम्हाला सांगणार नाही, मी फक्त थोडक्यात सांगेन: Mail.ru ग्रुप डेव्हलपमेंट टीमच्या Tarantool वर आधारित प्रोटोटाइप सोल्यूशनद्वारे लोड चाचण्यांमध्ये सर्वोत्तम कामगिरी दर्शविली गेली. आम्ही एक करार केला आणि विकास सुरू केला. Mail.ru ग्रुपचे चार लोक होते आणि Alfa-Bank मधून तीन डेव्हलपर, तीन सिस्टीम विश्लेषक, एक सोल्यूशन आर्किटेक्ट, एक उत्पादन मालक आणि एक स्क्रम मास्टर होते.

पुढे मी तुम्हाला सांगेन की आमची प्रणाली कशी वाढली, ती कशी विकसित झाली, आम्ही काय केले आणि हे नक्की का.

विकास

आमच्या सध्याच्या सिस्टीममधून डेटा कसा मिळवायचा हा पहिला प्रश्न आम्ही स्वतःला विचारला. आम्ही ठरवले की HTTP आमच्यासाठी अगदी योग्य आहे, कारण सर्व वर्तमान प्रणाली HTTP वर XML किंवा JSON पाठवून एकमेकांशी संवाद साधतात.

आम्‍ही टारनटूलमध्‍ये तयार केलेला HTTP सर्व्हर वापरतो कारण आम्‍हाला SSL सत्रे संपवण्‍याची आवश्‍यकता नाही, आणि त्‍याची कार्यक्षमता आम्‍हाला पुरेशी आहे.

मी आधीच म्हटल्याप्रमाणे, आमच्या सर्व सिस्टीम वेगवेगळ्या डेटा मॉडेल्समध्ये राहतात आणि इनपुटवर आम्ही स्वतःचे वर्णन केलेल्या मॉडेलमध्ये ऑब्जेक्ट आणणे आवश्यक आहे. एका भाषेची आवश्यकता होती जी डेटा बदलू देते. आम्ही अनिवार्य लुआ निवडले. आम्ही सर्व डेटा रूपांतरण कोड सँडबॉक्समध्ये चालवतो - हे एक सुरक्षित ठिकाण आहे ज्याच्या पलीकडे चालू असलेला कोड जात नाही. हे करण्यासाठी, आम्ही फक्त आवश्यक कोड लोड करतो, फंक्शन्ससह वातावरण तयार करतो जे काहीही ब्लॉक किंवा ड्रॉप करू शकत नाही.

रूपांतरणानंतर, आम्ही तयार करत असलेल्या मॉडेलचे पालन करण्यासाठी डेटा तपासला जाणे आवश्यक आहे. मॉडेल काय असावे आणि त्याचे वर्णन करण्यासाठी कोणती भाषा वापरावी यावर आम्ही बराच वेळ चर्चा केली. आम्ही Apache Avro निवडले कारण भाषा सोपी आहे आणि तिला Tarantool चे समर्थन आहे. मॉडेलच्या नवीन आवृत्त्या आणि सानुकूल कोड दिवसातून अनेक वेळा, अगदी लोडखाली किंवा त्याशिवाय, दिवसाच्या कोणत्याही वेळी कार्यान्वित केले जाऊ शकतात आणि बदलांशी खूप लवकर जुळवून घेतात.

पडताळणी केल्यानंतर, डेटा जतन करणे आवश्यक आहे. आम्ही हे vshard वापरून करतो (आमच्याकडे शार्ड्सच्या भौगोलिक-विखुरलेल्या प्रतिकृती आहेत).

शिवाय, विशिष्टता अशी आहे की आम्हाला डेटा पाठवणार्‍या बर्‍याच सिस्टम आम्हाला तो मिळाला की नाही याची काळजी घेत नाही. म्हणूनच आम्ही सुरुवातीपासूनच दुरुस्तीची रांग लागू केली. हे काय आहे? काही कारणास्तव एखादी वस्तू डेटा ट्रान्सफॉर्मेशन किंवा पडताळणी करत नसल्यास, आम्ही अद्याप पावतीची पुष्टी करतो, परंतु त्याच वेळी ऑब्जेक्टला दुरुस्तीच्या रांगेत जतन करतो. हे सुसंगत आहे आणि मुख्य व्यवसाय डेटा वेअरहाऊसमध्ये स्थित आहे. आम्ही ताबडतोब त्यासाठी प्रशासक इंटरफेस, विविध मेट्रिक्स आणि अलर्ट लिहिले. परिणामी, आम्ही डेटा गमावत नाही. जरी स्त्रोतामध्ये काहीतरी बदलले असले तरीही, डेटा मॉडेल बदलले असल्यास, आम्ही ते त्वरित शोधू आणि परिस्थितीशी जुळवून घेऊ शकतो.

आता आपल्याला जतन केलेला डेटा कसा पुनर्प्राप्त करायचा हे शिकण्याची आवश्यकता आहे. आम्ही आमच्या सिस्टमचे काळजीपूर्वक विश्लेषण केले आणि पाहिले की Java आणि Oracle च्या क्लासिक स्टॅकमध्ये काही प्रकारचे ORM असणे आवश्यक आहे जे डेटा रिलेशनल ते ऑब्जेक्टमध्ये रूपांतरित करते. तर मग ताबडतोब ग्राफच्या रूपात सिस्टमला ऑब्जेक्ट्स का देऊ नये? म्हणून आम्ही आनंदाने GraphQL स्वीकारले, ज्याने आमच्या सर्व गरजा पूर्ण केल्या. हे आपल्याला आलेखांच्या स्वरूपात डेटा प्राप्त करण्यास आणि आपल्याला आत्ता आवश्यक असलेल्या गोष्टी काढण्याची परवानगी देते. तुम्ही एपीआयची बर्‍याच लवचिकतेसह आवृत्ती देखील बनवू शकता.

जवळजवळ लगेचच आम्हाला समजले की आम्ही काढत असलेला डेटा पुरेसा नाही. आम्ही अशी फंक्शन्स तयार केली आहेत जी मॉडेलमधील ऑब्जेक्ट्सशी जोडली जाऊ शकतात - मूलत: गणना केलेली फील्ड. म्हणजेच, आम्ही फील्डमध्ये एक विशिष्ट कार्य संलग्न करतो, जे, उदाहरणार्थ, सरासरी कोट किंमतीची गणना करते. आणि डेटाची विनंती करणार्‍या बाह्य ग्राहकाला हे देखील माहित नसते की हे एक गणना केलेले फील्ड आहे.

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

मग आमच्या लक्षात आले की आमच्या निर्णयात अनेक भूमिका स्फटिक झाल्या. भूमिका ही फंक्शन्सचा एक प्रकार आहे. सामान्यतः, भूमिकांमध्ये भिन्न उपकरण वापर प्रोफाइल असतात:

• टी-कनेक्ट: येणारे कनेक्शन हाताळते, CPU मर्यादित, कमी मेमरी वापर, स्टेटलेस.
• IB-कोर: टॅरनटूल प्रोटोकॉलद्वारे प्राप्त डेटाचे रूपांतर करते, म्हणजेच ते टेबलसह कार्य करते. हे देखील स्थिती संचयित करत नाही आणि स्केलेबल आहे.
• स्टोरेज: फक्त डेटा संग्रहित करते, कोणतेही तर्क वापरत नाही. ही भूमिका सर्वात सोपी इंटरफेस लागू करते. स्केलेबल धन्यवाद vshard.

म्हणजेच, भूमिकांचा वापर करून, आम्ही क्लस्टरचे वेगवेगळे भाग एकमेकांपासून वेगळे केले, जे एकमेकांपासून स्वतंत्रपणे मोजले जाऊ शकतात.

म्हणून, आम्ही अॅसिंक्रोनस ट्रान्झॅक्शनल डेटा फ्लो रेकॉर्डिंग आणि अॅडमिन इंटरफेससह दुरुस्ती रांग तयार केली आहे. व्यवसायाच्या दृष्टिकोनातून रेकॉर्डिंग असिंक्रोनस आहे: जर आम्हाला स्वतःला डेटा लिहिण्याची हमी दिली गेली असेल, कुठेही असो, आम्ही त्याची पुष्टी करू. जर त्याची पुष्टी झाली नाही, तर काहीतरी चूक झाली आणि डेटा पाठविला जाणे आवश्यक आहे. हे असिंक्रोनस रेकॉर्डिंग आहे.

चाचणी

प्रकल्पाच्या सुरुवातीपासूनच, आम्ही ठरवले की आम्ही चाचणी आधारित विकास कार्यान्वित करण्याचा प्रयत्न करू. आम्ही टारंटूल/टॅप फ्रेमवर्क वापरून लुआमध्ये युनिट चाचण्या लिहितो आणि पायटेस्ट फ्रेमवर्क वापरून पायथनमध्ये एकत्रीकरण चाचण्या लिहितो. त्याच वेळी, आम्ही विकसक आणि विश्लेषक दोघांनाही एकत्रीकरण चाचण्या लिहिण्यात गुंतवतो.

आम्ही चाचणी आधारित विकास कसा वापरतो?

आम्हाला काही नवीन वैशिष्ट्य हवे असल्यास, आम्ही त्यासाठी प्रथम चाचणी लिहिण्याचा प्रयत्न करतो. जेव्हा आम्हाला बग सापडतो, तेव्हा आम्ही प्रथम चाचणी लिहिण्याची खात्री करतो आणि त्यानंतरच त्याचे निराकरण करतो. सुरुवातीला असे काम करणे कठीण आहे, कर्मचार्‍यांच्या बाजूने गैरसमज आहे, अगदी तोडफोड देखील: "चला आता त्वरीत निराकरण करू, काहीतरी नवीन करू आणि नंतर चाचण्यांसह झाकून टाकू." फक्त हे “नंतर” जवळजवळ कधीच येत नाही.

म्हणून, आपणास प्रथम चाचण्या लिहिण्यास भाग पाडणे आणि इतरांना ते करण्यास सांगणे आवश्यक आहे. माझ्यावर विश्वास ठेवा, चाचणी आधारित विकास अल्पावधीतही फायदे आणतो. तुमचे जीवन सोपे झाले आहे असे तुम्हाला वाटेल. आम्हाला असे वाटते की 99% कोड आता चाचण्यांनी कव्हर केले आहे. हे बरेच दिसते, परंतु आम्हाला कोणतीही समस्या नाही: चाचण्या प्रत्येक कमिटवर चालतात.

तथापि, आम्हाला सर्वात जास्त आवडते ते लोड चाचणी आहे; आम्ही ते सर्वात महत्वाचे मानतो आणि ते नियमितपणे पार पाडतो.

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

आम्ही खूप दुःखी होतो. आम्ही सर्व्हर लोड पाहतो, परंतु ते निष्क्रिय असल्याचे दिसून आले.

आम्ही विकासकांना कॉल करतो आणि ते आम्हाला समजावून सांगतात, जावाच्या जगातून आलेले लोक, टारनटूल सिंगल-थ्रेडेड आहे. हे फक्त लोड अंतर्गत एका प्रोसेसर कोरद्वारे प्रभावीपणे वापरले जाऊ शकते. मग आम्ही प्रत्येक सर्व्हरवर जास्तीत जास्त संभाव्य टॅरनटूल उदाहरणे तैनात केली, लोड चालू केले आणि आधीच प्रति सेकंद 14,5 हजार व्यवहार प्राप्त केले.

मी पुन्हा स्पष्ट करू. संसाधने वेगळ्या पद्धतीने वापरणाऱ्या भूमिकांमध्ये विभागणी केल्यामुळे, कनेक्शन आणि डेटा ट्रान्सफॉर्मेशन प्रक्रियेसाठी जबाबदार असलेल्या आमच्या भूमिका केवळ प्रोसेसर लोड करतात आणि लोडच्या काटेकोरपणे प्रमाणात असतात.

या प्रकरणात, मेमरी फक्त इनकमिंग कनेक्शन आणि तात्पुरत्या वस्तूंवर प्रक्रिया करण्यासाठी वापरली गेली.

त्याउलट, स्टोरेज सर्व्हरवर, प्रोसेसर लोड वाढला, परंतु कनेक्शनवर प्रक्रिया करणार्‍या सर्व्हरच्या तुलनेत खूपच हळू.

आणि मेमरी वापर लोड केलेल्या डेटाच्या थेट प्रमाणात वाढला.

सेवा

आमचे नवीन उत्पादन विशेषत: ऍप्लिकेशन प्लॅटफॉर्म म्हणून विकसित करण्यासाठी, आम्ही त्यावर सेवा आणि लायब्ररी तैनात करण्यासाठी एक घटक तयार केला आहे.

सेवा काही फील्डवर चालणाऱ्या कोडचे फक्त छोटे तुकडे नाहीत. ते खूप मोठ्या आणि जटिल संरचना असू शकतात जे क्लस्टरचा भाग आहेत, संदर्भ डेटा तपासा, व्यवसाय तर्क चालवा आणि प्रतिसाद परत करा. आम्ही सेवा स्कीमा GraphQL वर निर्यात करतो आणि ग्राहकाला संपूर्ण मॉडेलवर आत्मनिरीक्षण करून डेटाचा सार्वत्रिक प्रवेश बिंदू प्राप्त होतो. हे खूप आरामदायक आहे.

सेवांमध्ये आणखी अनेक कार्ये असल्याने, आम्ही ठरवले की अशी लायब्ररी असावी ज्यामध्ये आम्ही वारंवार वापरलेला कोड हलवू. आम्ही त्यांना सुरक्षित वातावरणात जोडले, ते आमच्यासाठी काहीही खंडित करत नाही हे यापूर्वी तपासले आहे. आणि आता आपण लायब्ररीच्या स्वरूपात फंक्शन्ससाठी अतिरिक्त वातावरण नियुक्त करू शकतो.

आम्हाला केवळ स्टोरेजसाठीच नव्हे तर कंप्युटिंगसाठीही व्यासपीठ हवे होते. आणि आमच्याकडे आधीपासून प्रतिकृती आणि शार्ड्सचा एक समूह असल्याने, आम्ही एक प्रकारचे वितरित संगणन लागू केले आणि त्याला नकाशा कमी म्हटले, कारण ते मूळ नकाशाच्या कमी सारखेच होते.

जुन्या प्रणाली

आमच्या सर्व लेगेसी सिस्टम आम्हाला HTTP वर कॉल करू शकत नाहीत आणि ग्राफक्यूएल वापरू शकत नाहीत, जरी ते प्रोटोकॉलला समर्थन देतात. म्हणून, आम्ही एक यंत्रणा तयार केली आहे जी या प्रणालींमध्ये डेटाची प्रतिकृती बनवण्याची परवानगी देते.

आमच्यासाठी काहीतरी बदलल्यास, स्टोरेजच्या भूमिकेत अद्वितीय ट्रिगर ट्रिगर केले जातात आणि बदलांसह संदेश प्रक्रिया रांगेत संपतो. ते वेगळ्या प्रतिकृतीची भूमिका वापरून बाह्य प्रणालीकडे पाठवले जाते. ही भूमिका राज्य साठवत नाही.

नवीन सुधारणा

तुम्हाला आठवत असेल, व्यवसायाच्या दृष्टिकोनातून, आम्ही असिंक्रोनस रेकॉर्डिंग केले. परंतु नंतर त्यांना समजले की ते पुरेसे होणार नाही, कारण सिस्टमचा एक वर्ग आहे ज्यांना ऑपरेशनच्या स्थितीबद्दल त्वरित प्रतिसाद मिळणे आवश्यक आहे. म्हणून आम्ही आमचे GraphQL वाढवले ​​आणि उत्परिवर्तन जोडले. ते सेंद्रियपणे डेटासह कार्य करण्याच्या विद्यमान प्रतिमानामध्ये बसतात. आमच्यासाठी, प्रणालीच्या दुसर्‍या वर्गासाठी वाचन आणि लेखन दोन्हीचा हा एकच मुद्दा आहे.

आम्हाला हे देखील समजले की एकट्या सेवा आमच्यासाठी पुरेशा नसतील, कारण दिवसातून एकदा, आठवड्यातून, महिन्यातून एकदा तयार केले जाणे आवश्यक असलेले जोरदार अहवाल आहेत. यास बराच वेळ लागू शकतो आणि अहवाल टारनटूलचा इव्हेंट लूप देखील अवरोधित करू शकतात. म्हणून, आम्ही स्वतंत्र भूमिका तयार केल्या: शेड्यूलर आणि धावपटू. धावपटू राज्य साठवत नाहीत. ते जड कार्ये चालवतात ज्याची आपण माशीवर गणना करू शकत नाही. आणि शेड्यूलर भूमिका या कार्यांच्या लाँच शेड्यूलचे परीक्षण करते, ज्याचे कॉन्फिगरेशनमध्ये वर्णन केले आहे. कार्ये स्वतःच व्यवसाय डेटा सारख्या ठिकाणी संग्रहित केली जातात. जेव्हा योग्य वेळ येते तेव्हा शेड्युलर कार्य घेतो, ते एखाद्या धावपटूला देतो, जो ते मोजतो आणि निकाल वाचवतो.

सर्व कामे वेळापत्रकानुसार चालवायची गरज नाही. काही अहवाल मागणीनुसार वाचावे लागतात. ही आवश्यकता येताच, सँडबॉक्समध्ये एक कार्य तयार केले जाते आणि अंमलबजावणीसाठी धावपटूकडे पाठवले जाते. काही काळानंतर, वापरकर्त्यास एक असिंक्रोनस प्रतिसाद प्राप्त होतो की सर्व काही मोजले गेले आहे आणि अहवाल तयार आहे.

सुरुवातीला, आम्ही सर्व डेटा संग्रहित करणे, त्याची आवृत्ती बनवणे आणि हटवणे न करणे या पॅराडाइमचे पालन केले. परंतु जीवनात, वेळोवेळी आपल्याला अद्याप काहीतरी हटवावे लागेल, बहुतेक काही कच्ची किंवा मध्यवर्ती माहिती. कालबाह्यतेच्या आधारावर, आम्ही कालबाह्य डेटापासून स्टोरेज साफ करण्यासाठी एक यंत्रणा तयार केली आहे.

आम्ही हे देखील समजतो की लवकरच किंवा नंतर अशी परिस्थिती येईल जेव्हा मेमरीमध्ये डेटा संचयित करण्यासाठी पुरेशी जागा नसेल, परंतु तरीही डेटा संग्रहित करणे आवश्यक आहे. या हेतूंसाठी, आम्ही लवकरच डिस्क स्टोरेज बनवू.

निष्कर्ष

आम्ही एका मॉडेलमध्ये डेटा लोड करण्याचे काम सुरू केले आणि ते विकसित करण्यासाठी तीन महिने घालवले. आमच्याकडे सहा डेटा पुरवठा प्रणाली होत्या. एका मॉडेलमध्ये संपूर्ण परिवर्तन कोड लुआमध्ये सुमारे 30 हजार ओळी आहेत. आणि बरेचसे काम अजून बाकी आहे. काहीवेळा शेजारच्या संघांकडून प्रेरणाचा अभाव असतो आणि अशा अनेक परिस्थिती असतात ज्यामुळे काम गुंतागुंतीचे होते. तुम्हाला कधीही अशाच कामाला सामोरे जावे लागत असेल, तर त्याच्या अंमलबजावणीसाठी तुम्हाला सामान्य वाटणारा वेळ तीन किंवा चार ने गुणा.

हे देखील लक्षात ठेवा की व्यवसाय प्रक्रियेतील विद्यमान समस्या नवीन DBMS वापरून सोडवल्या जाऊ शकत नाहीत, अगदी उत्पादनक्षम देखील. मी काय म्हणत होतो? आमच्या प्रकल्पाच्या सुरूवातीस, आम्ही ग्राहकांमध्ये अशी धारणा निर्माण केली की आता आम्ही एक नवीन वेगवान डेटाबेस आणू आणि आम्ही जगू! प्रक्रिया जलद होतील, सर्व काही ठीक होईल. किंबहुना, तंत्रज्ञानामुळे व्यावसायिक प्रक्रियेतील समस्यांचे निराकरण होत नाही, कारण व्यवसाय प्रक्रिया लोक आहेत. आणि तुम्हाला लोकांसोबत काम करण्याची गरज आहे, तंत्रज्ञान नाही.

चाचणी-चालित विकास प्रारंभिक टप्प्यात वेदनादायक आणि वेळ घेणारा असू शकतो. परंतु त्याचा सकारात्मक परिणाम अल्पावधीतही लक्षात येईल, जेव्हा तुम्हाला प्रतिगमन चाचणी आयोजित करण्यासाठी काहीही करण्याची आवश्यकता नसते.

विकासाच्या सर्व टप्प्यांवर लोड चाचणी आयोजित करणे अत्यंत महत्वाचे आहे. जितक्या लवकर तुम्हाला आर्किटेक्चरमधील काही त्रुटी लक्षात येतील, तितकेच त्याचे निराकरण करणे सोपे होईल, ज्यामुळे भविष्यात तुमचा बराच वेळ वाचेल.

लुआमध्ये काहीही चुकीचे नाही. यात कोणीही लिहायला शिकू शकतो: Java डेव्हलपर, JavaScript डेव्हलपर, पायथन डेव्हलपर, फ्रंट-एंड किंवा बॅक-एंड. आमचे विश्लेषकही त्यावर लिहितात.

आमच्याकडे SQL नाही या वस्तुस्थितीबद्दल आम्ही बोलतो तेव्हा ते लोकांना घाबरवते. “तुम्हाला SQL शिवाय डेटा कसा मिळेल? ते शक्य आहे का? नक्कीच. OLTP वर्ग प्रणालीमध्ये, SQL आवश्यक नाही. काही प्रकारच्या भाषेच्या स्वरूपात एक पर्याय आहे जो आपल्याला त्वरित दस्तऐवज-देणारं दृश्याकडे परत करतो. उदाहरणार्थ, ग्राफक्यूएल. आणि वितरित संगणनाच्या स्वरूपात एक पर्याय आहे.

जर तुम्हाला समजले असेल की तुम्हाला स्केल करणे आवश्यक आहे, तर तुमचे सोल्यूशन टारनटूलवर अशा प्रकारे डिझाइन करा की ते डझनभर टारनटूल उदाहरणांवर समांतरपणे चालू शकेल. आपण हे न केल्यास, नंतर ते कठीण आणि वेदनादायक होईल, कारण Tarantool केवळ एक प्रोसेसर कोर प्रभावीपणे वापरू शकते.

स्त्रोत: www.habr.com