2012 का हाईलोड

मॉस्को में कुछ दिनों पहले " हाई लोडेड सिस्टम के डेवलपर्स का एक सम्मेलन" हाईलाड ++ था , जिसमें से मैं एक प्रतिभागी बनने के लिए भाग्यशाली था। नीचे मैं उन रिपोर्टों पर संक्षेप में जाना चाहता हूं जो मैंने सम्मेलन के दौरान देखीं, उनमें मेरी राय में दिलचस्प बिंदुओं पर प्रकाश डाला।

मैं तुरंत आपको चेतावनी दूंगा कि मैं कुछ चीजों को गलत समझ सकता हूं, कुछ को गलत समझ सकता हूं। यदि यह आपके लिए महत्वपूर्ण है - इस पोस्ट को न पढ़ें, लेकिन व्यक्ति में अगले सम्मेलन में आएं!

दिन 1

भंडारण और VKontakte सामग्री का वितरण

रिपोर्ट दो साल पहले एक कहानी के साथ शुरू हुई जब मैंने पाशा ड्यूरोव से पूछा कि VKontakte उपयोगकर्ता डेटा कैसे संग्रहीत करता है? उस दिन, पाशा ने "डिस्क पर" उत्तर दिया। तब से, मैं उसे पसंद नहीं करता हूं :) इस बार ओलेग (स्पीकर) ने इस सवाल का जवाब पूरी तरह से देने का वादा किया, उसे पूरी रिपोर्ट समर्पित की।

प्रारंभ में, सभी फ़ाइलों (फ़ोटो) को अपलोड फ़ोल्डर में कोड के समान सर्वर पर संग्रहीत किया गया था। यह दृष्टिकोण सरल है, लेकिन इसकी दो खामियां हैं: सुरक्षा (कोड इंजेक्शन, XSS) और स्केलेबिलिटी।

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

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

• सिस्टम में जोड़े गए अंतिम सर्वर में जोड़ें (फिट नहीं है, क्योंकि सर्वर जल्दी से अंतरिक्ष से बाहर चला जाता है);
• सबसे मुक्त सर्वर (फिट नहीं है, क्योंकि सभी ट्रैफ़िक सर्वर पर डंप हो जाता है);
• बेतरतीब ढंग से मुक्त सर्वर (सबसे अच्छा);

बाधाओं को खोजें और समाप्त करें। आमतौर पर टोंटी एक है - सिस्टम में बाकी नोड्स की तुलना में यह बहुत बेहतर काम करता है। बोतल गर्दन जब उपयोगकर्ता डेटा की एक बड़ी राशि का भंडारण निम्नलिखित हो सकता है:

• डेटा बैकअप (RAID का उपयोग किया जाता है यदि 2 डिस्क का पूरा सरणी जलता है - उपयोगकर्ता फ़ाइलें स्थायी रूप से खो जाती हैं);
• कैशिंग (सामग्री का 60% क्लाइंट पर कैश से आता है);
• यातायात (समाधान CDN है, विशेष रूप से वीडियो के लिए: मॉस्को में VKontakte में सर्वर हैं जो सेंट पीटर्सबर्ग में एक डेटा सेंटर से वीडियो कैश करते हैं);

उपयोग की गई फ़ाइल प्रणाली XFS है। हालाँकि, उपयोगकर्ता फ़ाइलों को फ़ाइल सिस्टम में संग्रहीत नहीं किया जाता है, लेकिन एक बड़ी फ़ाइल में। फ़ाइल हमेशा पढ़ने के लिए खुली होती है, फ़ाइल इंडेक्स रैम में संग्रहित होता है। लोग इस तकनीक के आगे के विकास को भौतिक मीडिया से पूरी तरह से अमूर्त रूप में देखते हैं।

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

तस्वीरों के बारे में क्या:

• कुल 30,000,000,000 से अधिक, 17,000,000 प्रति दिन जोड़े जाते हैं;
• छवियां ग्राहक पक्ष (फ्लैश) पर पूर्व-संपीड़ित होती हैं;
• ग्राफिक्स मैजिक का उपयोग करता है;
• जब सभी आवश्यक अनुमतियों के लिए फ़ोटो को तुरंत काट दिया जाता है;

ऑडियो के बारे में:

