तालिकाओं में Google ऐप इंजन डेटा के साथ काम करने की गति और लागत

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

ये गणना उन लोगों के लिए समय बचाएगी जो अपनी परियोजना की मेजबानी के लिए एक मंच की तलाश कर रहे हैं, लेकिन यह सुनिश्चित नहीं है कि Google ऐप इंजन इसके लिए उपयुक्त है या नहीं। इसके अलावा, इन तालिकाओं को मोटे तौर पर उन्मुख करने के लिए "चीट शीट" के रूप में इस्तेमाल किया जा सकता है, अनुरोध प्रसंस्करण में कितना समय लगेगा और इसे अनुकूलित करने के लिए सबसे अच्छा कैसे होगा।





इस लेख को पढ़ते समय, याद रखें कि Google ऐप इंजन वास्तव में स्वचालित रूप से स्केलेबल है। लेखों में से एक ने मुझे गुमराह किया और मुझे पहले ही इस पर संदेह होने लगा। व्यवहार में जाँच:



अक्सर अनुरोधों के साथ, यहां तक ​​कि एक आईपी पते से, जीएई स्वचालित रूप से नए उदाहरण उठाता है और उनके बीच लोड को समान रूप से वितरित करता है। ऊपर दिए गए आंकड़े में, 8 उदाहरण जोड़े जाते हैं और यह सीमा से बहुत दूर है।

लेख में दिए गए सभी माप एक उदाहरण के लिए प्रासंगिक हैं। जैसे ही साइट पर लोड बढ़ता है, क्वेरी निष्पादन की कुल गति बढ़ जाएगी (नए उदाहरणों के स्वत: जोड़ के कारण), लेकिन एक अनुरोध के निष्पादन की गति नहीं बदलेगी (अधिक सटीक होने के लिए, यह 30% के भीतर घट जाएगी)।

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

टेस्ट 1: Google BigTable Data Warehouse में लिखना

इस मान से रिकॉर्डिंग:

प्रभाव	सीपीयू समय	वास्तविक समय
डेटाबेस में 1 प्रविष्टि	90 मि	40 मि
बदले में 10 प्रविष्टियां	750 मि	250 मि
बदले में 100 प्रविष्टियां	7250 एमएस	2100 मि
बदले में 1000 प्रविष्टियाँ	71000 मि	28000 मि

बैच रिकॉर्ड:

प्रभाव	सीपीयू समय	वास्तविक समय
एक अनुरोध में 10 रिकॉर्ड	670 मि	60 मि
एक अनुरोध में 100 रिकॉर्ड	6600 मि	370 मि
एक अनुरोध में 1000 रिकॉर्ड	65000 मि	2500 मि

जैसा कि आप देख सकते हैं, बैच रिकॉर्डिंग की लागत एकल मूल्य पर रिकॉर्डिंग की लागत से थोड़ी कम है। लेकिन पैकेट लेखन के निष्पादन की गति 10 गुना अधिक है ।

रिकॉर्डिंग लागत:

लगभग 10 प्रोसेसर सेकंड 10 रिकॉर्ड लेते हैं (थोड़ा तेज, हम एक मार्जिन के साथ लेते हैं):

योग	मैं कितने रिकॉर्ड खरीद सकता हूं
1 प्रतिशत	3600 प्रविष्टियाँ
1 डॉलर	360 हजार रिकॉर्ड

अनुरोध के अनुसार अधिकतम रिकॉर्ड

प्रभाव	आरामदायक अधिकतम *	तकनीकी अधिकतम
वैकल्पिक रिकॉर्डिंग	20	1 हजार
बैच रिकॉर्ड	200	10 हजार

तुलना के लिए: अमेज़ॅन EC2 माइक्रो पर SQL सर्वर एक्सप्रेस R2: 1 सेकंड 500 रिकॉर्ड।

* 0.5 सेकंड से अधिक का अनुरोध असुविधा का कारण बनता है। जब भी संभव हो, किसी को तालिका में संकेतित की तुलना में अधिक प्रविष्टियां नहीं करनी चाहिए (इसके अलावा, अन्य संचालन को ध्यान में रखना चाहिए)।

टेस्ट 2. Google बिगटेबल स्टोरेज से डेटा पढ़ना और पेज पर प्रदर्शित करना

इस मान से पढ़ना:

प्रभाव	सीपीयू समय	वास्तविक समय
1 पठन	३१ मि	20 मि
बदले में 10 रीडिंग	160 मि	100 मि
बदले में 100 रीडिंग	1600 मि	750 मि
बदले में 1000 रीडिंग	12000 मि	8500 मि

बैच पढ़ना (शर्त द्वारा चयन> && <)

प्रभाव	सीपीयू समय	वास्तविक समय
एक अनुरोध में 10 रिकॉर्ड	100 मि	25 मि
एक अनुरोध में 100 रिकॉर्ड	1000 मि	80 मि
एक अनुरोध में 1000 रिकॉर्ड	9600 मि	400 मि

लेखन के समान: सीपीयू समय लगभग समान ही खर्च होता है: बैच रीडिंग और सिंगल दोनों में। लेकिन वास्तविक समय बैच पढ़ने में 10 गुना कम लगता है।

पढ़ने की लागत:

रिकॉर्डिंग की तुलना में लगभग 6 गुना सस्ता है। 1 प्रोसेसर दूसरा - 60 रीडिंग:

योग	मैं कितनी बार पढ़ सकता हूं
1 प्रतिशत	21 हजार रीडिंग
1 डॉलर	2 मिलियन रीडिंग

अधिकतम प्रति अनुरोध 1 पढ़ता है

