इस दस्तावेज़ को पढ़ें. इसमें, सर्वरलेस ऐप्लिकेशन को हर सेकंड में हज़ारों से ज़्यादा कार्रवाइयां करने या एक साथ लाखों उपयोगकर्ताओं के लिए स्केल करने के बारे में दिशा-निर्देश दिए गए हैं. इस दस्तावेज़ में, सिस्टम को गहराई से समझने में आपकी मदद करने के लिए, कुछ ऐडवांस विषयों के बारे में बताया गया है. अगर आपने अभी Cloud Firestore का इस्तेमाल शुरू किया है, तो क्विकस्टार्ट गाइड देखें.
Cloud Firestore और Firebase के मोबाइल/वेब SDK टूल, सर्वरलेस ऐप्लिकेशन डेवलप करने के लिए एक बेहतरीन मॉडल उपलब्ध कराते हैं. इनमें क्लाइंट-साइड कोड, सीधे तौर पर डेटाबेस को ऐक्सेस करता है. एसडीके की मदद से क्लाइंट, डेटा में होने वाले अपडेट को रीयल टाइम में सुन सकते हैं. सर्वर इंफ़्रास्ट्रक्चर की ज़रूरत न होने वाले रिस्पॉन्सिव ऐप्लिकेशन बनाने के लिए, रीयल-टाइम अपडेट का इस्तेमाल किया जा सकता है. हालांकि, किसी ऐप्लिकेशन को शुरू करना बहुत आसान है, लेकिन Cloud Firestore को बनाने वाले सिस्टम की सीमाओं को समझना ज़रूरी है. इससे, ट्रैफ़िक बढ़ने पर आपका सर्वरलेस ऐप्लिकेशन अच्छी तरह से काम कर पाता है और उसकी परफ़ॉर्मेंस बेहतर होती है.
अपने ऐप्लिकेशन को स्केल करने के बारे में सलाह पाने के लिए, यहां दिए गए सेक्शन देखें.
अपने उपयोगकर्ताओं के आस-पास के इलाके में डेटाबेस की जगह चुनना
इस डायग्राम में, रीयल-टाइम ऐप्लिकेशन के आर्किटेक्चर के बारे में बताया गया है:
जब किसी उपयोगकर्ता के डिवाइस (मोबाइल या वेब) पर चल रहा कोई ऐप्लिकेशन, Cloud Firestore से कनेक्ट होता है, तो कनेक्शन को उसी क्षेत्र में मौजूद Cloud Firestore के फ़्रंटएंड सर्वर पर भेजा जाता है जहां आपका डेटाबेस मौजूद है. उदाहरण के लिए, अगर आपका डेटाबेस us-east1 में है, तो कनेक्शन भी Cloud Firestore के फ़्रंटएंड में जाएगा. यह भी us-east1 में होगा. ये कनेक्शन लंबे समय तक बने रहते हैं और तब तक खुले रहते हैं, जब तक ऐप्लिकेशन इन्हें बंद नहीं कर देता. फ़्रंटएंड, Cloud Firestore स्टोरेज सिस्टम से डेटा पढ़ता है.
उपयोगकर्ता की मौजूदा जगह और Cloud Firestoreडेटाबेस की जगह के बीच की दूरी से, उपयोगकर्ता को मिलने वाली लेटेन्सी पर असर पड़ता है. उदाहरण के लिए, भारत में रहने वाले किसी उपयोगकर्ता के ऐप्लिकेशन का डेटाबेस, अगर नॉर्थ अमेरिका के Google Cloud इलाके में है, तो उसे ऐप्लिकेशन के इस्तेमाल में ज़्यादा समय लग सकता है. साथ ही, ऐप्लिकेशन तेज़ी से काम नहीं करेगा. इसके उलट, अगर डेटाबेस भारत या एशिया के किसी दूसरे हिस्से में है, तो ऐप्लिकेशन तेज़ी से काम करेगा और उपयोगकर्ता को बेहतर अनुभव मिलेगा.
भरोसेमंद तरीके से काम करने के लिए डिज़ाइन
यहां दिए गए विषयों से, आपके ऐप्लिकेशन की भरोसेमंद होने की स्थिति बेहतर होती है या इस पर असर पड़ता है:
ऑफ़लाइन मोड चालू करना
Firebase SDK टूल, ऑफ़लाइन डेटा को सेव करने की सुविधा देते हैं. अगर उपयोगकर्ता के डिवाइस पर मौजूद ऐप्लिकेशन, Cloud Firestore से कनेक्ट नहीं हो पाता है, तो ऐप्लिकेशन का इस्तेमाल किया जा सकता है. इसके लिए, स्थानीय तौर पर कैश मेमोरी में सेव किए गए डेटा का इस्तेमाल किया जाता है. इससे यह पक्का किया जाता है कि उपयोगकर्ताओं को डेटा का ऐक्सेस मिलता रहे. भले ही, उन्हें इंटरनेट कनेक्शन में समस्या आ रही हो या वे कुछ घंटों या दिनों तक इंटरनेट का ऐक्सेस पूरी तरह से खो दें. ऑफ़लाइन मोड के बारे में ज़्यादा जानने के लिए, ऑफ़लाइन डेटा चालू करना लेख पढ़ें.
अपने-आप फिर से कोशिश करने की सुविधा के बारे में जानकारी
Firebase SDK, कार्रवाइयों को फिर से करने और टूटे हुए कनेक्शन को फिर से जोड़ने का काम करते हैं. इससे सर्वर को रीस्टार्ट करने या क्लाइंट और डेटाबेस के बीच नेटवर्क की समस्याओं की वजह से होने वाली कुछ समय की गड़बड़ियों को ठीक करने में मदद मिलती है.
किसी देश/इलाके के हिसाब से या एक से ज़्यादा देशों/इलाकों के हिसाब से जगहें चुनें
किसी देश या इलाके के हिसाब से और एक से ज़्यादा देशों या इलाकों के हिसाब से लोकेशन चुनने के बीच कई तरह के फ़ायदे और नुकसान होते हैं. इनमें मुख्य अंतर यह है कि डेटा को कैसे कॉपी किया जाता है. इससे आपके ऐप्लिकेशन की उपलब्धता की गारंटी मिलती है. एक से ज़्यादा क्षेत्रों में मौजूद इंस्टेंस, सेवा देने की ज़्यादा भरोसेमंद सुविधा देता है. साथ ही, आपके डेटा की सुरक्षा को बढ़ाता है. हालांकि, इसके लिए आपको ज़्यादा कीमत चुकानी पड़ती है.
रीयल-टाइम क्वेरी सिस्टम के बारे में जानकारी
रीयल-टाइम क्वेरी को स्नैपशॉट लिसनर भी कहा जाता है. इनकी मदद से ऐप्लिकेशन, डेटाबेस में होने वाले बदलावों को सुन सकता है. साथ ही, डेटा में बदलाव होने पर कम समय में सूचनाएं पा सकता है. कोई ऐप्लिकेशन, डेटाबेस को समय-समय पर पोल करके भी यही नतीजा पा सकता है. हालांकि, यह तरीका अक्सर धीमा होता है, इसमें ज़्यादा खर्च आता है, और इसके लिए ज़्यादा कोड की ज़रूरत होती है. रीयल-टाइम क्वेरी सेट अप करने और इस्तेमाल करने के उदाहरणों के लिए, रीयल-टाइम अपडेट पाना लेख पढ़ें. यहां दिए गए सेक्शन में, स्नैपशॉट लिसनर के काम करने के तरीके के बारे में बताया गया है. साथ ही, परफ़ॉर्मेंस को बनाए रखते हुए रीयल-टाइम क्वेरी को स्केल करने के कुछ सबसे सही तरीकों के बारे में बताया गया है.
मान लें कि दो उपयोगकर्ता, मोबाइल एसडीके टूल की मदद से बनाए गए मैसेजिंग ऐप्लिकेशन के ज़रिए Cloud Firestore से कनेक्ट होते हैं.
क्लाइंट A, chatroom नाम के कलेक्शन में दस्तावेज़ जोड़ने और अपडेट करने के लिए, डेटाबेस में लिखता है:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
क्लाइंट B, स्नैपशॉट लिसनर का इस्तेमाल करके, उसी कलेक्शन में अपडेट सुनता है. जब भी कोई नया मैसेज बनाया जाता है, तो क्लाइंट B को तुरंत सूचना मिलती है. इस डायग्राम में, स्नैपशॉट लिसनर के आर्किटेक्चर के बारे में बताया गया है:
जब क्लाइंट B, डेटाबेस से स्नैपशॉट लिसनर को कनेक्ट करता है, तो इवेंट का यह क्रम होता है:
- क्लाइंट B, Cloud Firestore से कनेक्शन खोलता है और Firebase SDK के ज़रिए
onSnapshot(collection("chatroom"))को कॉल करके एक लिसनर रजिस्टर करता है. यह लिसनर कई घंटों तक चालू रह सकता है. - Cloud Firestore फ़्रंटएंड, डेटासेट को बूटस्ट्रैप करने के लिए, मौजूदा स्टोरेज सिस्टम से क्वेरी करता है. यह मिलते-जुलते दस्तावेज़ों का पूरा नतीजा लोड करता है. इसे पोलिंग क्वेरी कहा जाता है. इसके बाद, सिस्टम डेटाबेस के Firebase सुरक्षा नियमों का आकलन करता है. इससे यह पुष्टि की जाती है कि उपयोगकर्ता इस डेटा को ऐक्सेस कर सकता है. अगर उपयोगकर्ता को अनुमति मिली हुई है, तो डेटाबेस उपयोगकर्ता को डेटा दिखाता है.
- इसके बाद, क्लाइंट B की क्वेरी लिसन मोड में चली जाती है. लिसनर, सदस्यता हैंडलर के साथ रजिस्टर करता है और डेटा के अपडेट का इंतज़ार करता है.
- क्लाइंट A अब किसी दस्तावेज़ में बदलाव करने के लिए, राइट ऑपरेशन भेजता है.
- डेटाबेस, दस्तावेज़ में किए गए बदलाव को अपने स्टोरेज सिस्टम में सेव करता है.
- लेन-देन के हिसाब से, सिस्टम एक ही अपडेट को इंटरनल चेंजलॉग में सेव करता है. बदलावों के क्रम को तय करने के लिए, बदलाव की जानकारी देने वाली फ़ाइल का इस्तेमाल किया जाता है.
- इसके बाद, बदलाव की जानकारी देने वाली सुविधा, अपडेट किए गए डेटा को सदस्यता हैंडलर के पूल में भेजती है.
- रिवर्स क्वेरी मैच करने वाला टूल यह देखने के लिए काम करता है कि अपडेट किया गया दस्तावेज़, फ़िलहाल रजिस्टर किए गए किसी स्नैपशॉट लिसनर से मैच करता है या नहीं. इस उदाहरण में, दस्तावेज़ Client B के स्नैपशॉट लिसनर से मेल खाता है. नाम से ही पता चलता है कि रिवर्स क्वेरी मैचिंग, सामान्य डेटाबेस क्वेरी की तरह होती है. हालांकि, इसे उल्टे तरीके से किया जाता है. यह किसी क्वेरी से मेल खाने वाले दस्तावेज़ों को खोजने के लिए, दस्तावेज़ों में खोज करने के बजाय, क्वेरी में खोज करता है. इससे, यह आसानी से पता लगा पाता है कि किसी दस्तावेज़ से कौनसी क्वेरी मेल खाती है. मिलान मिलने पर, सिस्टम उस दस्तावेज़ को स्नैपशॉट लिसनर को भेज देता है. इसके बाद, सिस्टम डेटाबेस के Firebase Security Rules का आकलन करता है, ताकि यह पक्का किया जा सके कि डेटा सिर्फ़ उन उपयोगकर्ताओं को मिले जिनके पास इसे ऐक्सेस करने का अधिकार है.
- सिस्टम, दस्तावेज़ के अपडेट को क्लाइंट B के डिवाइस पर मौजूद एसडीके को भेजता है. इसके बाद,
onSnapshotकॉलबैक ट्रिगर होता है. अगर लोकल पर्सिस्टेंस की सुविधा चालू है, तो SDK, अपडेट को लोकल कैश मेमोरी पर भी लागू करता है.
Cloud Firestore की स्केलेबिलिटी का एक अहम हिस्सा, बदलाव के लॉग से लेकर सदस्यता हैंडलर और फ़्रंटएंड सर्वर तक के फ़ैन-आउट पर निर्भर करता है. फ़ैन-आउट की मदद से, डेटा में हुए किसी भी बदलाव को लाखों उपयोगकर्ताओं तक आसानी से पहुंचाया जा सकता है. इससे रीयल-टाइम क्वेरी और कनेक्ट किए गए उपयोगकर्ताओं को बेहतर तरीके से सेवा दी जा सकती है. इन सभी कॉम्पोनेंट की कई रेप्लिका को अलग-अलग ज़ोन में (या मल्टी-रीजन डिप्लॉयमेंट के मामले में, अलग-अलग क्षेत्रों में) चलाने से, Cloud Firestore ज़्यादा उपलब्धता और स्केलेबिलिटी हासिल करता है.
ध्यान दें कि मोबाइल और वेब SDK टूल से जारी की गई सभी रीड कार्रवाइयां, ऊपर दिए गए मॉडल के मुताबिक होती हैं. ये डिवाइस, पोलिंग क्वेरी करते हैं. इसके बाद, ये डिवाइस 'सुनने का मोड' चालू करते हैं, ताकि यह पक्का किया जा सके कि डिवाइस लगातार काम कर रहा है. यह सुविधा, रीयल-टाइम में सुनने वाले लोगों, किसी दस्तावेज़ को वापस पाने के लिए किए गए कॉल, और एक बार में की जाने वाली क्वेरी पर भी लागू होती है. सिंगल दस्तावेज़ से जानकारी पाने और एक बार में की जाने वाली क्वेरी को, कम समय के लिए स्नैपशॉट सुनने वाले के तौर पर माना जा सकता है. इन पर परफ़ॉर्मेंस से जुड़ी एक जैसी पाबंदियां लागू होती हैं.
रीयल-टाइम क्वेरी को स्केल करने के लिए सबसे सही तरीके लागू करना
स्केल की जा सकने वाली रीयल-टाइम क्वेरी डिज़ाइन करने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं.
सिस्टम में ज़्यादा राइट ट्रैफ़िक को समझना
इस सेक्शन से, आपको यह समझने में मदद मिलती है कि राइट अनुरोधों की संख्या बढ़ने पर सिस्टम कैसे काम करता है.
Cloud Firestore बदलावों के लॉग, रीयल-टाइम क्वेरी को प्रोसेस करते हैं. ये लॉग, राइट ट्रैफ़िक बढ़ने पर अपने-आप हॉरिज़ॉन्टल तरीके से स्केल हो जाते हैं. जब किसी डेटाबेस के लिए राइट रेट, किसी एक सर्वर की क्षमता से ज़्यादा हो जाता है, तो बदलावों का लॉग कई सर्वर में बंट जाता है. साथ ही, क्वेरी प्रोसेसिंग एक के बजाय कई सदस्यता हैंडलर से डेटा इस्तेमाल करने लगती है. क्लाइंट और एसडीके के नज़रिए से, यह सब पारदर्शी है. साथ ही, जब स्प्लिट होते हैं, तो ऐप्लिकेशन को कोई कार्रवाई करने की ज़रूरत नहीं होती. इस डायग्राम में दिखाया गया है कि रीयल-टाइम क्वेरी कैसे स्केल होती हैं:
ऑटोमैटिक स्केलिंग की सुविधा की मदद से, बिना किसी सीमा के राइट ट्रैफ़िक को बढ़ाया जा सकता है. हालांकि, ट्रैफ़िक बढ़ने पर सिस्टम को जवाब देने में कुछ समय लग सकता है. 5-5-5 नियम के सुझावों का पालन करें, ताकि राइट हॉटस्पॉट न बने. Key Visualizer, राइट हॉटस्पॉट का विश्लेषण करने के लिए एक उपयोगी टूल है.
कई ऐप्लिकेशन में, अनुमान के मुताबिक ऑर्गैनिक ग्रोथ होती है. Cloud Firestore बिना किसी सावधानी के इस ग्रोथ को मैनेज कर सकता है. हालांकि, बड़े डेटासेट को इंपोर्ट करने जैसे बैच वर्कलोड की वजह से, राइट ऑपरेशन बहुत तेज़ी से बढ़ सकते हैं. ऐप्लिकेशन डिज़ाइन करते समय, इस बात का ध्यान रखें कि राइट ट्रैफ़िक कहां से आता है.
समझें कि लिखने और पढ़ने की प्रोसेस कैसे इंटरैक्ट करती है
रीयल-टाइम क्वेरी सिस्टम को एक पाइपलाइन के तौर पर देखा जा सकता है. यह पाइपलाइन, लिखने की कार्रवाइयों को पढ़ने वालों से कनेक्ट करती है. जब भी कोई दस्तावेज़ बनाया जाता है, अपडेट किया जाता है या मिटाया जाता है, तो बदलाव स्टोरेज सिस्टम से उन लिसनर तक पहुंच जाता है जिन्होंने फ़िलहाल रजिस्टर किया है. Cloud Firestore के बदलाव के लॉग का स्ट्रक्चर, डेटा में एकरूपता बनाए रखने की गारंटी देता है. इसका मतलब है कि आपके ऐप्लिकेशन को कभी भी ऐसे अपडेट की सूचनाएं नहीं मिलती हैं जो डेटाबेस में डेटा में हुए बदलावों के क्रम से अलग हों. इससे ऐप्लिकेशन डेवलपमेंट आसान हो जाता है, क्योंकि डेटा की कंसिस्टेंसी से जुड़े मुश्किल मामले हट जाते हैं.
कनेक्ट की गई इस पाइपलाइन का मतलब है कि हॉटस्पॉट या लॉक कंटेंशन की वजह से, डेटा को लिखने की कार्रवाई से डेटा को पढ़ने की कार्रवाइयों पर बुरा असर पड़ सकता है. जब लिखने की कार्रवाइयां पूरी नहीं होती हैं या थ्रॉटलिंग की समस्या आती है, तो हो सकता है कि पढ़ने की कार्रवाई, बदलाव के लॉग से एक जैसा डेटा मिलने का इंतज़ार करे. अगर आपके ऐप्लिकेशन में ऐसा होता है, तो आपको क्वेरी के लिए, डेटा लिखने की प्रोसेस धीमी होने के साथ-साथ जवाब मिलने में भी ज़्यादा समय लग सकता है. हॉटस्पॉट से बचना, इस समस्या से बचने का सबसे अच्छा तरीका है.
दस्तावेज़ों और लिखने की कार्रवाइयों को छोटा रखें
स्नैपशॉट लिसनर का इस्तेमाल करके ऐप्लिकेशन बनाते समय, आम तौर पर यह ज़रूरी होता है कि उपयोगकर्ताओं को डेटा में हुए बदलावों के बारे में तुरंत पता चले. इसके लिए, चीज़ों को छोटा रखने की कोशिश करें. सिस्टम, कम फ़ील्ड वाले छोटे दस्तावेज़ों को बहुत तेज़ी से प्रोसेस कर सकता है. बड़े दस्तावेज़ों में सैकड़ों फ़ील्ड और ज़्यादा डेटा होता है. इसलिए, इन्हें प्रोसेस होने में ज़्यादा समय लगता है.
इसी तरह, कम समय में होने वाली कमिट और राइट कार्रवाइयों को प्राथमिकता दें, ताकि इंतज़ार का समय कम हो. ज़्यादा संख्या में बैच बनाने से, लेखक को ज़्यादा थ्रूपुट मिल सकता है. हालांकि, इससे स्नैपशॉट सुनने वाले लोगों को सूचना मिलने में ज़्यादा समय लग सकता है. यह अक्सर अन्य डेटाबेस सिस्टम के इस्तेमाल की तुलना में अलग होता है. अन्य डेटाबेस सिस्टम में, परफ़ॉर्मेंस को बेहतर बनाने के लिए बैचिंग का इस्तेमाल किया जा सकता है.
सही लिसनर का इस्तेमाल करें
आपके डेटाबेस के लिए राइट रेट बढ़ने पर, Cloud Firestore डेटा प्रोसेसिंग को कई सर्वर में बांट देता है. Cloud Firestore का शार्डिंग एल्गोरिदम, एक ही कलेक्शन या कलेक्शन ग्रुप के डेटा को एक ही बदलाव लॉग सर्वर पर रखने की कोशिश करता है. सिस्टम, क्वेरी को प्रोसेस करने में शामिल सर्वर की संख्या को कम से कम रखते हुए, ज़्यादा से ज़्यादा राइट थ्रूपुट देने की कोशिश करता है.
हालांकि, कुछ पैटर्न की वजह से स्नैपशॉट लिसनर के लिए अब भी सबऑप्टिमल व्यवहार हो सकता है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन ज़्यादातर डेटा को एक बड़े कलेक्शन में सेव करता है, तो लिसनर को ज़रूरी डेटा पाने के लिए, कई सर्वर से कनेक्ट करना पड़ सकता है. क्वेरी फ़िल्टर लागू करने पर भी यह लागू होता है. कई सर्वर से कनेक्ट करने पर, जवाब मिलने में देरी हो सकती है.
जवाब मिलने में होने वाली इस देरी से बचने के लिए, अपने स्कीमा और ऐप्लिकेशन को इस तरह से डिज़ाइन करें कि सिस्टम, कई अलग-अलग सर्वर पर जाए बिना ही श्रोताओं को जवाब दे सके. डेटा को छोटे-छोटे कलेक्शन में बांटने से, राइट रेट कम हो सकता है.
यह रिलेशनल डेटाबेस में परफ़ॉर्मेंस क्वेरी के बारे में सोचने जैसा है, जिसके लिए पूरी टेबल स्कैन करने की ज़रूरत होती है. रिलेशनल डेटाबेस में, पूरी टेबल को स्कैन करने वाली क्वेरी, स्नैपशॉट लिसनर के बराबर होती है. यह लिसनर, ऐसे कलेक्शन पर नज़र रखता है जिसमें डेटा में लगातार बदलाव होता रहता है. यह क्वेरी, उस क्वेरी की तुलना में धीरे-धीरे काम कर सकती है जिसे डेटाबेस, ज़्यादा सटीक इंडेक्स का इस्तेमाल करके पूरा कर सकता है. ज़्यादा खास इंडेक्स वाली क्वेरी, स्नैपशॉट लिसनर की तरह होती है. यह किसी एक दस्तावेज़ या ऐसे कलेक्शन पर नज़र रखती है जिसमें अक्सर बदलाव नहीं होता. आपको अपने ऐप्लिकेशन को लोड करके टेस्ट करना चाहिए, ताकि आपको इस्तेमाल के उदाहरणों से जुड़ी समस्याओं के बारे में बेहतर तरीके से पता चल सके.
पोलिंग क्वेरी को तेज़ी से प्रोसेस करना
रीयल-टाइम में जवाब देने वाली क्वेरी का एक और अहम हिस्सा यह पक्का करना है कि डेटा को बूटस्ट्रैप करने के लिए पोलिंग क्वेरी, तेज़ी से और असरदार तरीके से काम करे. जब कोई नया स्नैपशॉट लिसनर पहली बार कनेक्ट होता है, तो उसे पूरे नतीजे का सेट लोड करना होता है. इसके बाद, उसे यह सेट उपयोगकर्ता के डिवाइस पर भेजना होता है. क्वेरी के धीमे होने से, आपका ऐप्लिकेशन कम रिस्पॉन्सिव हो जाता है. उदाहरण के लिए, इसमें ऐसी क्वेरी शामिल हैं जो कई दस्तावेज़ों को पढ़ने की कोशिश करती हैं या ऐसी क्वेरी जो सही इंडेक्स का इस्तेमाल नहीं करती हैं.
कुछ मामलों में, लिसनर को सुनने की स्थिति से वापस पोलिंग की स्थिति में भी ले जाया जा सकता है. यह प्रोसेस अपने-आप होती है. साथ ही, एसडीके और आपके ऐप्लिकेशन को इसकी जानकारी होती है. इन स्थितियों में पोलिंग की स्थिति ट्रिगर हो सकती है:
- लोड में हुए बदलावों की वजह से, सिस्टम बदलाव के लॉग को फिर से बैलेंस करता है.
- हॉटस्पॉट की वजह से, डेटाबेस में डेटा लिखने में देरी होती है या डेटा नहीं लिखा जा पाता.
- सर्वर के कुछ समय के लिए रीस्टार्ट होने से, सुनने वालों पर कुछ समय के लिए असर पड़ता है.
अगर आपकी पोलिंग क्वेरी तेज़ी से पूरी होती हैं, तो पोलिंग की स्थिति आपके ऐप्लिकेशन के उपयोगकर्ताओं को दिखती है.
ज़्यादा समय तक संगीत सुनने वाले लोगों को प्राथमिकता दें
Cloud Firestore का इस्तेमाल करने वाला ऐप्लिकेशन बनाने के लिए, अक्सर श्रोताओं को लंबे समय तक जोड़े रखना और उन्हें ऐप्लिकेशन पर बनाए रखना सबसे किफ़ायती तरीका होता है. Cloud Firestore का इस्तेमाल करने पर, आपसे सिर्फ़ उन दस्तावेज़ों के लिए शुल्क लिया जाता है जो आपके ऐप्लिकेशन को वापस भेजे जाते हैं. आपसे ओपन कनेक्शन बनाए रखने के लिए शुल्क नहीं लिया जाता. स्नैपशॉट लिसनर लंबे समय तक काम करता है. यह अपनी पूरी लाइफ़टाइम में सिर्फ़ उतना ही डेटा पढ़ता है जितना क्वेरी को पूरा करने के लिए ज़रूरी होता है. इसमें, शुरुआती पोलिंग ऑपरेशन शामिल होता है. इसके बाद, डेटा में बदलाव होने पर सूचनाएं मिलती हैं. दूसरी ओर, वन-शॉट क्वेरी ऐसे डेटा को फिर से पढ़ती हैं जिसमें शायद तब से कोई बदलाव नहीं हुआ है, जब ऐप्लिकेशन ने आखिरी बार क्वेरी को एक्ज़ीक्यूट किया था.
अगर आपके ऐप्लिकेशन को ज़्यादा डेटा इस्तेमाल करना है, तो स्नैपशॉट लिसनर का इस्तेमाल करना सही नहीं होगा. उदाहरण के लिए, अगर इस्तेमाल के किसी मामले में, कनेक्शन के ज़रिए हर सेकंड में कई दस्तावेज़ भेजे जाते हैं, तो एक बार में की जाने वाली ऐसी क्वेरी का इस्तेमाल करना बेहतर हो सकता है जो कम फ़्रीक्वेंसी पर चलती हैं.
आगे क्या करना है
- स्नैपशॉट लिसनर इस्तेमाल करने का तरीका जानें.
- सबसे सही तरीकों के बारे में ज़्यादा जानें.