कसरी चिन्ता छोड्ने र मोनोलिथ बिना बाँच्न सुरु गर्ने

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

आज यस्तै एउटा दिन हो । र यदि तपाईं अहिले आगोमा हुनुहुन्न भने, हामीसँग तपाईंको लागि एउटा कथा छ। हामीले कसरी Tarantool मा भण्डारणको साथ काम गर्न थालेको कथा।

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

अहिले उपकरणदेखि व्यवसायिक तर्कसम्म सबै र सबैलाई अलग गर्ने प्रचलित विचारधारा हो। नतिजाको रूपमा, हामीसँग, उदाहरणका लागि, दुई DC हरू छन् जुन नेटवर्क स्तरमा व्यावहारिक रूपमा स्वतन्त्र छन्। र त्यसपछि सबै कुरा पूर्ण रूपमा फरक थियो।

आज, CI/CD, K8S, आदि को रूप मा परिवर्तन गर्न को लागी धेरै उपकरण र उपकरणहरू छन्। "मोनोलिथिक" समयमा, हामीलाई यति धेरै विदेशी शब्दहरू आवश्यक पर्दैन। डाटाबेसमा "भण्डार" लाई सच्याउन पर्याप्त थियो।

तर समय अगाडि बढ्यो, र अनुरोधहरूको संख्या यससँगै अगाडि बढ्यो, कहिलेकाहीँ हाम्रो क्षमताहरू भन्दा बाहिरको RPS लाई शूट गर्दै। बजारमा CIS देशहरूको प्रवेशको साथ, पहिलो मोनोलिथको डाटाबेस प्रोसेसरमा लोड 90% भन्दा कम भएन, र RPS 2400 को स्तरमा रह्यो। र यी केवल साना चयनकर्ताहरू थिएनन्, तर भारी प्रश्नहरू थिए। ठूला IO को पृष्ठभूमिमा लगभग आधा डाटा चलाउन सक्ने चेक र JOINहरूको गुच्छा।

जब पूर्ण ब्ल्याक फ्राइडे बिक्री दृश्यमा देखा पर्न थाल्यो - र वाइल्डबेरीहरू रूसमा तिनीहरूलाई समात्ने पहिलो मध्ये एक थियो - स्थिति पूर्ण रूपमा दुःखी भयो। आखिर, त्यस्ता दिनहरूमा लोड तीन पटक बढ्छ।
ओह, यी "मोनोलिथिक समयहरू"! म पक्का छु कि तपाईले यस्तै केहि अनुभव गर्नुभएको छ, र तपाईले अझै पनि बुझ्न सक्नुहुन्न कि तपाईलाई यो कसरी हुन सक्छ।

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

विभिन्न घटनाहरूमा म भन्छु: "यदि तपाईंले मोनोलिथ देख्नुभएन भने, तब तपाईं बढ्नुहुन्न!" मलाई यस विषयमा तपाईंको रायमा रुचि छ, कृपया टिप्पणीहरूमा लेख्नुहोस्।

गर्जनको आवाज

हाम्रो "बोनफायर" मा फर्कौं। "मोनोलिथिक" कार्यक्षमताको लोड वितरण गर्न, हामीले प्रणालीलाई ओपनसोर्स टेक्नोलोजीहरूमा आधारित माइक्रोसेवाहरूमा विभाजन गर्ने निर्णय गर्यौं। किनभने, न्यूनतममा, तिनीहरू मापन गर्न सस्तो छन्। र हामीले 100% बुझेका थियौं कि हामीले मापन गर्नुपर्नेछ (र धेरै)। आखिर, पहिले नै त्यो समयमा छिमेकी देशहरूको बजारमा प्रवेश गर्न सम्भव थियो, र दर्ताको संख्या, साथै आदेशहरूको संख्या, अझ बलियो रूपमा बढ्न थाले।

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

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

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