• 130K प्रति दिन जोड़ा जाता है;
• उपयोगकर्ताओं के पास खुद को दूसरे के पेज से डेटा को "जोड़ने" की क्षमता है, जो परिमाण के आदेशों द्वारा डाउनलोड किए गए ऑडियो की मात्रा को कम करता है;
• कॉपीराइट धारकों के अनुरोध पर, फ़ाइलों को शुरू में md5 हैश द्वारा खोजा गया था। अब एक एल्गोरिथ्म विकसित किया गया है जो कुछ ऑडियो विशेषताओं द्वारा समान ऑडियो रिकॉर्ड पाता है;

वीडियो के बारे में:

• 320K प्रति दिन जोड़ा जाता है;
• कतार के माध्यम से विलंबित वीडियो प्रसंस्करण का उपयोग किया जाता है - ऑनलाइन वीडियो संसाधित करना बहुत महंगा है;
• ffmpeg का उपयोग वीडियो प्रोसेसिंग के लिए किया जाता है;
• अन्य उपयोगकर्ताओं द्वारा पुनः लोड किए जाने पर वीडियो को डुप्लिकेट किया जाता है - यह कोई समस्या नहीं है;
• एक समय में, VKontakte में फ्लैश (वाट!) पर वीडियो के लिए पी 2 पी था, अब वे इसके बिना कर सकते हैं;

सामान्य तौर पर, मुझे यह महसूस हुआ कि संपर्क अपेक्षाकृत सरल है। सरल लेकिन प्रभावी।

एक उच्च लोड परियोजना में NoSQL

Mamba में NoSQL का उपयोग कैसे किया जाता है, इस पर रिपोर्ट करें। विचाराधीन प्रणाली की विशेषताएं यह है कि निष्पादित प्रश्नों का 30% से अधिक इंक्रीमेंट और काउंटरों की रीडिंग है।

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

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

इसलिए, लोग Google से LevelDB की दिशा में चले गए। यह डेटाबेस एलएसएम-ट्री तकनीक का उपयोग करता है। डेटा को SSTable फ़ाइलों में संग्रहीत किया जाता है: अपरिवर्तनीय कुंजी-मान जोड़े।
रैम में डेटा एक समान (लेकिन पहले से ही परिवर्तनीय) संरचना को लिखा गया है। समय-समय पर, मेमोरी से डिस्क मर्ज तक घटाता है।
अचानक बिजली आउट होने की स्थिति में समस्याओं को न पकड़ने के लिए - राइट अहेड लॉग लिखा जाता है।

लोगों ने एक बार फिर से परीक्षण किया और पाया कि ज्यादातर मामलों में LevelDB लाइब्रेरी पहले से उपयोग किए गए सभी विकल्पों को बेहतर बनाता है। अब उनके पास डेटाबेस में 4700 गेट / सेकेंड और 200M रिकॉर्ड के साथ 1600 अपडेट / सेकंड हैं।

MVCC अनमास्क किया गया

मल्टीवर्सन कॉन्सुरेंसी कंट्रोल एक ऐसा तंत्र है जो पाठकों को लिखने को अवरुद्ध करने की अनुमति नहीं देता है, बल्कि पाठकों को लिखता है। सामान्य तौर पर, यह डेटाबेस में ताले की संख्या को काफी कम कर देता है। ओरेकल, मैसूर इनोबीडी, पोस्टग्रेस् क्यूएल और कुछ अन्य लोगों में मौजूद हैं।

MVCC सिस्टम तालिकाओं में प्रत्येक प्रविष्टि के दो गुण हैं: क्रिएटन (xmin) - लेनदेन की संख्या जिसमें रिकॉर्ड बनाया गया था, समाप्ति (xmax) - लेनदेन की संख्या जिसमें रिकॉर्ड हटा दिया गया था।

     INSERT xmin 40, xmax Null
     DELETE xmin 40, xmax 47 

     अद्यतन xmin 64, xmax 78 / xmin 78, xmax NUll

जब प्रत्येक कथन निष्पादित किया जाता है, तो एक MVCC स्नैपशॉट बनाया जाता है, जो यह निर्धारित करता है कि डेटाबेस में कौन सा डेटा दिखाई दे रहा है / बयान के लिए सुलभ है।
एक स्ट्रिंग की दृश्यता निर्धारित करने के लिए एल्गोरिथ्म निम्नानुसार है:

