टारनटूल: प्रति दिन 1.5 बिलियन अनुरोधों को कैसे संभालना है?

टारनटूल रिपोर्ट: प्रति दिन 1.5 बिलियन अनुरोध कैसे संसाधित करें? "- Mail.Ru प्रौद्योगिकी मंच 2011 से टेप की एक श्रृंखला में अगले। रिपोर्ट को डिक्रिप्ट करने की प्रणाली कैसे काम करती है, इसके विवरण के लिए, Mail.Ru टेक्नोलॉजी फोरम का “इनसाइड आउट” लेख देखें : इवेंट-मैनेजमेंट में उच्च तकनीक । वहाँ, साथ ही साथ फोरम की वेबसाइट ( http://techforum.mail.ru ) पर - अन्य रिपोर्टों के लिपियों के लिंक।

(मोबाइल उपकरणों के लिए वीडियो संस्करण डाउनलोड करें - iOS / Android H.264 480 × 368, आकार 170 एमबी, वीडियो बिटरेट 500 केबीपीएस, ऑडियो - 64 केबीपीएस)
(उच्च संकल्प वीडियो संस्करण H.264 624 × 480 डाउनलोड करें , आकार 610 एमबी, वीडियो बिटरेट 1500 केबीपीएस, ऑडियो 128 केबीपीएस)
(प्रेजेंटेशन स्लाइड्स डाउनलोड करें , 520K)

इस स्पीकर को पेश करना कठिन है क्योंकि हर कोई उसे जानता है। आप में से प्रत्येक, मुझे यकीन है, उन उत्पादों का उपयोग करता है जिनमें कोस्त्या का हाथ था। यह मुख्य रूप से MySQL है। कोस्त्या वर्षों से इस लोकप्रिय डेटाबेस को विकसित कर रहा है, जिसका उपयोग 100% नहीं तो 90% रूसी साइटों के लिए किया जाता है। आज Kostya Mail.Ru Group के लिए काम करता है। कोस्त्या आज हमें बताएंगे कि हमने क्या किया है, यह कैसे काम करता है, और सबसे महत्वपूर्ण बात - यह किस तरह का प्रदर्शन आपको अपनी सेवाओं पर लाने की अनुमति देगा।



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

टारनटूल की कोशिश करने के लिए इस रिपोर्ट में कौन आया था, इसके बारे में अधिक जानें इस फोरम में? क्या ऐसे लोग हैं?

यह बहुत अच्छा है, क्योंकि सामान्य तौर पर टारनटूल एक ऐसी प्रणाली है जो Mail.Ru Group द्वारा विकसित की गई है और हमारी कंपनी में सबसे अधिक सक्रिय रूप से उपयोग की जाती है, लेकिन इसकी व्यापक प्रयोज्यता है। यह एक ओपन-सोर्स सिस्टम है, जो मेरी राय में, अच्छी तरह से प्रलेखित है, हमारे पास कई प्रोग्रामिंग भाषाओं के लिए कनेक्टर हैं - पायथन, रूबी, पर्ल। हाल ही में, दो दिन पहले, समुदाय के सदस्यों में से एक ने पायथन के लिए एक नया कनेक्टर लिखा था। इसलिए, मुझे उम्मीद है कि आज हमारी बातचीत का परिणाम यह होगा कि आप टारनटूल की कोशिश करेंगे। और शायद आप कहेंगे कि यह क्यों बेकार है - मैं इस तरह की समीक्षा को सुनकर प्रसन्न होगा।



मैं किस बारे में बात करूंगा? चूंकि रिपोर्ट का विषय महत्वाकांक्षी नहीं है, इसलिए मैं डीबीएमएस पारिस्थितिकी तंत्र में टारनटूल के स्थान के बारे में बात करूंगा: हमारे पास अब डेटा संग्रहीत करने के लिए इतने सारे समाधान क्यों हैं, यह राशि पर्याप्त क्यों है। इसके बाद, हम सिस्टम पर सीधे जाएंगे, इसके विश्लेषण के लिए कि यह क्या कर सकता है। मैं अपनी योजनाओं के बारे में, टीम की योजनाओं के बारे में, हम उत्पाद में क्या विशेषताएं जोड़ेंगे, आदि के बारे में एक कहानी के साथ समाप्त करूंगा।