नतिजाको रूपमा, हामीले टारन्टुलसँग राम्रोसँग मिल्ने योजना ल्यायौं।

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

वास्तुकला। विकल्प 1. प्रयोगकर्ता सेवा

हालको समयमा, त्यहाँ 24 शार्डहरू छन्, जसमध्ये प्रत्येकमा 2 उदाहरणहरू छन् (प्रत्येक DC को लागि एक), सबै मास्टर-मास्टर मोडमा छन्।

डाटाबेसको शीर्षमा डाटाबेस प्रतिकृतिहरू पहुँच गर्ने अनुप्रयोगहरू छन्। एप्लिकेसनहरूले हाम्रो कस्टम लाइब्रेरी मार्फत Tarantool सँग काम गर्दछ, जसले Tarantool Go ड्राइभर इन्टरफेस लागू गर्दछ। उनी सबै प्रतिकृतिहरू देख्छिन् र पढ्न र लेख्न मास्टरसँग काम गर्न सक्छिन्। अनिवार्य रूपमा, यसले प्रतिकृति सेट मोडेल लागू गर्दछ, जसले प्रतिकृतिहरू चयन गर्न, पुन: प्रयासहरू प्रदर्शन गर्ने, सर्किट ब्रेकर र दर सीमाको लागि तर्क थप्छ।

यस अवस्थामा, शार्डको सन्दर्भमा प्रतिकृति चयन नीति कन्फिगर गर्न सम्भव छ। उदाहरणका लागि, राउन्डरोबिन।

वास्तुकला। विकल्प २. सामानको अन्तिम लागत गणना गर्नको लागि सेवा

केहि महिना पहिले, सामानको अन्तिम लागत गणना गर्नका लागि धेरै अनुरोधहरू नयाँ सेवामा गएका थिए, जुन, सिद्धान्तमा, डाटाबेस बिना काम गर्दछ, तर केहि समय पहिले हुड अन्तर्गत Tarantool को साथ सेवा द्वारा 100% प्रशोधन गरिएको थियो।

सेवा डेटाबेसमा 4 मास्टरहरू हुन्छन् जसमा सिङ्क्रोनाइजरले डेटा सङ्कलन गर्दछ, र यी प्रत्येक प्रतिकृति मास्टरहरूले पढ्न मात्र प्रतिकृतिहरूमा डेटा वितरण गर्दछ। प्रत्येक मास्टरसँग लगभग 15 वटा प्रतिकृतिहरू छन्।

या त पहिलो वा दोस्रो योजनामा, यदि एउटा DC अनुपलब्ध छ भने, अनुप्रयोगले दोस्रोमा डेटा प्राप्त गर्न सक्छ।

यो ध्यान दिन लायक छ कि Tarantool मा प्रतिकृति एकदम लचिलो छ र रनटाइम मा कन्फिगर गर्न सकिन्छ। अन्य प्रणालीहरूमा, कठिनाइहरू उत्पन्न भयो। उदाहरणका लागि, PostgreSQL मा max_wal_senders र max_replication_slots प्यारामिटरहरू परिवर्तन गर्न विजार्डको पुन: सुरु गर्न आवश्यक छ, जसले केही अवस्थामा अनुप्रयोग र DBMS बीचको जडानहरू विच्छेद गर्न सक्छ।

खोज्नुहोस् र तपाईंले पाउनुहुनेछ!

किन हामीले यसलाई "सामान्य मानिसहरू जस्तै" गरेनौं, तर एक असामान्य तरिका रोज्यौं? यो के सामान्य मानिन्छ मा निर्भर गर्दछ। धेरै मानिसहरूले सामान्यतया मङ्गोबाट एउटा क्लस्टर बनाउँछन् र यसलाई तीनवटा भू-वितरित डीसीहरूमा फैलाउँछन्।

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

