हाईलाड ++ 2011 सम्मेलन की मुख्य बातें

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

क्लाउड-आधारित वेब सेवा "एक वयस्क तरीके से" / सर्गेई रेज़िकोव (1C-Bitrix) डिज़ाइन करना

1 सी में रूस, अमेरिका और यूरोप में स्थित तीन डाटा सेंटर हैं। डेटा सेंटरों के बीच संचार के नुकसान में घंटों लग सकते हैं। अतुल्यकालिक मास्टर प्रतिकृति डेटाबेस सर्वरों के बीच कॉन्फ़िगर की गई है।
सभी आर्किटेक्चर Amazon Web Services से बनाया गया है।
स्थिर सामग्री के लिए, अमेज़न S3 का उपयोग किया जाता है। अन्य बातों के अलावा, लाभ ईबीएस की तुलना में इस तरह के समाधान की कम कीमत है।
इलास्टिक क्लाउड बैलेंसिंग, क्लाउडवेच और ऑटो स्केलिंग द्वारा उपयोग किया जाता है।
DB2 के साथ कारें - EC2 पर। प्रत्येक 17.1Gb रैम के साथ। सॉफ्टवेयर RAID सरणियों को ईबीएस डिस्क से बनाया गया है। RAID-10 को सबसे तेज़ और सबसे विश्वसनीय के रूप में चुना गया है।
InnoDB द्वारा उपयोग किया जाता है।
ईसीएस एफएस फ्रीज़ का उपयोग करके ईसी 2 में स्नैपशॉट्स का उपयोग करके बैकअप किया जाता है।
अमेज़ॅन आरबीएस का उपयोग निम्नलिखित कारणों से नहीं किया जाता है:

• डेटाबेस में कोई पूर्ण रूट नहीं है
• पारदर्शी नहीं है
• लंबी अवधि के जोखिम

Odnoklassniki बाइनरी डेटा वेयरहाउस आर्किटेक्चर / अलेक्जेंडर ख्रीस्तोफोरोव, ओलेग अनास्तासिव (Odnoklassniki)

प्रारंभ में वन-डीबी के उपयोग की संभावना का मूल्यांकन किया गया था। निम्नलिखित प्रतिबंध थे:

• खराब प्रदर्शन
• लंबे बैकअप (17 घंटे तक)

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

• उपलब्ध सर्वर और उनके पते
• स्थानों और स्थितियों को चलाएं
• रूटिंग टेबल
• वितरित ताला

इस प्रणाली को 24 सर्वरों पर तैनात किया गया है: 20 - भंडारण, 2 - लॉग, 2 - बैकअप।

आपको MongoDB / Sergey Tulentsev का उपयोग क्यों नहीं करना चाहिए

रिपोर्ट के मुख्य बिंदु:

• नक्शा / धीमा और एकल पिरोया कम करें
• मानचित्र में प्रत्येक ऑपरेशन / रीड या राइट लॉक को कम करता है
• मेमोरी मैप्ड फाइल्स प्रॉब्लम - सिस्टम में खराब मेमोरी मैनेजमेंट
• बहुत सुविधाजनक नहीं है जब सभी शार्क समान हैं। अंतर्निहित ऑटो साझाकरण खराब तरीके से कॉन्फ़िगर किया गया है

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

RuNet में पहली बार: प्रति दिन 100M पत्रों की कहानी / एंड्री सास (सगाई)

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

व्यंजनों की एक बड़ी पुस्तक या जटिल प्रणालियों के प्रबंधन पर अक्सर पूछे जाने वाले प्रश्न / अलेक्जेंडर टिटोव, इगोर कुरोच्किन (स्काइप)

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

बड़े पैमाने पर डेटा संग्रह अनुप्रयोगों / जोश बर्कस को डिजाइन करना

फॉल्स के बारे में आंकड़े एकत्र करने के लिए मोज़िला सोकोरो परियोजना का उपयोग करने की सिफारिश की गई है। जानकारी संग्रहीत करने के लिए, hbase का उपयोग सबसे स्केलेबल समाधान के रूप में किया जाता है। उसी समय, डेटा खुद hbase (30 टीबी पर 40 टीबी) में संग्रहीत किया जाता है। मेटाडेटा (500 GB) के संग्रहण के लिए 2 PostgreSQL सर्वर जिम्मेदार हैं। 6 सर्वर लोड संतुलन में लगे हुए हैं।
विन्यास प्रबंधन के लिए एक उपकरण के रूप में - कठपुतली।

12 रेडिस मामलों का उपयोग करते हैं - टारनटूल / अलेक्जेंडर कालेंद्रेव, कोन्स्टेंटिन ओसिपोव (Mail.ru) में

