VKontakte सन्देश डाटाबेस स्क्र्याचबाट पुन: लेख्नुहोस् र बाँच्नुहोस्

हाम्रा प्रयोगकर्ताहरूले थकान थाहा नपाई एकअर्कालाई सन्देशहरू लेख्छन्।

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

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

हाम्रो लागि, यो क्षण डेढ वर्ष पहिले आएको थियो। हामी यो कसरी आयो र अन्तमा के भयो - हामी तपाईंलाई क्रम मा बताउँछौं।

पृष्ठभूमि

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

2009 को अन्त्यमा, पहिलो पाठ-इन्जिन भण्डार लेखिएको थियो, र 2010 मा सन्देशहरू यसलाई हस्तान्तरण गरिएको थियो।

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

यो दुई प्रयोगकर्ताहरू बीच पत्राचारको लागि पर्याप्त थियो। त्यसपछि के भयो अनुमान गर्नुहोस्?

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

"PHP, च्याटमा सन्देश पठाउनुहोस्," प्रयोगकर्ता भन्छन्।
"आउनुहोस्, {username}," PHP भन्छ।

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

2015 को अन्त्यमा, हामीले सामुदायिक सन्देशहरू लन्च गर्यौं, र 2016 को सुरुमा, हामीले तिनीहरूका लागि API सुरु गर्यौं। समुदायहरूमा ठूला च्याटबटहरूको आगमनको साथ, लोड वितरणको बारेमा पनि बिर्सन सम्भव थियो।

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

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

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

नयाँ अवधारणा

नयाँ दृष्टिकोणको केन्द्रीय सार कुराकानी हो। च्याटसँग सम्बन्धित सन्देशहरूको सूची हुन्छ। प्रयोगकर्तासँग च्याटहरूको सूची छ।

आवश्यक न्यूनतम दुई नयाँ डाटाबेस हो:

• च्याट इन्जिन। यो च्याट भेक्टरहरूको भण्डार हो। प्रत्येक च्याटमा सन्देशहरूको भेक्टर हुन्छ जुन यससँग सम्बन्धित छ। प्रत्येक सन्देशमा च्याट भित्र पाठ र एक अद्वितीय सन्देश पहिचानकर्ता हुन्छ - chat_local_id।
• प्रयोगकर्ता इन्जिन। यो प्रयोगकर्ता भेक्टरहरूको भण्डारण हो - प्रयोगकर्ताहरूका लागि लिङ्कहरू। प्रत्येक प्रयोगकर्तासँग peer_id (interlocutors - अन्य प्रयोगकर्ताहरू, बहु-च्याट वा समुदायहरू) र सन्देशहरूको भेक्टर हुन्छ। प्रत्येक peer_id सँग सम्बन्धित सन्देशहरूको भेक्टर हुन्छ। प्रत्येक सन्देशमा chat_local_id र त्यो प्रयोगकर्ताको लागि एक अद्वितीय सन्देश ID हुन्छ - user_local_id।

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

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

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

नयाँ योजनामा ​​सन्देश पठाउँदा यस्तो देखिन्छ:

1. PHP ब्याकइन्डले सन्देश पठाउन अनुरोधको साथ प्रयोगकर्ता-इन्जिनलाई सम्पर्क गर्दछ।
2. प्रयोगकर्ता-इन्जिनले इच्छित च्याट-इन्जिन उदाहरणमा अनुरोधलाई प्रोक्सीहरू दिन्छ, जुन प्रयोगकर्ता-इन्जिन chat_local_id मा फर्किन्छ - यो च्याट भित्र नयाँ सन्देशको एक अद्वितीय पहिचानकर्ता। च्याट_इन्जिनले च्याटमा सबै प्राप्तकर्ताहरूलाई सन्देश प्रसारण गर्दछ।
3. प्रयोगकर्ता-इन्जिनले च्याट-इन्जिनबाट chat_local_id प्राप्त गर्छ र PHP मा user_local_id फर्काउँछ - यो प्रयोगकर्ताको लागि एक अद्वितीय सन्देश पहिचानकर्ता। यो पहिचानकर्ता तब प्रयोग गरिन्छ, उदाहरणका लागि, API मार्फत सन्देशहरूसँग काम गर्न।

तर वास्तवमा सन्देशहरू पठाउनुको अतिरिक्त, तपाईंले केही थप महत्त्वपूर्ण कुराहरू लागू गर्न आवश्यक छ:

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

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

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

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

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

ठिक छ, सबै विवरणहरूलाई ध्यानमा राखिएको छ, बाँकी सबै नयाँ योजनामा ​​स्विच गर्नु हो - र अधिमानतः प्रयोगकर्ताहरूले यसलाई ध्यान नदिईकन।

डाटा माइग्रेसन

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

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

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

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

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

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

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

हामी आयातित सन्देशहरू भण्डारण गर्न विशेष डाटा संरचना प्रयोग गर्छौं।

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

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

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

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

Результаты

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

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

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

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

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

स्रोत: www.habr.com