त्यो हो, Redis राज्यविहीन कार्यहरूका लागि राम्रो छ, स्टेटफुल होइन। सिद्धान्तमा, यसले धेरैजसो समस्याहरू समाधान गर्न अनुमति दिन्छ, तर केवल यदि तिनीहरू अनुक्रमणिकाको जोडीको साथ मुख्य-मान समाधानहरू थिए। तर रेडिस त्यस समयमा दृढता र नक्कल संग धेरै दुखी थियो। साथै, कार्यसम्पादनको बारेमा गुनासोहरू थिए।

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

अन्ततः हामी टारन्टुलमा बस्यौं।

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

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

कार्यान्वयनको सुरुआत कसिलो भयो

त्यस समयमा, हाम्रो मुख्य विकास स्ट्याक .NET थियो, जसमा Tarantool को लागि कुनै कनेक्टर थिएन। हामीले तुरुन्तै Go मा केहि गर्न थाल्यौं। यसले लुआसँग पनि राम्रो काम गर्यो। त्यस समयमा मुख्य समस्या डिबगिङको साथ थियो: .NET मा सबै कुरा यससँग राम्रो छ, तर त्यस पछि इम्बेडेड लुआको संसारमा डुब्न गाह्रो भयो, जब तपाईंसँग लगहरू बाहेक कुनै डिबगिङ छैन। थप रूपमा, कुनै कारणले प्रतिकृति आवधिक रूपमा अलग भयो, त्यसैले मैले टारान्टुल इन्जिनको संरचनामा जान थालेको थियो। च्याटले यससँग मद्दत गर्‍यो, र केही हदसम्म, कागजात; कहिलेकाहीँ हामीले कोड हेर्‍यौं। त्यसबेला, कागजात यस्तो थियो।

त्यसोभए, धेरै महिनाको अवधिमा, मैले टारन्टूलसँग काम गरेर राम्रो नतिजाहरू प्राप्त गर्न सफल भएँ। हामीले git मा सन्दर्भ विकासहरू कम्पाइल गर्यौं जसले नयाँ माइक्रोसर्भिसेसहरूको गठनमा मद्दत गर्‍यो। उदाहरणका लागि, जब एउटा कार्य उठ्यो: अर्को माइक्रोसर्भिस सिर्जना गर्न, विकासकर्ताले रिपोजिटरीमा सन्दर्भ समाधानको स्रोत कोड हेरे, र नयाँ सिर्जना गर्न एक हप्ता भन्दा बढी लागेन।

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

आज यो अब काम गर्दैन: तपाईंले सेवामा निगरानी र लगिङ थप्नुपर्छ, परीक्षणको साथ कार्यक्षमता कभर गर्नुहोस्, भर्चुअल मेसिन अर्डर गर्नुहोस् वा कुबेरलाई डेलिभरी, आदि। सामान्यतया, यो यस तरिकाले राम्रो हुनेछ, यद्यपि यसले लामो समय लिनेछ र थप कष्टप्रद हुनेछ।

विभाजन र शासन गर्नुहोस्। लुआ संग के सम्झौता छ?

त्यहाँ एउटा गम्भीर दुविधा थियो: केही टोलीहरूले लुआमा धेरै तर्कको साथ सेवामा परिवर्तनहरू भरपर्दो रूपमा रोल आउट गर्न असमर्थ थिए। यो अक्सर सेवा काम नगरेको साथ थियो।

त्यो हो, विकासकर्ताहरूले केहि प्रकारको परिवर्तनको तयारी गरिरहेका छन्। Tarantool माइग्रेसन गर्न थाल्छ, तर प्रतिकृति अझै पुरानो कोड संग छ; केहि DDL वा अन्य केहि प्रतिकृति मार्फत त्यहाँ आइपुग्छ, र कोड मात्र अलग हुन्छ किनभने यो खातामा लिइएको छैन। नतिजाको रूपमा, प्रशासकहरूको लागि अद्यावधिक प्रक्रिया A4 पानामा राखिएको थियो: प्रतिकृति रोक्नुहोस्, यसलाई अद्यावधिक गर्नुहोस्, प्रतिकृति सक्रिय गर्नुहोस्, यहाँ बन्द गर्नुहोस्, त्यहाँ अद्यावधिक गर्नुहोस्। दुःस्वप्न!