यहाँ ऐसी तस्वीर है, सिर्फ आधे घंटे में मैंने इन सभी लोगो को प्रशिक्षित किया। आप में से कितने लोग इन आधे से ज्यादा लोगो को पहचानते हैं? अल्पसंख्यक। यानी आप में से कई लोग MySQL को जानते हैं, शायद Memcached, शायद PostgreSQL। वास्तव में यही सब है।

आज हमने Hadoop के बारे में एक बात सुनी और देखा कि वास्तव में ये सभी प्रणालियाँ बहुत व्यापक रूप से उपयोग की जाती हैं और बहुत लोकप्रिय हैं। और यह सभी ओपन सोर्स सिस्टम हैं। हम देखते हैं कि सिस्टम सॉफ्टवेयर की दुनिया तेजी से खुले स्रोत की ओर बढ़ रही है। पूर्व याहू प्रोग्रामर्स द्वारा विकसित एकमात्र नॉन-ओपन सोर्स सिस्टम Citrusleaf है। यह काफी समृद्ध वाणिज्यिक प्रणाली है।

यदि हम इस स्लाइड का विश्लेषण उन डेटा विशेषताओं के दृष्टिकोण से करते हैं जिनके लिए उल्लेखित प्रणालियों का इरादा है, तो हम दो आयाम पाएंगे। पहला आयाम डेटा की मात्रा है। हम देखते हैं - कैसंड्रा, हडोप, वोल्डेमॉर्ट - ये ऐसी प्रणालियाँ हैं जिन्हें बड़ी मात्रा में डेटा का प्रबंधन करने के लिए डिज़ाइन किया गया है। तस्वीर के दूसरी तरफ हम उन प्रणालियों को देखते हैं जो अक्सर बहुत बड़ी मात्रा में डेटा के साथ काम नहीं करते हैं, लेकिन इस डेटा तक बहुत उच्च-प्रदर्शन पहुंच प्रदान करते हैं। दूसरा आयाम डेटा संरचना का स्तर है। और ये सिर्फ दो मैट्रिक्स हैं जिनके द्वारा हम इन प्रणालियों की तुलना कर सकते हैं। वास्तव में, NoSQL दुनिया के आयाम बहुत बड़े हैं। NoSQL आंदोलन क्यों आया और हम इस धन को क्यों देखते हैं? मेरी राय में, पारंपरिक DBMS की दुनिया में 3 मुख्य अनसुलझी समस्याएं हैं। आप 10, 20 समस्याएं पा सकते हैं, लेकिन संबंधपरक डीबीएमएस की मुख्य और वास्तव में खराब हल की गई समस्याएं इस प्रकार हैं:



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

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

अच्छी तरह से और अंततः समस्या # 3 प्रदर्शन है। यह गैस की कीमत की तरह है, यानी अगर यह एक 20 साल पहले था और इंजन 4-6 लीटर थे , अब हम सोच रहे हैं कि एक ही लीटर गैसोलीन या एक लीटर आंतरिक दहन इंजन से बहुत अधिक हॉर्स पावर या किलोमीटर को कैसे निचोड़ें। । पारंपरिक डीबीएमएस पुरानी अमेरिकी कारों के समान हैं - वे चमड़े की आंतरिक और उच्च चिकनाई के साथ बड़े, सुंदर हैं। लेकिन पारंपरिक डीबीएमएस की वास्तुकला अन्य हार्डवेयर की अपेक्षा के साथ बनाई गई थी, एक अलग अनुप्रयोग। हार्ड ड्राइव की गति, मेमोरी की गति, यह सब करने के लिए सीपीयू और सीपीयू कैश की गति का अनुपात ... सामान्य तौर पर, सिस्टम आर के बाद से बहुत कुछ बदल गया है। और Mail.Ru Group जैसे डेटा केंद्रों में, जहाँ दसियों हज़ार कंप्यूटर हैं, यह बहुत ही कारक - संबंधपरक DBMS की ऊर्जा दक्षता - अत्यंत महत्वपूर्ण है। दरअसल, जब NoSQL प्रश्नों को संसाधित करते हैं, तो SQL पार्सिंग के लिए संपूर्ण ओवरहेड, एक प्रभावी क्वेरी निष्पादन योजना की खोज, और कई रीडिंग की स्थिरता सुनिश्चित करना अनावश्यक हो जाता है।

