शुरुआत से VKontakte संदेश डेटाबेस को फिर से लिखें और जीवित रहें

हमारे उपयोगकर्ता बिना थकान जाने एक-दूसरे को संदेश लिखते हैं।

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

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

हमारे लिए ये पल डेढ़ साल पहले आया था. हम यहां तक ​​कैसे पहुंचे और अंत में क्या हुआ - हम आपको क्रम से बताते हैं।

मामले के इतिहास

पहले कार्यान्वयन में, VKontakte संदेशों ने PHP बैकएंड और MySQL के संयोजन पर काम किया। यह एक छोटे छात्र की वेबसाइट के लिए पूरी तरह से सामान्य समाधान है। हालाँकि, यह साइट अनियंत्रित रूप से बढ़ी और अपने लिए डेटा संरचनाओं के अनुकूलन की मांग करने लगी।

2009 के अंत में, पहला टेक्स्ट-इंजन रिपॉजिटरी लिखा गया था, और 2010 में संदेशों को इसमें स्थानांतरित कर दिया गया था।

टेक्स्ट-इंजन में, संदेशों को सूचियों में संग्रहीत किया जाता था - एक प्रकार का "मेलबॉक्स"। ऐसी प्रत्येक सूची एक यूआईडी द्वारा निर्धारित की जाती है - वह उपयोगकर्ता जिसके पास ये सभी संदेश हैं। एक संदेश में विशेषताओं का एक सेट होता है: वार्ताकार पहचानकर्ता, पाठ, अनुलग्नक, इत्यादि। "बॉक्स" के अंदर संदेश पहचानकर्ता स्थानीय_आईडी है, यह कभी नहीं बदलता है और नए संदेशों के लिए क्रमिक रूप से निर्दिष्ट किया जाता है। "बॉक्स" स्वतंत्र हैं और इंजन के अंदर एक दूसरे के साथ सिंक्रनाइज़ नहीं हैं; उनके बीच संचार PHP स्तर पर होता है। आप टेक्स्ट-इंजन की डेटा संरचना और क्षमताओं को अंदर से देख सकते हैं यहां.

यह दो उपयोगकर्ताओं के बीच पत्राचार के लिए काफी था। सोचो आगे क्या हुआ?

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

उपयोगकर्ता कहता है, "PHP, आइए चैट पर एक संदेश भेजें।"
"आओ, {उपयोगकर्ता नाम}," PHP कहता है।

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

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

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

2016 में संदेश इंजन चैट-सदस्यों और सदस्य-चैट के 100 उदाहरण और 8000 टेक्स्ट-इंजन हैं। उन्हें एक हजार सर्वरों पर होस्ट किया गया था, जिनमें से प्रत्येक में 64 जीबी मेमोरी थी। पहले आपातकालीन उपाय के रूप में, हमने मेमोरी को 32 जीबी और बढ़ा दिया। हमने पूर्वानुमानों का अनुमान लगाया। बड़े बदलावों के बिना, यह लगभग एक और वर्ष के लिए पर्याप्त होगा। आपको या तो हार्डवेयर पर पकड़ बनानी होगी या डेटाबेस को स्वयं अनुकूलित करना होगा।

वास्तुकला की प्रकृति के कारण, हार्डवेयर को कई गुना बढ़ाना ही उचित है। यानी कम से कम कारों की संख्या दोगुनी करना - जाहिर है, यह काफी महंगा रास्ता है। हम अनुकूलन करेंगे.

नई अवधारणा

नए दृष्टिकोण का केंद्रीय सार चैट है। चैट में उससे संबंधित संदेशों की एक सूची होती है। उपयोगकर्ता के पास चैट की एक सूची होती है.

आवश्यक न्यूनतम दो नए डेटाबेस हैं:

• चैट-इंजन। यह चैट वैक्टर का भंडार है। प्रत्येक चैट में संदेशों का एक वेक्टर होता है जो उससे संबंधित होता है। प्रत्येक संदेश में चैट के अंदर एक टेक्स्ट और एक अद्वितीय संदेश पहचानकर्ता होता है - चैट_लोकल_आईडी।
• उपयोगकर्ता-इंजन। यह उपयोगकर्ता वैक्टर का भंडारण है - उपयोगकर्ताओं के लिए लिंक। प्रत्येक उपयोगकर्ता के पास पियर_आईडी (वार्ताकार - अन्य उपयोगकर्ता, मल्टी-चैट या समुदाय) का एक वेक्टर और संदेशों का एक वेक्टर होता है। प्रत्येक Peer_id में संदेशों का एक वेक्टर होता है जो उससे संबंधित होता है। प्रत्येक संदेश में उस उपयोगकर्ता के लिए एक चैट_लोकल_आईडी और एक अद्वितीय संदेश आईडी होती है - उपयोगकर्ता_लोकल_आईडी।

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

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

उसी समय, हार्ड ड्राइव पर डेटा दिन में केवल एक बार बदलता है - मॉस्को में देर रात, जब लोड न्यूनतम होता है। इसके लिए धन्यवाद (यह जानते हुए कि डिस्क पर संरचना पूरे दिन स्थिर रहती है), हम वैक्टर को एक निश्चित आकार के सरणियों से बदलने का जोखिम उठा सकते हैं - और इसके कारण, मेमोरी में वृद्धि होती है।

नई योजना में संदेश भेजना इस तरह दिखता है:

