हाईलेड ++ 2017 के साथ सबसे अच्छा अंग्रेजी बोलने वाले

हाईलाड ++ 2017 के साथ " डिब्रीपिंग " की निरंतरता में, हमने पांच सर्वश्रेष्ठ (सम्मेलन के प्रतिभागियों के अनुसार) अंग्रेजी भाषा की रिपोर्टों की एक छोटी समीक्षा तैयार की।

ProxySQL के उपयोग से संबंधित विषयों को शीर्ष अंक दिए गए थे (शीर्ष 5 में इस उपकरण के बारे में दो रिपोर्टें थीं), अमेज़ॅन सार्वजनिक क्लाउड में आवेदन परीक्षण, साथ ही यह एक समस्या बनने पर बड़े पैमाने पर लॉगिंग के सिद्धांत और अपाका काफ्का की निगरानी।

हमने अभी मुफ़्त पहुंच के लिए HighLoad ++ 2017 की सभी रिपोर्टों के वीडियो पोस्ट किए हैं। इस प्लेलिस्ट में हमारे YouTube चैनल पर 150 रिपोर्ट की पूरी सूची।

इस प्लेलिस्ट के अलावा, चैनल में डेटाबेस, आर्किटेक्चर, स्केलिंग, क्वीज, मशीन लर्निंग, और अन्य हाईलोड ज्ञान पर कई सौ वीडियो हैं :)

EC2 के प्रदर्शन परिवर्तनशीलता को मापने

हेनरिक इनगो (मोंगोडीबी सॉल्यूशन आर्किटेक्ट, और अब मानगो डीबी में लीड प्रोडक्टिविटी इंजीनियर)।


प्रतिभागियों द्वारा नोट की गई पहली रिपोर्ट का तर्क है कि सार्वजनिक क्लाउड का उपयोग वास्तव में लोड परीक्षण सहित अपने स्वयं के उत्पादों का परीक्षण करने के लिए किया जा सकता है। इस मामले में, MongoDB DBMS, जिसे अमेज़ॅन क्लाउड का उपयोग करके परीक्षण किया जा रहा है, "प्रयोगात्मक" था। कुल मिलाकर, लगभग 400 हजार घंटे प्रति माह इस कार्य पर खर्च किए जाते हैं, इस समय का लगभग 5% केवल प्रदर्शन परीक्षण है, जिसका मुख्य कार्य अनुकूलन प्रदान करना भी नहीं है, और कुछ सुधारों के परिणामस्वरूप "सबसिडीशन" की अनुमति नहीं देना है।

प्रस्तुति का मुख्य प्रश्न यह है कि सार्वजनिक क्लाउड में प्रतिलिपि प्रस्तुत करने योग्य परीक्षा परिणाम कैसे प्राप्त करें।

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



उसके बाद, कुछ दिलचस्प निर्भरताओं के प्रदर्शन के साथ प्रत्येक सिद्धांतों का परीक्षण करने के परिणामों का विश्लेषण किया जाता है। उदाहरण के लिए, यहां चयनित उदाहरण पर "शोर" स्तर (रिपोर्ट की शब्दावली में) की निर्भरता का एक ग्राफ है:



अमेज़ॅन के बुनियादी ढांचे के विवरण के बारे में जानकारी की कमी के लिए, रिपोर्ट सभी सवालों के जवाब नहीं देती है, कुछ मामलों में केवल धारणाएं बनाती हैं, लेकिन सोचने के लिए कुछ है।

लॉगिंग और रेंटिंग

Vytis Valentinavičius (Lamoda, संचालन का नेतृत्व)


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

रिपोर्ट बताती है कि ऐसी स्थिति को कैसे नहीं सुलझाया जाए, लेकिन इसे कैसे रोका जाए, सिद्धांत रूप में, यह देखते हुए कि कई स्पष्ट समाधानों में उनके नुकसान हैं।

Vytis Valentinavičius इस तथ्य पर केंद्रित है कि लॉग में एक संरचना होनी चाहिए। लेकिन एक ही समय में यह फुलाया नहीं जा सकता। प्रत्येक क्षेत्र को इकट्ठा करने और संग्रहीत करने के लिए एक उद्देश्य होना चाहिए, क्योंकि एकत्रित कोई भी डेटा पैसा है। लमोडा का एक उदाहरण प्रति सेकंड 25 हजार डिबग लॉग संदेश है (प्रति सप्ताह 32 टीबी जानकारी, जिसके लिए अकेले भंडारण की लागत $ 12 हजार है)।
इसके अलावा, घटनाओं को ट्रैक करना महत्वपूर्ण है, न कि विशिष्ट त्रुटियां। भविष्य के एकत्रीकरण के लिए और अधिक जटिल घटनाओं का निर्माण करने के लिए उन्हें एकत्रित, मैट्रिक्स की पहचान की जानी चाहिए, और उनके विश्लेषण के आधार पर।