और, इस तथ्य के बावजूद कि पारंपरिक DBMS की समस्याओं को आमतौर पर वैज्ञानिकों और चिकित्सकों के समुदाय द्वारा समझा, अध्ययन और मान्यता प्राप्त है, NoSQL दुनिया ने इन समस्याओं के नए समाधानों के साथ न केवल जवाब दिया, बल्कि एक साफ स्लेट के साथ, विचारों का विस्फोट, और अक्सर जहां वास्तव में, विस्फोट करने के लिए। कुछ नहीं चाहिए। उदाहरण के लिए, डेटा मॉडल जैसे क्षेत्रों में। यानी NoSQL दुनिया ने एडगर कॉड के प्रसिद्ध मॉडल और प्रस्तावित प्रतिमानों जैसे कॉलम स्टोरेज - कॉलम-ओरिएंटेड स्टोरेज, की-वैल्यू स्टोरेज, JSON और XML फॉर्मेट को गिरा दिया।


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

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

और अंत में, हम डेटा संग्रहण एल्गोरिदम के निरंतर विकास को देख रहे हैं, जो हमेशा बहुत महत्वपूर्ण है, और बड़ी संख्या में नए स्केलिंग तरीकों का निर्माण, जैसे कि निरंतर हैशिंग , मास्टर-मास्टर प्रतिकृति , आदि।

DBMS दुनिया का भविष्य क्या है, NoSQL आंदोलन किस ओर ले जाएगा? मेरी राय में, डेटा स्टोरेज सॉल्यूशंस की दुनिया का विस्तार होगा, और एप्लिकेशन इंजीनियरों को यह जानने के लिए मजबूर किया जाएगा कि Hadoop जैसे NoSQL रिपॉजिटरी, रिलेशनल रिपॉजिटरी और वितरित क्लस्टर हैं। इस प्रकार, भविष्य में उत्पादों की विविधता से, तीन निचे बनेगी, समाधान के तीन बुनियादी क्लस्टर, जिनमें से एक संबंधपरक डीबीएमएस है, जो स्वाभाविक रूप से आने वाले लंबे समय तक रहेगा।


डेटा मॉडल के साथ कई प्रयोगों को बढ़ावा मिलेगा? उदाहरण के लिए, Redis के प्रतिमान, जिसे डेटा स्ट्रक्चर्स सर्वर के रूप में भी जाना जाता है, क्या यह दृष्टिकोण फैल जाएगा? मेरी राय में, डेटा मॉडल को लगभग दो मौलिक दृष्टिकोणों को भी स्थिर करना होगा: एक दृष्टिकोण जो प्रस्तुति से मॉडल के एक अमूर्त की उपस्थिति का तात्पर्य करता है, और यहां रिलेशनल मॉडल की तुलना में बेहतर अमूर्तता अभी तक प्रस्तावित नहीं की गई है, और डेटा मॉडल स्वयं।

इसके साथ, मैं आधुनिक डीबीएमएस की दुनिया की समीक्षा को पूरा करना चाहूंगा। पूर्वानुमान एक कृतघ्नता है, लेकिन NoSQL DBMS की दुनिया में टारेंटूल की जगह का विचार देने के लिए, मैंने कुछ सामान्य चित्र देने का फैसला किया।

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

टारनटूल एक स्थिर भंडारण है। डेटा रैम में संग्रहीत होता है, लेकिन सभी डेटा परिवर्तन परमाणु होते हैं, अर्थात टारनटूल में दर्ज की गई हर चीज को डिस्क पर लिखा जाता है।

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

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

डेटा एक्सेस भाषा के क्षेत्र में, टारनटूल समाधान एक SQL भाषा है, हालांकि अन्य प्रोग्रामिंग भाषाओं के लिए समर्थन है।


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

