VKontakte संदेश डेटाबेस सुरवातीपासून पुन्हा लिहा आणि टिकून राहा

आमचे वापरकर्ते थकवा न कळता एकमेकांना संदेश लिहितात.

ते खूप आहे. आपण सर्व वापरकर्त्यांचे सर्व संदेश वाचण्यासाठी सेट केल्यास, यास 150 हजार वर्षांपेक्षा जास्त वेळ लागेल. जर तुम्ही बऱ्यापैकी प्रगत वाचक आहात आणि प्रत्येक संदेशावर एका सेकंदापेक्षा जास्त वेळ घालवू नका.

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

आमच्यासाठी हा क्षण दीड वर्षापूर्वी आला होता. आम्ही येथे कसे आलो आणि शेवटी काय झाले - आम्ही तुम्हाला क्रमाने सांगतो.

पार्श्वभूमी

पहिल्याच अंमलबजावणीमध्ये, VKontakte संदेशांनी PHP बॅकएंड आणि MySQL च्या संयोजनावर कार्य केले. लहान विद्यार्थ्यांच्या वेबसाइटसाठी हा पूर्णपणे सामान्य उपाय आहे. तथापि, ही साइट अनियंत्रितपणे वाढली आणि स्वतःसाठी डेटा स्ट्रक्चर्सच्या ऑप्टिमायझेशनची मागणी करू लागली.

2009 च्या शेवटी, पहिले मजकूर-इंजिन भांडार लिहिले गेले आणि 2010 मध्ये संदेश त्यात हस्तांतरित केले गेले.

मजकूर-इंजिनमध्ये, संदेश सूचीमध्ये संग्रहित केले गेले - एक प्रकारचे "मेलबॉक्सेस". अशी प्रत्येक यादी uid द्वारे निर्धारित केली जाते - ज्या वापरकर्त्याकडे हे सर्व संदेश आहेत. संदेशामध्ये गुणधर्मांचा एक संच असतो: इंटरलोक्यूटर आयडेंटिफायर, मजकूर, संलग्नक इ. “बॉक्स” मधील संदेश अभिज्ञापक लोकल_आयडी आहे, तो कधीही बदलत नाही आणि नवीन संदेशांसाठी अनुक्रमे नियुक्त केला जातो. "बॉक्स" स्वतंत्र आहेत आणि इंजिनमध्ये एकमेकांशी सिंक्रोनाइझ केलेले नाहीत त्यांच्यातील संवाद PHP पातळीवर होतो. तुम्ही डेटा स्ट्रक्चर आणि टेक्स्ट-इंजिनची क्षमता आतून पाहू शकता येथे.

दोन वापरकर्त्यांमधील पत्रव्यवहारासाठी हे पुरेसे होते. पुढे काय झाले याचा अंदाज लावा?

मे 2011 मध्ये, VKontakte ने अनेक सहभागींसोबत संभाषणे सादर केली-मल्टी-चॅट. त्यांच्यासोबत काम करण्यासाठी, आम्ही सदस्य-चॅट्स आणि चॅट-मेंबर्स असे दोन नवीन क्लस्टर्स उभे केले. पहिला वापरकर्त्यांद्वारे चॅट्सचा डेटा संग्रहित करतो, दुसरा चॅटद्वारे वापरकर्त्यांचा डेटा संग्रहित करतो. स्वतः सूचींव्यतिरिक्त, यामध्ये, उदाहरणार्थ, आमंत्रित वापरकर्ता आणि त्यांना चॅटमध्ये जोडण्यात आलेली वेळ यांचा समावेश होतो.

"PHP, चला चॅटवर एक संदेश पाठवू," वापरकर्ता म्हणतो.
“चला, {username},” PHP म्हणतो.

या योजनेचे तोटे आहेत. सिंक्रोनाइझेशन अजूनही PHP ची जबाबदारी आहे. मोठ्या चॅट्स आणि वापरकर्ते जे त्यांना एकाच वेळी संदेश पाठवतात ही एक धोकादायक कथा आहे. मजकूर-इंजिन उदाहरण uid वर अवलंबून असल्याने, चॅट सहभागींना वेगवेगळ्या वेळी समान संदेश प्राप्त होऊ शकतो. प्रगती स्थिर राहिल्यास यासह जगता येईल. पण तसे होणार नाही.