सैद्धांतिक विचारों के अलावा, रिपोर्ट में कुछ चालों का वर्णन किया गया है जो लैमोडा उत्पादन में लॉग के साथ काम करने के लिए उपयोग करते हैं।

मेट्रिक्स नॉट एनफ: मॉनिटरिंग अपाचे काफ्का

ग्वेन शापिरा (संगम, उत्पाद प्रबंधक)


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

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

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



एक सलाहकार के रूप में ग्वेन शापिरा के विशाल अनुभव के लिए धन्यवाद, पूरी प्रस्तुति जीवन से ज्वलंत उदाहरणों के साथ है।

ProxySQL केस परिदृश्यों का उपयोग करें

एल्किन तेजुसील (पर्कोना, ग्लोबल डीबीए टीम)


दो रिपोर्ट तुरंत, जो प्रतिभागियों के अनुमान के अनुसार, TOP 5 में थे, ProxySQL से संबंधित हैं, MySQL के लिए SQL प्रश्नों को अनुमानित करने का एक साधन है (और, हाल ही में, ClickHouse)।

पहली रिपोर्ट आम तौर पर इस उपकरण का उपयोग करने के लिए परिदृश्यों के बारे में है।

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

सामान्य तौर पर, ProxySQL आपको लोड संतुलन और पुनर्लेखन क्वेरी (जो हमारी सूची से अगली रिपोर्ट में चर्चा की जाएगी), क्वेरी कतार और कैश को गर्म करने से, जो MySQL में नहीं है, से बड़ी संख्या में कार्यों को हल करने की अनुमति देता है। प्रत्येक विकल्प Alkin Tezuysal को विस्तार से बताया गया है, जिसमें समाधान के फायदे और नुकसान और साथ ही विशेष मामलों का उल्लेख किया गया है जिसमें यह उपयोगी हो सकता है।

यहां हम डेटाबेस के अनुकूलन के संबंध में केवल दो उदाहरणों का उल्लेख करते हैं।

उदाहरण 1 - डेटाबेस से एप्लिकेशन कनेक्शन स्थापित करने के लिए अनुरोधों की संख्या को कम करने के लिए ProxySQL का उपयोग करना। रिपोर्ट में दिए गए ग्राफ में विचार रेखांकन परिलक्षित होता है:



ProxySQL काफी कनेक्शन अनुरोधों की संख्या को कम कर देता है, खासकर जब SSL का उपयोग कर रहा हो।

उदाहरण 2 - बेकार प्रश्नों को फ़िल्टर करना (जैसे कि चयन 1, बड़े पैमाने पर अनुप्रयोगों में प्रकट) जो डेटाबेस को धीमा कर देते हैं। यहाँ, परिणाम का सबसे अच्छे ढंग से मूल्यांकन किया गया है:

ProxySQL के साथ MySQL के लिए सस्ती डेटामाकिंग - डेवलपर्स के लिए डेटा अनामीकरण

Rene Cannao (संस्थापक और उत्पाद स्वामी ProxySQL)



ProxySQL पर दूसरी अंग्रेजी-भाषा की रिपोर्ट, जो TOP-5 में मिलती है, एक बहुत ही विशिष्ट समस्या - डेटा मास्किंग को हल करने के लिए समर्पित है।

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

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

यदि ProxySQL के बारे में पहली कहानी अधिक सैद्धांतिक थी, तो यहां एक निरंतर अभ्यास है। यहां तक ​​कि नियमित अभिव्यक्ति का उपयोग करके कॉन्फ़िगर किए गए नियम सूचीबद्ध हैं।





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

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

बेशक, यह अंग्रेजी बोलने वाला पांच हिमलिंग का एक सिरा है जो कि HighLoad ++ 2017 में था। इसलिए, हमें याद है कि हमने इस सम्मेलन की सभी रिपोर्टों के वीडियो पोस्ट किए हैं जो इस प्लेलिस्ट में मिल सकते हैं।

मॉस्को में 8 और 9 नवंबर को स्कोलोवो में हाईलाड ++ 2018 आयोजित किया जाएगा। कार्यक्रम पर काम पहले से ही चल रहा है, लेकिन रिपोर्ट 1 सितंबर से पहले प्रस्तुत की जा सकती है।