सरल INSERT / UPDATE / SELECT / DELETE प्रश्नों के अलावा, हम Lua संग्रहीत कार्यविधियों का समर्थन करते हैं जो आपको बहुत ही लचीले ढंग से यह निर्धारित करने की अनुमति देती हैं कि आपके पास कौन-सी डेटा एक्सेस स्क्रिप्ट है। संग्रहीत कार्यविधियाँ होने से आप टारेंटूल को डेटा सर्वर से व्यावसायिक तर्क सर्वर में बदल सकते हैं, क्योंकि यह एक मनमाना डेटा भंडारण प्रारूप, डेटा स्थिरता के मध्यस्थों, मनमाने ढंग से प्रश्नों को मनाना संभव हो जाता है।

दर्शकों से सवाल:

डेटा की दृढ़ता कैसे बनी रहती है?

हम लॉगिंग का उपयोग करते हैं, अर्थात्। सभी प्रविष्टियों को डिस्क में लॉग किया गया है। अब मैं इस बारे में बात करूंगा, लेकिन पहले डेटा मॉडल के बारे में।


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



इंडेक्स या तो सरल या यौगिक हो सकते हैं, और किसी भी इंडेक्स का उपयोग खोज करने के लिए किया जा सकता है। हालांकि, प्रत्येक स्थान में, एक साधारण प्राथमिक कुंजी निर्दिष्ट की जानी चाहिए, जिसे डालने, अपडेट करने या हटाने के दौरान उपयोग करने के लिए उपयोग किया जाना चाहिए। एक समग्र माध्यमिक कुंजी के माध्यम से पहुंचना संभव है, उदाहरण के लिए, खेतों 3 और 5 के माध्यम से, या खेतों 7, 9, 11 के माध्यम से।





फिर, हम डेटा एक्सेस लैंग्वेज के क्षेत्र में कुछ विचारक नहीं हैं - हमारा क्लाइंट एसक्यूएल एक्सेस लागू करता है, और अन्य प्रोग्रामिंग भाषाओं से कनेक्टर्स के क्षेत्र में हम पारंपरिक डीबीएमएस की दुनिया से समझौतों का पालन करते हैं। यहाँ PHP में ऐसा दिखता है:


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


ट्यूपल्स का चयन करने के मामले में, हम कुंजी नंबर का चयन करते हैं जिसके द्वारा अनुरोध किया जाता है - या तो यह नंबर 0 के साथ प्राथमिक कुंजी है, या अन्य कुंजी है।


कार्यक्षमता का एक सामान्य अवलोकन दिए जाने के बाद, मैं इस पर आगे बढ़ना चाहूंगा कि हम अन्य NoSQL सिस्टम से कैसे अलग हैं, जो आपने पहले से काम किया था।

मैं प्रदर्शन के साथ शुरुआत करूंगा। सामान्य तौर पर, चूंकि यह रैम में डेटा स्टोरेज है, इसलिए प्रदर्शन शुरू में पारंपरिक DBMS की तुलना में काफी अधिक है, जैसे कि, उदाहरण के लिए, MySQL। हम कई कनेक्शनों के लिए एसिंक्रोनस I / O और अतुल्यकालिक समर्थन का उपयोग करते हैं। हम आसानी से 10,000 सक्रिय यौगिकों को पकड़ते हैं। एक मशीन पर हमारा प्रदर्शन, इस तथ्य के बावजूद कि हम आगे लॉग में लिखने के सभी बदलाव लिख रहे हैं, अर्थात्। हम डिस्क में सभी परिवर्तनों को लॉग करते हैं, यह 100,000 UPDATEs और INSERTs प्रति सेकंड तक पहुंचता है। इस मशीन पर रीड रिक्वेस्ट के लिए, हमने प्रति सेकंड 260,000 चयन का प्रदर्शन हासिल किया। ये इस तरह के सुपरडिजिट नहीं हैं: वे मेम्चे या रेडिस के प्रदर्शन के लिए तुलनीय हैं।

और क्या लेटेंसी? प्रतिक्रिया में देरी कितनी है?