टारनटूल - सबसे डेटा संग्रहीत करने के लिए NoSQL DBMS। टारेंटूल रैम में सभी डेटा संग्रहीत करता है और डिस्क में सभी परिवर्तनों को लॉग करता है, इस प्रकार विफलता की स्थिति में डेटा विश्वसनीयता की गारंटी देता है। मेमोरी में डेटा संग्रहीत करने से आप पारंपरिक आधुनिक उपकरणों पर अधिकतम प्रदर्शन - 200-300k प्रति सेकंड के साथ क्वेरी कर सकते हैं।
टैरंटूल प्रॉक्सी और शार्क के आधार पर स्केलिंग प्रस्तावित है।
जल्द ही टारनटूल भी निम्नलिखित सुविधाएँ प्राप्त करेगा:

• लेन-देन का समर्थन
• गुरु प्रतिकृति गुरु
• क्लस्टर प्रबंधक
• बैलेंसर लोड करें

इस प्रकार, mail.ru प्रतिनिधियों ने रेडिस के प्रतिस्थापन के रूप में टारनटूल की बात की। उत्पादकता में कमी ~ 5% से।

जावा / एलेक्सी रागज़िन में कचरा संग्रह का रहस्य

मेमोरी में लिंक गिनना सबसे अच्छा टूल नहीं है। यह आपको चक्रीय रेखांकन से नहीं बचाता है, यह मल्टीथ्रेडिंग के साथ अच्छी तरह से काम नहीं करता है। यह CPU लोड का 15-30% भी है।
जेनेटिक परिकल्पना के अनुसार, अधिकांश वस्तुएं युवा मर जाती हैं। जब तक वे होते हैं, उन्हें कम संख्या में अन्य वस्तुओं द्वारा संदर्भित किया जाता है। इस प्रकार, "युवा" और "पुरानी" वस्तुओं के भंडारण को अलग करके, हम बढ़ी हुई उत्पादकता प्राप्त कर सकते हैं।
जेवीएम जैसे हॉटस्पॉट के लिए, कई चाबियाँ हैं। कुंजी का उपयोग करने की संभावना पर जानकारी एलेक्सी के ब्लॉग में निहित है।
यह अनुशंसा की जाती है कि आप संवेदनशील कचरा संग्रह अनुप्रयोगों को रोकने के लिए समवर्ती मार्क स्वीप जीसी का उपयोग करें। विशेष रूप से शामिल: -XX: + ExplicitGCInvokesConcurrent
CMS अक्सर अनुप्रयोग संचालन के दौरान कचरा इकट्ठा करता है: "नई" पीढ़ी की वस्तुओं को स्टॉप-द-वर्ल्ड मोड (एक काफी त्वरित संचालन) में एकत्र किया जाता है, जबकि "पुरानी" पीढ़ी समानांतर और लंबे समय से एकत्र की जाती है। तदनुसार, आवेदन को पीढ़ी की परिकल्पना की शर्तों को पूरा करना होगा।
नतीजतन, 32 जीबी के ढेर के लिए ठहराव 150 एमएस से अधिक नहीं पहुंच सकता है।
एक विकल्प के रूप में, ऑफ-हीप मेमोरी का उपयोग करें। लेकिन यह पहले से ही अधिक कठिन कार्य है।

अपाचे कैसेंड्रा - एक और नोएसक्यू स्टोरेज / व्लादिमीर क्लिमोंटोविच

अपाचे कैसेंड्रा = अमेज़ॅन डायनामो + Google बिगटेबल।
टोकन रिंग टोपोलॉजी पर आधारित डेटा विभाजन की तकनीक का उपयोग किया जाता है। प्रतिकृति भी इसी टोपोलॉजी पर आधारित है। इसमें कैसांद्रा अमेजन डायनमो के समान है।
कुंजी / मान डेटा मॉडल Bigtable से लिया गया है। जटिल प्रश्न उपलब्ध हैं, अनुक्रमित (एक बेकार चीज)।
LIFO अनुरोध कैशिंग तंत्र।
स्केल करने का सबसे आसान तरीका 2 बार है। तब विभाजन खंडों की सीमाएं केवल 2 से विभाजित होती हैं।
थ्रोट प्रोटोकॉल के आधार पर नोड्स एक दूसरे के साथ संवाद करते हैं।

AJAX लेआउट / ओलेग इलारियनोव (वीके)

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

नंगेक्स और ओपनस्टैक स्विफ्ट / स्टैनिस्लाव बोग्यात्रेव, निकोले दवास (क्लोडो) के एकीकरण के आधार पर स्थिर सामग्री के भंडारण और वितरण के लिए एक क्लाउड स्टोरेज का निर्माण करना।

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

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

पीपीएस ओलेग ब्यून और ओन्टिको के प्रतिनिधियों के लिए हाईलोअड ++ के आयोजन के लिए धन्यवाद, हम 2012 में अगले सम्मेलन के लिए तत्पर हैं!