• अंतिम पूर्ण लेनदेन (वर्तमान) की संख्या प्राप्त करें;
• हम उन रिकॉर्डों को देखने पर विचार करते हैं जिनमें:
  
  • xmin <वर्तमान संख्या;
  • वे हटाए नहीं जाते हैं (xmax = null), या जिस लेनदेन में वे हटाए जाते हैं, उसे सार्वजनिक नहीं किया जाता है;
  
  

Xmin और xmax फ़ील्ड प्रत्येक तालिका में मौजूद हैं, लेकिन डिफ़ॉल्ट रूप से छिपे हुए हैं। हालांकि, उन्हें हमेशा चयन में स्पष्ट रूप से निर्दिष्ट किया जा सकता है: चयन करें xmin, xmax, * FROM परीक्षण से ;

आप चुनिंदा क्वेरी txid_current () का उपयोग करके वर्तमान लेनदेन की आईडी प्राप्त कर सकते हैं। यह क्वेरी pg_clog तालिका से डेटा का चयन करती है। यह समझना महत्वपूर्ण है कि एक लेन-देन रोलबैक बस इस तालिका में लेनदेन रिकॉर्ड करने के लिए उचित टोकन सेट कर रहा है। उसी समय कोई डेटा डिलीट नहीं किया जाता है। एक लेन-देन को केवल लुढ़का हुआ वापस चिह्नित किया जाता है।

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

वैसे, यहाँ स्पीकर की साइट है जिस पर उसने कई दिलचस्प लेखों का वादा किया था।

Google पर MySQL

रिपोर्टों के बीच शायद सबसे बड़ी निराशा। संक्षेप में, इसका सार एक थीसिस को उबालता है: "हां, हमारे पास MySQL थोड़ा हमारे द्वारा पैच किया गया है।"
शायद मेरी अत्यधिक आवश्यकताएं हैं, लेकिन मुझे अच्छे निगम से कुछ और दिलचस्प की उम्मीद थी।

सबसे बड़ी परियोजनाएं: विज्ञापन, चेकआउट और, निश्चित रूप से, YouTube।

डेटा केंद्रों के लिए, सबसे महंगे हार्डवेयर का उपयोग नहीं किया जाता है, लेकिन सबसे "उन्नत" एक है। घटक (डिस्क) बहुत बार अनुपयोगी हो जाते हैं, लेकिन आसानी से और सस्ते रूप से प्रतिस्थापित किए जा सकते हैं।

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

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

NginX में SPDY समर्थन

SPDY एक TCP / TLS कनेक्शन पर एक बाइनरी प्रोटोकॉल है। यह HTTP के लिए एक ट्रांसपोर्ट है। Google द्वारा डिज़ाइन किया गया।

मुख्य विशेषताएं:

• मल्टीप्लेक्सिंग (प्रति कनेक्शन कई अनुरोध, सर्वर से क्लाइंट तक, और इसके विपरीत);
• हेडर कम्प्रेशन (ज़ालिब, अपस्फीति);
• प्रवाह नियंत्रण (टीसीपी कनेक्शन के लिए विंडो);
• सर्वर पुश (सर्वर द्वारा शुरू किए गए ब्राउज़र में डेटा को "लोड करना");

फायदे में: बिल्ट-इन HTTPS (TLS के कारण), बड़ी संख्या में चित्रों के साथ अच्छा काम (मल्टीप्लेक्सिंग के कारण);
मिनीसों में से: यह एक डोमेन के साथ काम करता है, परिणामस्वरूप - यह सीडीएन का समर्थन नहीं करता है;

शोध (मुकाबला) के अनुसार Wordpress'a: SPDY HTTPS से अधिक तेज़ है, लेकिन नियमित HTTP की तुलना में धीमा है।

एसक्यूएल ट्रिक्स

रिपोर्ट दिलचस्प थी, लेकिन सभी SQL / PostgreSQL सुविधाओं से परिचित नहीं थी:

