Google App Engine Data Storage

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



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

डेटा वेयरहाउस (डेटास्टोर)

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

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

मेम्कैश

मेम्चे को "माध्यमिक" डेटा स्टोरेज के एक तंत्र के रूप में जाना जाता है। Memcache एपीआई महंगा ऑपरेशन से बचने के लिए डेटा को आशावादी रूप से कैश करने में सक्षम बनाता है। Memcache को अक्सर अन्य APIs के लिए कैश स्तर के रूप में उपयोग किया जाता है, जैसे डेटास्टोर या किसी भी गणना के परिणामों को कैशिंग करने के लिए।

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

उदाहरण स्मृति

एप्लिकेशन इंस्टेंस भी वैश्विक चर या वर्ग के सदस्यों का उपयोग करके डेटा को कैश कर सकते हैं। यह विधि उच्चतम गति प्रदान करती है, लेकिन इसके कुछ नुकसान भी हैं।

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

Blobstore

BLOB संग्रहण उपयोगकर्ता द्वारा अपलोड की गई बड़ी मात्रा में डेटा को संग्रहीत और स्थानांतरित करना आसान और कुशल बनाता है।

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

स्थानीय फाइलें

एप्लिकेशन एप्लीकेशन के साथ डाउनलोड की गई किसी भी फाइल को पढ़ सकता है और मानक फाइल सिस्टम ऑपरेशन का उपयोग करके स्थिर सामग्री के रूप में चिह्नित नहीं किया जाता है। इससे रीड-ओनली डेटा जुड़ता है जिसे एप्लिकेशन की आवश्यकता हो सकती है।

• लाभ:
  • फास्ट - स्थानीय फ़ाइलों को पढ़ने में मशीन पर केवल मानक डिस्क संचालन शामिल होता है, जिस पर एप्लिकेशन इंस्टेंस चल रहा है, इसलिए गति लगभग मेमेचे के समान है।
  • विश्वसनीय - यदि एप्लिकेशन काम करता है, तो स्थानीय फाइलें हमेशा उपलब्ध होती हैं।
  • लचीले - आप स्थानीय फ़ाइलों तक पहुँचने के लिए किसी भी प्रारूप या तंत्र का उपयोग कर सकते हैं।
• नुकसान:
  • केवल पढ़ें - एप्लिकेशन फ़ाइलों को संशोधित नहीं कर सकते हैं।
  • सीमित आकार - प्रतिबंध प्रति फ़ाइल 10MB और प्रति एप्लिकेशन 150MB हैं।
• कैसे और कहाँ उपयोग करें:
  
  
  
  एप्लिकेशन सेटिंग्स, टेम्प्लेट आदि का संग्रहण।
  
  
  
  
• जहां उपयोग न करना बेहतर हो:
  
  
  
  कोई मतभेद नहीं नोट किया
  
  

टास्क कतार पेलोड

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

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

ई-मेल

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

• लाभ:
  • लचीले - आप मेल कोटा को प्रभावित किए बिना "नियमित" मेल भेजकर या "व्यवस्थापक" मेल भेजकर बड़ी मात्रा में भेज सकते हैं।
  • सुविधाजनक - एक डेटा पत्र एक POST अनुरोध के रूप में आता है, प्रसंस्करण की सुविधा के लिए जो एक मानक InboundMailHandler है।
  • अनुप्रयोगों के बीच डेटा का आदान-प्रदान करने की क्षमता।
• नुकसान:
  • स्पैम - अप्रयुक्त पत्र आवेदन पते पर आ सकते हैं, आने वाले डेटा का अतिरिक्त सत्यापन आवश्यक है।
  • भेजते समय, आपको डेटा की मात्रा के आधार पर विभिन्न तरीकों का उपयोग करने की आवश्यकता होती है - व्यवस्थापक 16Kb से अधिक पत्र नहीं भेज सकते हैं, और नियमित पत्र भेजना अपेक्षाकृत महंगा है।
  • "व्यवस्थापक" मेल के साथ पूर्ण काम के लिए, बिलिंग को शामिल करना वांछनीय है। सक्षम बिलिंग के साथ एक आवेदन प्रति दिन 3,492,979 पत्र प्रशासक भेज सकते हैं, जबकि एक विकलांग 5,000 के साथ।
  • एक व्यवस्थापक के रूप में आवेदन पते को जोड़ने की एक गैर-तुच्छ प्रक्रिया - इस पते पर एक Google खाता बनाने के लिए एक अस्थायी हैंडलर की आवश्यकता होती है और इसे प्रशासकों की सूची में शामिल करता है।
• कैसे और कहाँ उपयोग करें:
  
  
  
  अनुप्रयोगों के बीच छोटी मात्रा में डेटा (16Kb तक) स्थानांतरित करना।
  
  
  
  
• जहां उपयोग न करना बेहतर है:
  
  
  
  बड़ी मात्रा में डेटा का बार-बार हस्तांतरण जल्दी से एक मेल कोटा का उपयोग करेगा - URLFetch इन उद्देश्यों के लिए अधिक उपयुक्त है।
  
  

URLFetch

URL पुनर्प्राप्ति API आपको HTTP और HTTPS अनुरोधों का उपयोग करके अन्य होस्ट से जानकारी प्राप्त करने की अनुमति देता है।

• लाभ:
  • अन्य एप्लिकेशन / सर्वर से डेटा प्राप्त करने की क्षमता।
  • अतुल्यकालिक - प्रतीक्षा करते समय अतुल्यकालिक रूप से डेटा प्राप्त करते समय, आप अन्य गणना कर सकते हैं।
  • आकार - आवेदन एक अनुरोध में 32 एमबी तक प्राप्त कर सकता है, हालांकि, इस एपीआई के माध्यम से भेजना 1 एमबी से अधिक नहीं हो सकता है।
• नुकसान:
  • गति दूसरे होस्ट की गति पर निर्भर करती है।
  • ट्रैफ़िक - URLFetch सेवा और उपयोगकर्ताओं के लिए, एकल ट्रैफ़िक कोटा। URLFetch के अत्यधिक उपयोग से उपयोगकर्ताओं के लिए सेवा अस्वीकार हो सकती है।
• कैसे और कहाँ उपयोग करें:
  
  
  
  पृष्ठभूमि डाउनलोड और डेटा प्रोसेसिंग, जैसे कि आरएसएस। तृतीय-पक्ष अनुप्रयोगों के साथ सहभागिता, उदाहरण के लिए reCaptcha के साथ।
  
  
  
  
• जहां उपयोग न करना बेहतर है:
  
  
  
  उपयोगकर्ता के लिए डेटा प्राप्त करना जब तेज तरीकों को लागू करना संभव है।
  
  

आवेदन लॉग

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

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

निष्कर्ष

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