सवाल बहुत अच्छा है।

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

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


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

आप किस फ़ाइल सिस्टम का उपयोग कर रहे हैं?

हम किसी भी फाइल सिस्टम का उपयोग करते हैं। यदि आपके पास इस विशेष पर चलने वाला ZFS है, उदाहरण के लिए लिनक्स, तो कृपया। इस स्थिति में, हम फ़ाइलों के साथ काम करने के लिए POSIX API का उपयोग करते हैं। हमारे द्वारा उपयोग की जाने वाली एकमात्र नॉन-पॉसिक्स कॉल फॉलोसिट () है, जो, मेरी राय में, JFS, XFS और EXT4 पर समर्थित है।


हम क्यों फैलोकेट () का उपयोग कर रहे हैं? यह आधुनिक फ़ाइल सिस्टम के काम करने के तरीके के कारण है। इसे और अधिक विस्तार से वर्णित करने की आवश्यकता है, मुझे इसे बाद में करने दें।

ग्राहकों के संबंध में एक और विशिष्ट प्रश्न यह है कि हम एक ग्राहक से एक ही स्थान पर एक ही कुंजी के 1000 GET तक कैसे पहुँच प्राप्त करें। क्या हम किसी तरह इस व्यवसाय को प्रॉक्सी कर सकते हैं? 1000 अनुरोधों को न भेजें ...

GET कैसे काम करता है और क्या यह प्रॉक्सी करना संभव है? टारेंटूल में एक क्लाइंट प्रोटोकॉल है। उदाहरण के लिए, मेमेचे पाठ और बाइनरी प्रोटोकॉल का समर्थन करता है। हमने इसी तरह से काम किया है। बाइनरी प्रोटोकॉल मुख्य रूप से उपयोग किया जाता है जिसमें GET आदेशों में से एक है। कमांड कोड अनुरोध पैकेट हेडर में 4 बाइट्स लेता है, पूरा हेडर 12 बाइट्स लेता है। शीर्ष लेख के दूसरे चार बाइट्स में अनुरोध आईडी होती है। अनुरोध आईडी विशिष्ट चिन्हित करने के लिए विशिष्ट रूप से चिह्नित करने के लिए एक साधन है। अनुरोध के जवाब में, सर्वर ने अनुरोधित आईडी को वापस कर दिया। यह आपको प्रॉक्सी अनुरोधों को काफी सरलता से अनुमति देता है, और यह Mail.Ru Group द्वारा सक्रिय रूप से उपयोग किया जाता है। , , Tarantool, request-id Tarantool' .

commit, ?

, . . group commit, . wal_fsync_delay — 0.01 . , Linux. Tarantool, MySQL. , , NUMA- MySQL, . — . , - Mail.Ru wal_fsync_delay 0.01 , .

Tarantool?

हाँ है। .

, Tarantool MySQL?

. , Tarantool, MySQL, Mail.Ru Group, . MySQL, .
. . , GET, , 700 . . , .



SET' . , (Intel Core I7, 7200 ), 300 000 700 000 .


, . 1.5 1.4. UPDATE's. , UPDATE'. .




, , , . Tarantool Key-Value, Trantool , .


auto-increment. PHP, NoSQL Tarantool, - -. UPDATE, , , . , . -, , , . .






Tarantool, . , , — .. space 0. , . , — , .


, , . , Tarantool .

« = tuple ()». क्योंकि , . : № 0 — , № 1 — , .. . № 2 , , , , . , . , . top bottom, UPDATE , box.update() — , callback . , UPDATE , , , printf(). , , =p=p=p, '=' () 1 'p' ( ) top, '=' () 2 'p' ( ) bottom, '=' () top val.




UPDATE, , , , , . , . .




, , Lua. , Lua . Javascript…


. , LuaJIT — just-in-time compiler, open source . — . Lua , , , - . , GitHub Tarantool, .


, , , - — ?

, -, - . , , 2 2 max+1.

, . , . Tarantool . ? , , WAL. 1 Tarantool 1 . , fiber', coroutines - , -. , ; , , , multi-threaded , . ? nodes, Tarantool. 2-4 . Tarantool — shared nothing MPI . .