1. PHP बैकएंड एक संदेश भेजने के अनुरोध के साथ उपयोगकर्ता-इंजन से संपर्क करता है।
2. उपयोगकर्ता-इंजन वांछित चैट-इंजन उदाहरण के लिए अनुरोध को प्रॉक्सी करता है, जो उपयोगकर्ता-इंजन चैट_लोकल_आईडी पर लौटता है - इस चैट के भीतर एक नए संदेश का एक अद्वितीय पहचानकर्ता। चैट_इंजन फिर चैट में सभी प्राप्तकर्ताओं को संदेश प्रसारित करता है।
3. उपयोगकर्ता-इंजन चैट-इंजन से चैट_लोकल_आईडी प्राप्त करता है और उपयोगकर्ता_लोकल_आईडी को PHP पर लौटाता है - इस उपयोगकर्ता के लिए एक अद्वितीय संदेश पहचानकर्ता। इस पहचानकर्ता का उपयोग तब किया जाता है, उदाहरण के लिए, एपीआई के माध्यम से संदेशों के साथ काम करने के लिए।

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

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

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

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

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

संदेश खोज को उपयोगकर्ता-इंजन से सभी चैट-इंजन उदाहरणों में एक विकर्ण क्वेरी के रूप में कार्यान्वित किया जाता है जिसमें इस उपयोगकर्ता की चैट शामिल होती है। परिणाम उपयोगकर्ता-इंजन में ही संयुक्त होते हैं।

खैर, सभी विवरणों को ध्यान में रखा गया है, जो कुछ बचा है वह एक नई योजना पर स्विच करना है - और अधिमानतः उपयोगकर्ताओं को इस पर ध्यान दिए बिना।

आंकड़ों का विस्थापन

तो, हमारे पास एक टेक्स्ट-इंजन है जो उपयोगकर्ता द्वारा संदेशों को संग्रहीत करता है, और दो क्लस्टर चैट-सदस्य और सदस्य-चैट हैं जो मल्टी-चैट रूम और उनमें उपयोगकर्ताओं के बारे में डेटा संग्रहीत करते हैं। इससे नए उपयोगकर्ता-इंजन और चैट-इंजन की ओर कैसे जाएं?

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

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

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

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

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

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

हम आयातित संदेशों को संग्रहीत करने के लिए एक विशेष डेटा संरचना का उपयोग करते हैं।

यह आकार के एक वेक्टर का प्रतिनिधित्व करता है सब कहाँ हैं - तत्वों के एक विशेष क्रम के साथ अलग-अलग हैं और अवरोही क्रम में क्रमबद्ध हैं। सूचकांकों के साथ प्रत्येक खंड में तत्वों को क्रमबद्ध किया गया है। ऐसी संरचना में किसी तत्व की खोज में समय लगता है के माध्यम से द्विआधारी खोजें. किसी तत्व को जोड़ने पर परिशोधन किया जाता है .

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

डेटा चैट-सदस्यों और उपयोगकर्ता-इंजन को लिखा जाता है (और टेक्स्ट-इंजन को नहीं, जैसा कि पुरानी योजना के अनुसार सामान्य ऑपरेशन में होता है)। उपयोगकर्ता-इंजन चैट-इंजन के अनुरोध को प्रॉक्सी करता है - और यहां व्यवहार इस बात पर निर्भर करता है कि यह चैट पहले ही मर्ज हो चुकी है या नहीं। यदि चैट को अभी तक मर्ज नहीं किया गया है, तो चैट-इंजन स्वयं संदेश नहीं लिखता है, और इसकी प्रोसेसिंग केवल टेक्स्ट-इंजन में होती है। यदि चैट को पहले ही चैट-इंजन में मर्ज कर दिया गया है, तो यह चैट_लोकल_आईडी को उपयोगकर्ता-इंजन पर लौटाता है और सभी प्राप्तकर्ताओं को संदेश भेजता है। उपयोगकर्ता-इंजन सभी डेटा को टेक्स्ट-इंजन पर प्रॉक्सी करता है - ताकि अगर कुछ होता है, तो हम पुराने इंजन में सभी मौजूदा डेटा रखते हुए हमेशा वापस रोल कर सकें। टेक्स्ट-इंजन user_local_id लौटाता है, जिसे उपयोगकर्ता-इंजन संग्रहीत करता है और बैकएंड पर लौटाता है।

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

निष्कर्ष

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

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

इसके अलावा, सर्वरों की संख्या दोगुनी करने के बजाय, हमने उनकी संख्या आधी कर दी - अब उपयोगकर्ता-इंजन और चैट-इंजन 500 भौतिक मशीनों पर रहते हैं, जबकि नई योजना में लोड के लिए एक बड़ा हेडरूम है। हमने उपकरण पर बहुत सारा पैसा बचाया - परिचालन व्यय में लगभग $5 मिलियन + $750 हजार प्रति वर्ष।

हम सबसे जटिल और बड़े पैमाने की समस्याओं के लिए सर्वोत्तम समाधान खोजने का प्रयास करते हैं। हमारे पास उनमें से बहुत सारे हैं - और यही कारण है कि हम डेटाबेस विभाग में प्रतिभाशाली डेवलपर्स की तलाश कर रहे हैं। यदि आप ऐसी समस्याओं को हल करना पसंद करते हैं और जानते हैं, एल्गोरिदम और डेटा संरचनाओं का उत्कृष्ट ज्ञान रखते हैं, तो हम आपको टीम में शामिल होने के लिए आमंत्रित करते हैं। हमसे संपर्क करें HR, तो आप समझ गए होंगे।

भले ही यह कहानी आपके बारे में न हो, कृपया ध्यान दें कि हम अनुशंसाओं को महत्व देते हैं। किसी मित्र को इसके बारे में बताएं डेवलपर रिक्तियां, और यदि वह सफलतापूर्वक परिवीक्षा अवधि पूरी कर लेता है, तो आपको 100 हजार रूबल का बोनस प्राप्त होगा।

स्रोत: www.habr.com