प्रभाव	आरामदायक अधिकतम *	तकनीकी अधिकतम
अनुक्रमिक पढ़ना	60	3 हजार
बैच पढ़ने	1100	50 हजार

* 0.5 सेकंड से अधिक का अनुरोध असुविधा का कारण बनता है। जब भी संभव हो, आपको तालिका में संकेतित की तुलना में अनुरोध के अनुसार अधिक रीडिंग नहीं करना चाहिए (इसके अलावा, अन्य संचालन को ध्यान में रखना चाहिए)।

टेस्ट 3. मेमकेच में डेटा स्टोरेज

लिखना और पढ़ना लगभग एक ही समय में किया जाता है (पढ़ना थोड़ा तेज है, लेकिन सादगी के लिए हम राउंड ऑफ होते हैं)।

संचालन की संख्या	सीपीयू / वास्तविक समय
1	23 सीपीयू / 11 एमएस
10	94 सीपीयू / 50 एमएस
100	300 सीपीयू / 300 एमएस
1000	3000 सीपीयू / 3000 एमएस

Memcache लागत

डेटाबेस से पढ़ने की तुलना में लगभग 3 गुना सस्ता और डेटाबेस से लिखने की तुलना में 15 गुना सस्ता है।

योग	मैं कितने ऑपरेशन खरीद सकता हूं
1 प्रतिशत	60 हजार पढ़ने / लिखने के संचालन
1 डॉलर	6 मिलियन पढ़ने / लिखने के संचालन

अधिकतम अनुरोध प्रति संचालन

प्रभाव	आरामदायक अधिकतम *	तकनीकी अधिकतम
पढ़ें / लिखें	150	9 हजार

* 0.5 सेकंड से अधिक का अनुरोध असुविधा का कारण बनता है। जब भी संभव हो, आपको मेज पर इंगित की तुलना में एक ही अनुरोध में मेमकेच के साथ अधिक संचालन नहीं करना चाहिए (इसके अलावा, अन्य संचालन को ध्यान में रखना चाहिए)।

परीक्षण 4. स्केलिंग

यह सब एक चिंता और एक अनुरोध के ऊपर लिखा गया है। सभी अनुरोधों की कुल निष्पादन गति काफी अधिक हो सकती है।

व्यावहारिक रूप से इस तरह के एक प्रयोग का आयोजन किया। एक एप्लिकेशन बनाया गया था जो एक डेटाबेस में 5 रिकॉर्ड और प्रति पृष्ठ सूचना आउटपुट के साथ 100 रीडिंग (गतिशील डेटा आकार 500 वर्ण * 100 = 50 Kb UTF-8) करता है। सीपीयू समय खपत: 1300 एमएस प्रति अनुरोध।

इस एप्लिकेशन को कई धाराओं (100 Mbit के चैनल के साथ सर्वर-बॉम्बर) में अनुरोधों द्वारा बमबारी की गई थी। बम विस्फोट के परिणाम:

धागों की संख्या	1 निवेदन समय
1	100 मि
10	150 मि

तो, लोड में 10 गुना वृद्धि के साथ, कुल क्वेरी प्रसंस्करण गति में लगभग 7 गुना (लगभग 150 एमएस 1 अनुरोध, केवल 10 * 7 = 70 अनुरोध प्रति सेकंड) की वृद्धि हुई।

प्रयोग के परिणामस्वरूप, 16 हजार प्रश्नों को 3 मिनट (10 उदाहरण, 1600 प्रश्न प्रत्येक) में पूरा किया गया और 800 एमबी यातायात खर्च किए गए।

निष्कर्ष

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

तस्वीर के बारे में अद्यतन करें

मैं देखता हूं, टिप्पणियों में लेख में चित्र के बारे में Google के प्रति निंदा शुरू हुई, यह कहते हुए कि GAE तथाकथित नहीं खड़ा हो सकता "Habraeffekt"। यह सब असत्य है।

यह तस्वीर अस्थायी रूप से (लगभग 1 बजे से 7 बजे तक) गायब हो गई क्योंकि मुफ्त सीमा समाप्त हो गई थी। 16 घंटे का समय जोड़ा, मुझे लगता है कि यह पर्याप्त है। मैंने ध्यान दिया कि इससे पहले कि मैंने हाबेरा पर काउंटर रखा था, पहले से ही प्रयोगों पर मुफ्त सीमा का 30% खर्च किया गया था। शेष 70% काउंटर के 20 हजार हिट्स के लिए पर्याप्त था (खाते में इसकी सुस्ती - इतना कम नहीं)।

वैसे, यह सिर्फ एक तस्वीर नहीं बल्कि एक काउंटर है । गणना परिणामों के साथ एक चित्र प्रत्येक अनुरोध के लिए org.toyz.litetext लाइब्रेरी का उपयोग करके प्रोग्रामेटिक रूप से बनाया गया है (कैशिंग अक्षम है)। चूंकि org.toyz.litetext पुस्तकालय बहुत धीमा है (मैंने इसे नहीं लिखा था) - प्रत्येक अनुरोध में 500 एमएस प्रोसेसर समय की खपत होती है। इसके अलावा, प्रत्येक डिस्प्ले की जानकारी डेटाबेस में दर्ज की जाती है।

अब (मॉस्को में लगभग 9 घंटे) प्रति मिनट 200 विचार (हर कोई काउंटर देखता है और इसे अपने दम पर गिन सकता है)। जीएई 13-15 अधिकारियों को चालू रखता है (अब 13, 15 थे)। लोड अभी भी बढ़ रहा है। कितने उदाहरण अपने चरम पर होंगे - मैं बाद में सदस्यता समाप्त करूंगा। विस्तार से (रेखांकन के साथ) मैंने एक नए लेख में लिखा: habrahabr.ru/blogs/gae/115731