• देखें तर्क और / या तालिकाओं को एनकैप्सुलेट करने का एक प्रभावी उपकरण है। मैं पहले से सहमत नहीं हूं, लेकिन मैं दूसरी (नाम बदलने वाली तालिकाओं) का उपयोग करता हूं;
• पोस्टर्स ओएस कैश का उपयोग करते हैं (इसलिए, वे या तो थोड़ा या सभी को आवंटित करने का प्रस्ताव करते हैं);
• pgbench - पोस्टग्रेज के परीक्षण के लिए एक उपयोगिता;
• सामान्य तालिका नाम (CTE) / पुनरावर्ती CTE;
• खिड़की के कार्य;
• JSON समर्थन (सी 9.2);
• पार्श्व समर्थन (FROM क्लॉज में वर्तमान लाइन पर गणना की गई डेटा का उपयोग, सी 9.3);
• पाठ और ट्रिगर्स के साथ काम करने के लिए विस्तार: pg_trgm;
• कुंजी-मूल्य जोड़े को संग्रहीत करने के लिए एक्सटेंशन: hstore;
• अन्य डेटाबेस से तालिका जोड़ने के माध्यम से dblink;
• भू-डेटा के साथ काम करने के लिए एक्सटेंशन: पोस्टजीआईएस और अर्थडिस्टेंस;
• तैयार किए गए कथन - आपको अनुरोध को पार्स करने, अस्तित्व और अधिकारों की जांच करने, एक योजना बनाने (कभी-कभी इसे लेने) से बचने की अनुमति देता है
  करने से ज्यादा समय);
• ताले का चयन निर्माण के माध्यम से स्पष्ट रूप से किया जा सकता है ... शेयर निर्माण के लिए;
• PgSQL के लिए तैयार विवरण निष्पादन के माध्यम से सुलभ हैं;
• कोड ब्लॉक $ कोड $ करते हैं ... $ कोड $ (c 9.1);
• सबसे ऊपर डालने के माध्यम से सबसे अच्छा लागू किया जाता है -> fk बाधा -> अद्यतन;
• आप फ़ंक्शन से कई मान वापस कर सकते हैं दर (लेन-देन के भीतर) या JSON (row_to_json, array_to_json) उत्पन्न करके;

वैसे, स्पीकर वास्तव में खतरनाक है: पुनरावर्ती CTE और Regexp का उपयोग करते हुए, उन्होंने Postgres में एक अनुरोध के एक सरणी के साथ JSON पार्सर लिखा!

क्राउचिंग सर्वर, छिपा हुआ डायोड

"नमस्ते, मेरा नाम एंड्री है, मैं वोरोनिश मवेशी हूं।" रिपोर्ट का यह विवरण पूरा किया जा सकता है :) सामान्य तौर पर, इसकी सभी महिमा में अक्षोनोव।

मुख्य बिंदु:

• बेंचमार्क के साथ - लक्ष्यों के बारे में याद रखने वाली मुख्य बात: आपको यह मापने की ज़रूरत है कि क्या ज़रूरत है, औसत लोड नहीं;
• मेट्रिक्स के औसत मूल्यों का मतलब कुछ भी नहीं है: अस्पताल में औसत तापमान ठंडी लाशों और ज्वर कोमा है;
• स्केलेबिलिटी नॉनलाइनर है (अमदहल का नियम - भले ही यह 5% के समानांतर न हो, तो
  64 * सीपीयू = 14.5 एक्स)
  
  C (n) = n / (1 + a * (n-1) + b * n * (n-1)), जहां
  
  एक - विवाद की डिग्री (अद्वितीय कोड की लागत),
  
  बी - सुसंगतता की डिग्री (सुसंगतता, संचार, तुल्यकालन की लागत);
• आप मीठे स्थान को उजागर कर सकते हैं - संसाधनों की मात्रा जिस पर प्रदर्शन इष्टतम होगा;
• एक मीठे स्थान के बाद, इसके विपरीत, उत्पादकता गिरना शुरू हो जाती है - यह विकास के साथ बदतर हो सकता है ;
• डिफ़ॉल्ट सेटिंग्स पर परीक्षण न करें - अधिकांश सॉफ्टवेयर के लिए, वे इसे हल्के ढंग से डालने के लिए, अजीब हैं (प्रत्येक इन्सर्ट के बाद fsync और MySQl में innodb_buffer_pool 32 एमबी है);
• 1000 बार एक ही अनुरोध चलाएं - कैश का परीक्षण करें;

विश्व स्थिरांक - यह समझना महत्वपूर्ण है कि कार्रवाई में कितना खर्च होता है।

