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

सृष्टि का इतिहास

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

इन आँकड़ों के कुछ स्क्रीनशॉट हमारे ब्लॉग पर भी दिखाई दिए ।

हम इसे ग्राहकों के लिए प्रकाशित करने के लिए लगभग तैयार थे, जब, अचानक, एक दुर्भाग्यपूर्ण तथ्य सामने आया था: शाब्दिक रूप से कई सौ मशीनों के साथ, 8-कोर एक्सोन यह सब गिनने के लिए पर्याप्त नहीं है।

कारण था भोला गणित। प्रत्येक वर्चुअल मशीन के आँकड़ों के स्रोत:

• प्रोसेसर
• स्मृति
• डिस्क संचालन: 2 पीसी। (पढ़ें / लिखें)
• पढ़ने / लिखित डेटा की मात्रा: 2 पीसी।
• डिस्क स्थान
• नेटवर्क: 2 पीसी।

कुल, प्रति कार 9 काउंटर। यदि प्रत्येक मशीन के लिए हम एक भोले तरीके से आंकड़े (5 रीलों) के बारे में सोचते हैं, तो यह 5 * 9 = 45 लेनदेन प्रति सेकंड प्रति मशीन है। एक सौ मशीनें ... हां, प्रति सौ में केवल 4,500 लेनदेन। यह अन्य सभी कार्यों (उदाहरण के लिए, संसाधन की खपत के लिए लेखांकन), बिजली प्रबंधन आदि की गिनती नहीं कर रहा है।

तीसरी सौ कारों पर, हमें अपने "भोले" आंकड़ों को बंद करना पड़ा और सोचना चाहिए कि यह कैसे सही है ...

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

आरआरडी के बारे में थोड़ा सा

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

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

शेक

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

समस्या हल करना

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

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

मैंने इस समाधान की गति के बारे में पहले से ही लिखा था, लेकिन गति के अलावा, इस दृष्टिकोण ने एक और समस्या हल कर दी - हमारे पास घबराना नहीं है (वास्तव में, यह मौजूद है क्योंकि बकेट को लिखने की गति को निर्धारित करने की अशुद्धि के कारण और पूर्णांकों के लिए गोल त्रुटियां हैं, लेकिन यह 0.1 से है 0.5% तक, जो कि ग्राफ के सामान्य आकार पर लाइन की मोटाई से कम है, जबकि भोले 'rrd-like' डेटाबेस पर 1-5% है।

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

भंडारण

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

प्रदर्शन

हमारी परंपरा के बाद, हमने HTML / JS के माध्यम से सब कुछ करने की कोशिश की - ग्राफिक्स को SVG में JS द्वारा सीधे तैयार किया गया है, बिना सर्वर की तरफ से PNG को प्रारंभिक प्रतिपादन। इसके लिए हम gRaphaël लाइब्रेरी ( http://g.raphaeljs.com/ ) का उपयोग करते हैं।

ज्ञात मुद्दे

जो ग्राहक बार-बार प्लग इन और अनप्लग ड्राइव करते हैं वे पाते हैं कि ड्राइव के प्रत्येक पुन: संयोजन के साथ I / O संचालन के सभी आँकड़े खो गए हैं। वास्तव में, यह खो नहीं है, बस वर्चुअल मशीन और डिस्क के बीच कनेक्शन हर बार नया है - और, इसलिए, डेटाबेस में नई पाइपलाइन।

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

इसी कारण से, हमारे पास पिछले महीने के आंकड़ों में कुछ गलतियाँ हो सकती हैं - हमने कुछ बिंदुओं को "जीवित" डिबग किया।

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

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

उपभोग प्रदर्शन

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