2015 च्या शेवटी, आम्ही समुदाय संदेश लाँच केले आणि 2016 च्या सुरूवातीस, आम्ही त्यांच्यासाठी API लाँच केले. समुदायांमध्ये मोठ्या चॅटबॉट्सच्या आगमनाने, लोड वितरणाबद्दल विसरणे शक्य झाले.

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

2016 मधील संदेश इंजिन चॅट-सदस्य आणि सदस्य-चॅट्सची 100 उदाहरणे आणि 8000 मजकूर-इंजिन आहेत. ते एक हजार सर्व्हरवर होस्ट केले होते, प्रत्येक 64 GB मेमरीसह. प्रथम आपत्कालीन उपाय म्हणून, आम्ही मेमरी आणखी 32 GB ने वाढवली. आम्ही अंदाजांचा अंदाज लावला. कठोर बदलांशिवाय, हे आणखी एक वर्ष पुरेसे असेल. तुम्हाला एकतर हार्डवेअर पकडणे आवश्यक आहे किंवा डेटाबेस स्वतःच ऑप्टिमाइझ करणे आवश्यक आहे.

आर्किटेक्चरच्या स्वरूपामुळे, हार्डवेअरला गुणाकारांमध्ये वाढविण्यास केवळ अर्थ प्राप्त होतो. म्हणजेच, कारची संख्या कमीतकमी दुप्पट करणे - अर्थातच, हा एक महाग मार्ग आहे. आम्ही ऑप्टिमाइझ करू.

नवीन संकल्पना

नवीन दृष्टिकोनाचा मध्यवर्ती सार गप्पा आहे. चॅटमध्ये त्याच्याशी संबंधित संदेशांची सूची असते. वापरकर्त्याकडे चॅटची यादी आहे.

आवश्यक किमान दोन नवीन डेटाबेस आहेत:

• चॅट-इंजिन. हे चॅट वेक्टरचे भांडार आहे. प्रत्येक चॅटमध्ये त्याच्याशी संबंधित संदेशांचा वेक्टर असतो. प्रत्येक संदेशामध्ये चॅटमध्ये एक मजकूर आणि एक अद्वितीय संदेश अभिज्ञापक असतो - chat_local_id.
• वापरकर्ता-इंजिन. हे वापरकर्ते वेक्टरचे संचयन आहे - वापरकर्त्यांसाठी दुवे. प्रत्येक वापरकर्त्याकडे peer_id (इंटरलोक्यूटर - इतर वापरकर्ते, बहु-चॅट किंवा समुदाय) आणि संदेशांचा वेक्टर असतो. प्रत्येक peer_id मध्ये संदेशांचा एक वेक्टर असतो जो त्याच्याशी संबंधित असतो. प्रत्येक संदेशामध्ये एक chat_local_id आणि त्या वापरकर्त्यासाठी एक अद्वितीय संदेश आयडी असतो - user_local_id.

नवीन क्लस्टर्स TCP वापरून एकमेकांशी संवाद साधतात - हे सुनिश्चित करते की विनंतीचा क्रम बदलत नाही. विनंत्या स्वतः आणि त्यांच्यासाठी पुष्टीकरण हार्ड ड्राइव्हवर रेकॉर्ड केले जातात - म्हणून आम्ही इंजिनच्या अपयश किंवा रीस्टार्टनंतर कधीही रांगेची स्थिती पुनर्संचयित करू शकतो. वापरकर्ता-इंजिन आणि चॅट-इंजिन प्रत्येकी 4 हजार शार्ड्स असल्याने, क्लस्टर्समधील विनंती रांग समान रीतीने वितरीत केली जाईल (परंतु प्रत्यक्षात काहीही नाही - आणि ते खूप लवकर कार्य करते).

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