• CPU L1 - 1,000,000,000 सेशन / सेकंड (1e9)
• CPU L2, मिसब्रांच - 100,000,000 सेशन / सेकंड (1e8)
• रैम एक्सेस - 10,000,000 से अधिक / सेकंड (1e7)
• SSD मेगाएरिड - 100,000 सेशन / सेकंड (1e5)
• एसएसडी - 10,000 सेशन / सेकंड (1e4)
• LAN, 1MB RAM - 1,000 सेपर / सेकंड (1e3)
• HDD की तलाश, 1 एमबी लैन - 100 सेपर / सेकंड (1e2)
• वैन राउंडट्रिप - 10 ऑप / सेक (1e1)
• विलंबित पहुंच - 10,000 से अधिक / सेकंड (1e4)
• आरडीबी सरल चयन - 100 से अधिक / सेकंड (1e2)

भाषा जाओ

शुरुआत और नमस्ते, वर्ल्ड इन जीओ।

दिन २

खोज कैसे काम करती है

आंद्रेई अकोयोनोव से मॉर्निंग सोबर :)
किसी भी खोज इंजन के काम में, 4 मील के पत्थर को प्रतिष्ठित किया जा सकता है: डेटा अधिग्रहण (मकड़ी रोबोट), अनुक्रमण, खोज, स्केलिंग।

अनुक्रमण में शामिल हैं:

• पाठ प्राप्त करना (html, pdf-> पाठ),
• tokenization,
• आकारिकी प्रसंस्करण (स्टेमिंग, लेमोोटाइजेशन),
• एक उलटा सूचकांक (कीवर्ड -> पुस्तक में पृष्ठ संख्या और उनमें शब्द की स्थिति) बनाना;

सूचकांक में डेटा संपीड़ित होना चाहिए। संपीड़न बिट, बाइट, ब्लॉक हो सकता है। कम डेटा - अनुरोध पर संसाधित होने की कम आवश्यकता है।

खोज में दो ऑर्थोगोनल चरणों होते हैं: जल्दी से मिलान (खोज) और गुणात्मक रूप से रेकिंग (रैंक)।
मिलान मापदंड इसके उपयोग के क्षेत्र (वेब, डेटा माइनिंग) के आधार पर भिन्न हो सकते हैं। रैंकिंग के लिए, यह, सिद्धांत रूप में, अंत तक प्रासंगिक नहीं हो सकता, क्योंकि प्रासंगिकता प्रत्येक उपयोगकर्ता के लिए व्यक्तिगत है। इसलिए, BM25 (TF, IDF, DocLength) जैसे ट्रिकी एल्गोरिदम का उपयोग रैंकिंग के लिए किया जाता है, जिसके परिणाम व्यक्तिगत रूप से यथासंभव अधिक होते हैं।

स्केलिंग के लिए, खोज के लिए संसाधनों की आवश्यकता होती है। इसलिए, Google के पास लाखों खोज सर्वर हैं, यैंडेक्स के पास हजारों हैं।

Odnoklassniki खोजें

लोग 30M उपयोगकर्ताओं के साथ पूर्ण खोज (MsSQl पर) का उपयोग करने में कामयाब रहे। 16 ठिकानों के क्लस्टर पर, एक खोज क्वेरी ने औसतन 15-30 सेकंड काम किया।
यह महसूस करते हुए कि आप उस तरह नहीं रह सकते हैं, हमने एक समाधान खोजने का फैसला किया।

जावा परियोजना के बाद से, उन्होंने ल्यूसीन की ओर देखना शुरू किया। ल्यूसिन के साथ काम करने के 3 वर्षों में निम्नलिखित परिवर्तन हुए:

• जोड़ा प्रतिकृति
• मेमोरी में अनुक्रमित का भंडारण (एक रैम ड्राइव पर कोशिश की, हीप में फाइलों को मैप करना, लेकिन अंत में बाइटएयर्रे में फाइलों को खींच लिया - ओल्डजेनरेशन में);
• अनुक्रमणिका द्वारा खोज को फिर से लिखा (डिफ़ॉल्ट रूप से कई ऑब्जेक्ट्स बनाए गए, जिससे जीसी के साथ समस्याएं पैदा हुईं);

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

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

केवल 5% अनुरोध (सबसे अधिक बार अनुरोध) लगातार कैश में हैं। 60% कैश में मारो।
व्यक्तिगत अनुरोधों के लिए, अस्थायी कैश बनाए जाते हैं (अनुरोध पर), जो कई मिनट तक रहते हैं।