नतिजाको रूपमा, अब हामी प्रायः लुआमा केहि नगर्ने प्रयास गर्छौं। केवल iproto प्रयोग गर्नुहोस् (सर्भरसँग अन्तरक्रिया गर्नको लागि बाइनरी प्रोटोकल), र त्यो हो। सायद यो विकासकर्ताहरू बीच ज्ञानको कमी हो, तर यस दृष्टिकोणबाट प्रणाली जटिल छ।

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

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

सबैभन्दा महत्त्वपूर्ण सेवाहरू मध्ये एक प्रयोगकर्ता प्रोफाइल हो। अर्थात्, सबै Wildberries प्रयोगकर्ताहरू Tarantool मा भण्डारण गरिएका छन्, र तिनीहरूमध्ये करिब 50 मिलियन छन्। प्रयोगकर्ता ID द्वारा साझा गरिएको प्रणाली, Go सेवाहरूमा जडान भएका धेरै DCहरूमा वितरित।
आरपीएसका अनुसार कुनै समय प्रमोटर नेता थिए, ६ हजार अनुरोध पुगेका थिए । एक समयमा हामीसँग 6-50 प्रतिहरू थिए। अब RPS मा नेता प्रयोगकर्ता प्रोफाइलहरू छन्, लगभग 60 हजार। यो सेवाले प्रयोगकर्ता ID को दायराहरू द्वारा विभाजित अनुकूलन शेर्डिङ प्रयोग गर्दछ। सेवाले 12 भन्दा बढी मेसिनहरू सेवा गर्दछ, तर यो धेरै छ; हामीले आवंटित स्रोतहरू घटाउने योजना बनाएका छौं, किनभने 20-4 मेसिनहरूको क्षमता यसको लागि पर्याप्त छ।

सत्र सेवा vshard र Cartridge मा हाम्रो पहिलो सेवा हो। vshard सेट अप गर्न र कार्ट्रिज अद्यावधिक गर्न हामीबाट केही प्रयास आवश्यक थियो, तर अन्तमा सबै काम भयो।

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

त्यहाँ एक गोदाम प्रणाली मा द्रुत सन्दर्भ कार्यक्षमता को लागी Tarantool को उपयोग को एक उदाहरण छ केहि मामिलाहरु मा छिटो दोहोरो-जाँच जानकारी को लागी। हामीले यसको लागि Redis प्रयोग गर्ने प्रयास गर्‍यौं, तर मेमोरीमा भएको डाटाले Tarantool भन्दा बढी ठाउँ लियो।

प्रतीक्षा सूचीका सेवाहरू, ग्राहक सदस्यताहरू, हाल फैशनेबल कथाहरू र स्थगित वस्तुहरू पनि Tarantool सँग काम गर्छन्। मेमोरीमा अन्तिम सेवाले लगभग 120 GB लिन्छ। यो माथिको सबैभन्दा व्यापक सेवा हो।

निष्कर्षमा

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

बिषयमा अरु के पढ्नु होला

• Tarantool प्रयोग गरेर स्क्र्याचबाट उच्च-लोड अनुप्रयोग सिर्जना गर्दै habr.com/ru/company/mailru/blog/510440
• Tarantool Cartridge मा विश्वसनीय नेता छनोट habr.com/ru/company/mailru/blog/513912
• उत्पादन बारे समाचार संग टेलिग्राम च्यानल Tarantool t.me/tarantool_news
• सामुदायिक च्याटमा Tarantool छलफल गर्नुहोस् t.me/tarantoolru

स्रोत: www.habr.com