त्याच वेळी, हार्ड ड्राइव्हवरील डेटा स्वतःच दिवसातून एकदाच बदलतो - मॉस्कोमध्ये रात्री उशिरा, जेव्हा भार कमीतकमी असतो. याबद्दल धन्यवाद (डिस्कवरील रचना दिवसभर स्थिर असते हे जाणून), आम्ही निश्चित आकाराच्या ॲरेसह वेक्टर बदलू शकतो - आणि यामुळे, मेमरी वाढू शकते.

नवीन योजनेमध्ये संदेश पाठवणे असे दिसते:

1. PHP बॅकएंड संदेश पाठवण्याच्या विनंतीसह वापरकर्ता-इंजिनशी संपर्क साधतो.
2. वापरकर्ता-इंजिन इच्छित चॅट-इंजिन उदाहरणासाठी विनंती प्रॉक्सी करते, जे वापरकर्ता-इंजिन chat_local_id वर परत येते - या चॅटमधील नवीन संदेशाचा एक अद्वितीय ओळखकर्ता. चॅट_इंजिन नंतर चॅटमधील सर्व प्राप्तकर्त्यांना संदेश प्रसारित करते.
3. युजर-इंजिन चॅट-इंजिनकडून chat_local_id प्राप्त करतो आणि PHP ला user_local_id परत करतो - या वापरकर्त्यासाठी एक अद्वितीय संदेश ओळखकर्ता. हे अभिज्ञापक नंतर वापरले जाते, उदाहरणार्थ, API द्वारे संदेशांसह कार्य करण्यासाठी.

परंतु प्रत्यक्षात संदेश पाठवण्याव्यतिरिक्त, तुम्हाला आणखी काही महत्त्वाच्या गोष्टींची अंमलबजावणी करणे आवश्यक आहे:

• उपसूची, उदाहरणार्थ, संभाषण सूची उघडताना तुम्हाला दिसणारे सर्वात अलीकडील संदेश आहेत. न वाचलेले संदेश, टॅग असलेले संदेश (“महत्त्वाचे”, “स्पॅम” इ.).
• चॅट-इंजिनमध्ये संदेश संकुचित करणे
• वापरकर्ता-इंजिनमध्ये संदेश कॅश करणे
• शोधा (सर्व संवादांद्वारे आणि विशिष्ट एकामध्ये).
• रिअल-टाइम अपडेट (लाँगपोलिंग).
• मोबाइल क्लायंटवर कॅशिंग लागू करण्यासाठी इतिहास जतन करणे.

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

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

चॅट्सपेक्षा बरेच कमी वापरकर्ते असल्याने, चॅट-इंजिनमध्ये यादृच्छिक-प्रवेश डिस्क विनंत्या जतन करण्यासाठी, आम्ही वापरकर्ता-इंजिनमध्ये संदेश कॅशे करतो.

मेसेज शोध वापरकर्ता-इंजिनकडून या वापरकर्त्याच्या चॅट्स असलेल्या सर्व चॅट-इंजिन उदाहरणांसाठी कर्ण क्वेरी म्हणून लागू केला जातो. परिणाम वापरकर्ता-इंजिनमध्येच एकत्रित केले जातात.

बरं, सर्व तपशील विचारात घेतले गेले आहेत, फक्त नवीन योजनेवर स्विच करणे बाकी आहे - आणि शक्यतो वापरकर्त्यांनी ते लक्षात न घेता.

डेटा स्थलांतर

म्हणून, आमच्याकडे एक मजकूर-इंजिन आहे जे वापरकर्त्याद्वारे संदेश संग्रहित करते आणि दोन क्लस्टर चॅट-सदस्य आणि सदस्य-चॅट्स आहेत जे बहु-चॅट रूम आणि त्यातील वापरकर्त्यांबद्दल डेटा संग्रहित करतात. यातून नवीन वापरकर्ता-इंजिन आणि चॅट-इंजिनकडे कसे जायचे?

जुन्या योजनेतील सदस्य-चॅट्स प्रामुख्याने ऑप्टिमायझेशनसाठी वापरल्या जात होत्या. आम्ही त्यातून आवश्यक डेटा चॅट-सदस्यांकडे त्वरीत हस्तांतरित केला आणि नंतर तो स्थलांतर प्रक्रियेत सहभागी होणार नाही.

चॅट-सदस्यांसाठी रांग. त्यात 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