पोर्टल के प्रत्येक उपयोगकर्ता को एक अलग ऐप-सर्वर सौंपा गया है (userId के आधार पर गणना की जाती है)। सर्वर की समस्या के मामले में, उपयोगकर्ता को रिज़र्व में स्थानांतरित कर दिया जाता है।

ऑनलाइन उपयोगकर्ताओं की खोज पहली बार सामान्य सूचकांक द्वारा की गई थी, जो सूचकांक के बाहर "ऑनलाइन" ध्वज को छान रहा था। फिर उन्होंने इस उद्देश्य के लिए एक अलग सूचकांक बनाया।

डेटा को हमेशा के लिए संग्रहीत करना

डिवाइस और एवरनोट संख्या के बारे में अवलोकन रिपोर्ट।

सॉफ्टवेयर: जावा 6, MySQl 5.1, डेबियन (स्थिर), DRBD (डिस्ट्रिब्यूटेड स्टोरेज सिस्टम), एक्सएन।
हार्डवेयर: सुपरमाइक्रो 1 यू, 2x एल 5630 सीओयू, 96 जीबी रैम, 6x 300 जीबी इंटेल एसएसडी, एलएसआई RAID 5 (+ स्पेयर) ~ $ 8000।

DataBase: MySQL, 10TB (पीक रीप्स 350, पीक वाइप्स 50)
खोज इंजन: ल्यूसिने (पीक रीप्स 800, पीक वाइप्स 50)

सर्वर संयुक्त राज्य अमेरिका और चीन (400 लिनक्स सर्वर) में स्थित हैं।

Apache / WebDAV के माध्यम से फाइलों तक पहुंच नियंत्रित की जाती है। डेटा हमेशा एक ही होस्ट पर संग्रहीत किया जाता है और स्थानांतरित नहीं किया जाता है। एनएफएस की तुलना में, वेबडाव में थोड़ा सा ओवरहेड होता है, लेकिन यह कई बार सरल और सस्ता होता है।

लोड संतुलन का उपयोग एसएस 10 के साथ एसएसएल आयरन बैलेंसर के साथ किया जाता है (एचटीटीपीएस बाहरी रूप से दिख रहा है, एचटीटीपी को अंदर से बंद किया जा रहा है)।

सेवा की विशेषताओं (कई छोटी फ़ाइलों का भंडारण) को ध्यान में रखते हुए, समस्याओं और उनकी आलोचना को निम्न तालिका में वर्णित किया जा सकता है:

/	आकार	सामान्य भार	शिखर भार
बैंडविड्थ	-	मध्यम	मध्यम
विलंब	-	कम	कम
cpu	-	कम	मध्यम
फ़ाइल का आकार	उच्च	कम	मध्यम
मेटा डेटा	कम	मध्यम	कम

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

DDOS यांत्रिकी

मैं इस रिपोर्ट को लगभग पूरी तरह से याद कर रहा था, जैसा कि मैं रात के खाने पर था :) अंतिम भाग से, मैं केवल कुछ जोड़े को अलग करने में कामयाब रहा।

HTTP हमलों के खिलाफ सबसे सरल सुरक्षा Nginx में सीमित क्षेत्र है। आप NGINX मॉड्यूल "testcookie" पर भी ध्यान दे सकते हैं।

हालांकि, यह समझना महत्वपूर्ण है कि Nginx DDOS हमलों का इलाज नहीं है।

रूस 2012 में DDOS हमले

कुल मिलाकर, 2012 में हुए हमले> 2600 हमले थे (पिछले साल कहीं थे> 1700)।

3,000 कारों का एक बोटनेट औसत साइट को बाढ़ने के लिए पर्याप्त है। सबसे बड़े बोटनेट में 150K मशीनें शामिल थीं। अधिकांश बोनट जर्मनी, अमेरिका, यूक्रेन, कजाकिस्तान (अवरोही) में रहते हैं।

डीडीओएस गतिविधि ई-कॉमर्स गतिविधि (अच्छी तरह से, राजनीति का एक सा) के रूप में ही है।
राजनीतिक डीडीओएस पाकिस्तान, भारत (जहां कानून लागू नहीं होता है) से बॉटनेट का उपयोग करते हैं।

अधिकांश हमले 1GB से कम ट्रैफ़िक उत्पन्न करते हैं (सामान्य साइट बैंडविड्थ अधिक नहीं है)।