? Mail.Ru Group.

- , , . , , , , . यानी , . — Memcache, Memcache- Memcache expiry — , , , , Lua. Mail.Ru. 4 , 2 Tarantool'. 2 , 2 . 60 100 , Mail.Ru .


, , , Tarantool , Tarantool , , , . , . , , , . - , 400 , . , . Tarantool 120 , , . , 2 , 60 . production , , . , , 20%.

. MongoDB. Mongo , . , . , ..

Mongo ? Mongo — , c Write Ahead Log', ?

, .

, Tarantool . Tarantool snapshot', . , , . copy-on-write, Redis. Write Ahead Log. , Write Ahead Log'. , 0.01 .

MySQL , , , . Tarantool ?

. Tarantool, , MSQL? MSQL , Write Ahead Log, , .. MSQL . Tarantool Write Ahead Log — . : Write Ahead Log . , , , . Write Ahead Log (log sequence number, LSN), , , , .

हम अब इस तरह की स्थितियों को स्पष्ट करने के लिए एक बिनलॉग का उपयोग कर रहे हैं - उदाहरण के लिए, एक व्यक्ति कहता है: मैंने एक महीने पहले यहां 5 लिखा था , मेरे पास 8. क्यों है। और इस दौरान बिनलॉग को देखकर, हम आपको बता सकते हैं कि वास्तव में कब, कौन, क्या बदल गया। क्या आपका भी यहाँ ऐसा कोई फंक्शन है?

हां, आप इस जानकारी को संग्रहीत कर सकते हैं। बस बिनलॉग बहुत बड़े हो सकते हैं, इसलिए हम स्नैपशॉट का भी उपयोग करते हैं। जैसे ही आप स्नैपशॉट लेते हैं, स्नैपशॉट लेने से पहले रिकॉर्ड किए गए सभी बिनलॉग को हटाया जा सकता है।



आखिरी पैटर्न जिसके बारे में मैं बात करना चाहूंगा वह यह है कि वर्तमान में हम मेरी दुनिया में लागू कर रहे हैं।

स्लाइड पर, आप संख्याएँ देखते हैं जैसे 6, 83, 1, 21, 8, आदि। ये तथाकथित सूचनाएं हैं: "आपकी तस्वीर को 44 उपयोगकर्ताओं द्वारा रेट किया गया था, 83 लोग एक दोस्त के रूप में vaz जोड़ना चाहेंगे।" अधिसूचना प्रणाली कैसे काम करती है? प्रत्येक उपयोगकर्ता के साथ एक निश्चित प्रकार की सूचनाएं जुड़ी होती हैं: फोटो, संदेश सूचनाएं, मित्र-अनुरोध, आदि। कुल मिलाकर, अब हमारे पास इस प्रकार के हैं 5. प्रत्येक प्रकार की अधिसूचना के लिए, हम नवीनतम सूचनाओं के रिंग बफर का समर्थन करते हैं। यदि आपको 30 मित्र-अनुरोध प्राप्त हुए हैं, तो हम इस रिंग बफर में अंतिम 20 स्टोर करते हैं, क्योंकि रिंग बफर की लंबाई 20 है। और इसलिए प्रत्येक प्रकार की अधिसूचना के लिए।

टारनटूल का उपयोग रिंग बफ़र्स को स्टोर करने के लिए किया जाता है। यानी प्रत्येक उपयोगकर्ता के लिए प्रत्येक प्रकार की अधिसूचना के लिए 5 बफ़र जुड़े हुए हैं। 2 बुनियादी ऑपरेशन हैं, पहला "उपयोगकर्ता के लिए अधिसूचना जोड़ें" है। टारनटूल पुष्टि करता है कि यह अधिसूचना अभी तक इस विशेष उपयोगकर्ता के लिए नहीं जोड़ी गई है। हम यह सब एक डेटा संरचना में संग्रहीत करते हैं, कॉम्पैक्ट रूप से, एक स्थान पर, दिए गए उपयोगकर्ता के लिए सभी रिंग बफ़र्स इस उपयोगकर्ता के एक टपल में संग्रहीत होते हैं। मुझे बताओ, जो SQL सिस्टम आपको यह अवसर देता है? मुझे नहीं पता है कि

रिंग बफ़र्स के साथ काम करने का दूसरा आदेश "अधिसूचना पढ़ें" है। मान लीजिए कि कोई उपयोगकर्ता अपने पृष्ठ पर जाता है, तो अधिसूचना बटन पर क्लिक करता है, उन्हें पढ़ता है। अपठित अपडेट का काउंटर शून्य पर रीसेट होना चाहिए।

अपठित सूचनाओं को जोड़ने, पढ़ने और गिनने के सभी तर्क सर्वर पर किए जाते हैं।

नोटिफिकेशन_पश () प्रक्रिया एक अद्वितीय अधिसूचना के लिए स्वचालित रूप से जांच करती है। यह तीन पैरामीटर लेता है - user_id, सूचना प्रकार और अधिसूचना पहचानकर्ता। अधिसूचना पहचानकर्ता MySQL में सूचना ऑब्जेक्ट के लिए प्राथमिक कुंजी हो सकती है, अर्थात, अब आपको शीर्ष पृष्ठ पर अधिसूचना पाठ को प्रदर्शित करने की आवश्यकता नहीं है, आप इसे MySQL में संग्रहीत कर सकते हैं, जिससे आपके मुख्य DBMS को कई छोटे प्रश्नों से अनलोड किया जा सकता है।

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

आइए देखें कि कैसे notification_push () काम करता है। एक अधिसूचना जोड़ने के लिए, हम नए अपठित गणना मान की गणना करते हैं, UPDATE रिंग बफर के लिए एक कमांड बनाते हैं और इस कमांड को निष्पादित करते हैं। एक अधिसूचना को जोड़कर परमाणु प्रदर्शन किया जाता है।



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



टारनटूल, सबसे पहले, वोल्डेमॉर्ट के लिए एक अच्छा बैकेंड होगा, रीक के लिए, हम स्केलिंग के लिए अपनी प्रणाली लिखेंगे, यह पहले से ही निकट भविष्य में है। हम 100 मशीनों पर कैसे काम करते हैं, इस बारे में आपके प्रश्नों की चेतावनी देकर, आप देखते हैं कि Mail.Ru, इतने बड़े प्रोजेक्ट में, अब 4, 6 मशीनों का उपयोग करता है, अर्थात्। समस्या सबसे तीव्र नहीं है। हम इस दिशा में आगे बढ़ रहे हैं, लेकिन स्केलिंग की कोई एकीकृत प्रणाली नहीं होगी।

हमारी योजनाएं, सबसे पहले, सर्वर इंस्टेंस, लेनदेन समर्थन, मास्टर-मास्टर प्रतिकृति, प्रतिकृति ट्रिगर के क्लस्टर को प्रबंधित करने के स्वचालन हैं। हमारे पास बड़ी संख्या में योजनाएं हैं: उत्पाद का प्रयास करें और हमें बताएं कि उन्हें कैसे बदलना है। आपका धन्यवाद

---

यह पाठ मेल.रू टेक्नोलॉजी फोरम 2011 में कोन्स्टेंटिन ओसिपोव की एक रिपोर्ट का एक प्रतिलिपि है, जो 16 नवंबर को इन्फोपेस सेंटर में हुआ था। वीडियो रिपोर्ट के लिए पाठ बनाने के लिए तकनीक के बारे में विवरण के लिए, यहां देखें: द इनसाइड आउट ऑफ द मेल.रु टेक्नोलॉजी फोरम: हाई-टेक इवेंट-मैनेजमेंट । अन्य रिपोर्ट (मोबाइल उपकरणों के लिए संस्करण सहित) के वीडियो संस्करण फोरम वेबसाइट - techforum.mail.ru पर उपलब्ध हैं। रिपोर्ट के पाठ संस्करण हर हफ्ते या फ़ोरम वेबसाइट पर एक समान प्रारूप में प्रायः या कुछ कम प्रकाशित किए जाएंगे। कृपया पाठ में टाइपो के बारे में पीएम को सूचित करें।