हमला करते समय, सबसे पहले लॉग्स (access.log) का विश्लेषण और एक ट्रैफ़िक डला (tcpdump -s0 -c1000000 -w attack.dump) बनाना है। हमले को और अधिक बेअसर करना: जंक ट्रैफिक से हटाएं, आईपी पते को ब्लॉक करें जिससे हमला होता है, आईपी को बदलें।

आपके पास साइट प्रदर्शन का कम से कम 2x मार्जिन हमेशा होना चाहिए।

रूसी डीडीओएस की विशेषताएं - पूर्ण ब्राउज़र स्टैक (वास्तविक ब्राउज़र का उपयोग करना जो सभी एंटी-डीडोस टेस्ट पास कर सकते हैं)।

अच्छी तरह से और हाँ - यदि आप समस्याओं की उम्मीद करते हैं, तो Qrator से संपर्क करें।

2012 में स्केलिंग

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

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

सक्रिय वेब प्रदर्शन अनुकूलन

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

वर्चुअल मशीनों के लिए वितरित, स्केलेबल और अत्यधिक भारित भंडारण प्रणाली

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

वर्चुअलाइजेशन का मुख्य उद्देश्य एक मेजबान, प्रभावी बैकअप और तैनाती के संसाधनों का साझाकरण है।

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

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

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

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

एक आभासी Hadoop क्लस्टर पर सिफारिश सेवा

लोगों ने Hadoop का उपयोग करके "साइट पर सेवा की सिफारिशों" को एक नक्शा / कम किया। उनकी विशेष समस्याओं और समाधानों को एक उदाहरण के रूप में दिया जाता है, इसलिए यहां लिखना संभव नहीं है।

MariaDB: नया MySQL

मारिया डीबी के बारे में अवलोकन रिपोर्ट। MySQL के संस्थापक ने MySQL के संस्थापक द्वारा स्क्रैच से पूरी तरह से फिर से लिखा गया था, क्योंकि MySQL सन से ओरेकल में चला गया था।
एक इंजन के रूप में, यह डिफ़ॉल्ट रूप से पेरकोना के एक्स्ट्राबीडी का उपयोग करता है। InnoDB का समर्थन करता है।

संक्षेप में, रिपोर्ट Chanhelog MariaDB संस्करण 5.5 तक उबलती है।

MySQL कैसे बढ़ी और यात्रा पर मुझे मिली चुनौतियों की व्यक्तिगत कहानी

ओरेकल से रिपोर्ट। मूल रूप से नए संस्करणों में क्या होगा। एक प्रकार का रोडमैप MySQl।

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

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

सही इंडेक्स कैसे चुनें

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

मेरी राय में निम्नलिखित बिंदु सबसे बड़े हैं:

• बहुत अधिक अनुक्रमित न करें, क्योंकि वे सम्मिलन की गति को कम करते हैं और आम तौर पर ओवरहेड में प्रवेश करते हैं - अनुक्रमित केवल वहीं करते हैं जहां उन्हें वास्तव में
  ज़रूरत होती है;
• केवल उस डेटा का चयन करें जिसकी आपको आवश्यकता है: कम डेटा नेटवर्क पर प्रसारित किया जाता है, कम डेटा प्रोसेसर द्वारा संसाधित किया जाता है;
• छँटाई काफी महंगा ऑपरेशन है;
• अलग - एक बहुत ही धीमी गति से संचालन, क्योंकि यह नमूने के परिणाम पर काम करता है;
• index (a, b) index से बेहतर (a) केवल बराबर संचालन पर;
• क्लस्टरिंग इंडेक्स में सभी पंक्ति डेटा होते हैं (स्पष्ट रूप से यह निहित था कि जब एक क्लस्टर इंडेक्स का निर्माण किया जाता है, तो तालिका में डेटा को इंडेक्स के अनुसार क्रमबद्ध किया जाता है);
• यदि स्तंभ अनुक्रमणिका में नहीं है, लेकिन इसका उपयोग चयन में किया जाता है, तो आपको तालिका से प्राप्त करना होगा;

प्रस्तुतियों

सभी प्रस्तुतियाँ SlideShare पर उपलब्ध हैं ।

पुनश्च

मैं चित्रों के बिना पोस्ट छोड़ दूंगा, क्योंकि कीव स्टेशन के पास MUMU कैफे में वाईफ़ाई स्थानीय ओलिवोन से बेहतर नहीं है ...