अपने सर्वरलेस ऐप्लिकेशन को हर सेकंड हजारों ऑपरेशन या एक साथ लाखों उपयोगकर्ताओं के हिसाब से बढ़ाने के बारे में दिशा-निर्देश पाने के लिए, यह दस्तावेज़ पढ़ें. इस दस्तावेज़ में बेहतर विषय शामिल हैं, ताकि आपको सिस्टम को बेहतर तरीके से समझने में मदद मिल सके. अगर आपने अभी Cloud Firestore का इस्तेमाल शुरू किया है, तो क्विकस्टार्ट गाइड देखें.
Cloud Firestore और Firebase के मोबाइल/वेब SDK टूल, बिना सर्वर वाले ऐप्लिकेशन बनाने के लिए एक बेहतरीन मॉडल उपलब्ध कराते हैं. इनमें क्लाइंट-साइड कोड, सीधे तौर पर डेटाबेस को ऐक्सेस करता है. एसडीके की मदद से, क्लाइंट रीयल-टाइम में डेटा के अपडेट सुन सकते हैं. रीयल-टाइम अपडेट का इस्तेमाल करके, ऐसे रिस्पॉन्सिव ऐप्लिकेशन बनाए जा सकते हैं जिनके लिए सर्वर इन्फ़्रास्ट्रक्चर की ज़रूरत नहीं होती. Cloud Firestore को सेट अप करना और चलाना बहुत आसान है. इससे, Cloud Firestore को बनाने वाले सिस्टम की सीमाओं को समझने में मदद मिलती है. इससे, ट्रैफ़िक बढ़ने पर आपका सर्वरलेस ऐप्लिकेशन स्केल कर पाता है और बेहतर तरीके से काम कर पाता है.
अपने ऐप्लिकेशन को बड़े पैमाने पर इस्तेमाल करने के बारे में सलाह पाने के लिए, यहां दिए गए सेक्शन देखें.
अपने उपयोगकर्ताओं के आस-पास डेटाबेस की जगह चुनना
इस डायग्राम में, रीयल-टाइम ऐप्लिकेशन के आर्किटेक्चर के बारे में बताया गया है:
जब उपयोगकर्ता के डिवाइस (मोबाइल या वेब) पर चल रहा कोई ऐप्लिकेशन, Cloud Firestore से कनेक्ट होता है, तो कनेक्शन को उसी इलाके के Cloud Firestore फ़्रंटएंड सर्वर पर भेजा जाता है जहां आपका डेटाबेस मौजूद होता है. उदाहरण के लिए, अगर आपका डेटाबेस us-east1 में है, तो कनेक्शन us-east1 में मौजूद Cloud Firestore फ़्रंटएंड पर भी जाता है. ये कनेक्शन लंबे समय तक चलते हैं और ऐप्लिकेशन के साफ़ तौर पर बंद किए जाने तक खुले रहते हैं. फ़्रंटएंड, Cloud Firestore स्टोरेज सिस्टम से डेटा पढ़ता है.
उपयोगकर्ता की मौजूदा जगह और Cloud Firestore डेटाबेस की जगह के बीच की दूरी का असर, उपयोगकर्ता को मिलने वाले इंतज़ार के समय पर पड़ता है. उदाहरण के लिए, भारत में रहने वाले किसी उपयोगकर्ता के ऐप्लिकेशन का डेटाबेस, नॉर्थ अमेरिका के Google Cloud इलाके में हो सकता है. ऐसे में, उसे ऐप्लिकेशन का इस्तेमाल करने में ज़्यादा समय लग सकता है और ऐप्लिकेशन उतना तेज़ काम नहीं करेगा जितना कि भारत या एशिया के किसी दूसरे इलाके में मौजूद डेटाबेस के साथ काम करने पर होता है.
भरोसेमंद डिज़ाइन
इन विषयों से आपके ऐप्लिकेशन की भरोसेमंदता को बेहतर बनाने या उस पर असर डालने में मदद मिलती है:
ऑफ़लाइन मोड चालू करना
Firebase SDK टूल, ऑफ़लाइन डेटा को सेव रखने की सुविधा देते हैं. अगर उपयोगकर्ता के डिवाइस पर मौजूद ऐप्लिकेशन, Cloud Firestore से कनेक्ट नहीं हो पाता है, तो भी ऐप्लिकेशन का इस्तेमाल किया जा सकता है. इसके लिए, ऐप्लिकेशन में कैश मेमोरी में सेव किया गया डेटा इस्तेमाल किया जाता है. इससे, उपयोगकर्ताओं को डेटा का ऐक्सेस तब भी मिलता रहेगा, जब इंटरनेट कनेक्शन में रुकावट आ रही हो या कई घंटों या दिनों तक इंटरनेट का ऐक्सेस पूरी तरह से बंद हो. ऑफ़लाइन मोड के बारे में ज़्यादा जानकारी के लिए, ऑफ़लाइन डेटा चालू करना लेख पढ़ें.
अपने-आप दोबारा कोशिश करने की सुविधा के बारे में जानकारी
Firebase SDK टूल, फिर से कोशिश करने और टूटे हुए कनेक्शन को फिर से जोड़ने की सुविधा देते हैं. इससे, सर्वर को रीस्टार्ट करने या क्लाइंट और डेटाबेस के बीच नेटवर्क से जुड़ी समस्याओं की वजह से होने वाली गड़बड़ियों को ठीक करने में मदद मिलती है.
एक से ज़्यादा इलाकों के लिए और क्षेत्र के हिसाब से साइटें बनाना
क्षेत्रीय और एक से ज़्यादा क्षेत्रों में मौजूद जगहों में से किसी एक को चुनने पर, कई फ़ायदे और नुकसान होते हैं. मुख्य अंतर यह है कि डेटा को डुप्लीकेट करने का तरीका अलग-अलग है. इससे, आपके ऐप्लिकेशन के उपलब्ध होने की गारंटी मिलती है. एक से ज़्यादा क्षेत्रों में मौजूद इंस्टेंस से, आपके डेटा को बेहतर तरीके से दिखाया जा सकता है और उसकी लाइफ़ बढ़ती है. हालांकि, इसके लिए ज़्यादा खर्च करना पड़ता है.
रीयल-टाइम क्वेरी सिस्टम को समझना
रीयल-टाइम क्वेरी, जिन्हें स्नैपशॉट लिसनर भी कहा जाता है, इनकी मदद से ऐप्लिकेशन को डेटाबेस में होने वाले बदलावों के बारे में पता चलता है. साथ ही, डेटा में बदलाव होने के तुरंत बाद, ऐप्लिकेशन को सूचनाएं मिलती हैं. ऐप्लिकेशन को अपडेट के लिए, समय-समय पर डेटाबेस को पोल करके भी वही नतीजा मिल सकता है. हालांकि, यह तरीका अक्सर धीमा और ज़्यादा महंगा होता है. साथ ही, इसके लिए ज़्यादा कोड की ज़रूरत होती है. रीयल-टाइम क्वेरी को सेट अप करने और इस्तेमाल करने के उदाहरणों के लिए, रीयल-टाइम अपडेट पाना लेख पढ़ें. नीचे दिए गए सेक्शन में, स्नैपशॉट लिसनर के काम करने के तरीके के बारे में बताया गया है. साथ ही, परफ़ॉर्मेंस को बनाए रखते हुए रीयल-टाइम क्वेरी को स्केल करने के सबसे सही तरीकों के बारे में भी बताया गया है.
मान लें कि दो उपयोगकर्ता, किसी मोबाइल 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 की क्वेरी सुनने के मोड में चली जाती है. Listener, सदस्यता मैनेजर के साथ रजिस्टर करता है और डेटा के अपडेट का इंतज़ार करता है.
- क्लाइंट A अब किसी दस्तावेज़ में बदलाव करने के लिए, लिखने का ऑपरेशन भेजता है.
- डेटाबेस, दस्तावेज़ में किए गए बदलाव को अपने स्टोरेज सिस्टम में सेव करता है.
- लेन-देन के हिसाब से, सिस्टम उसी अपडेट को किसी इंटरनल बदलावों की सूची में डाल देता है. बदलावों के होने के हिसाब से, बदलावों की सूची में बदलावों का क्रम तय होता है.
- बदलावों की जानकारी देने वाली फ़ाइल, अपडेट किए गए डेटा को सदस्यता मैनेज करने वाले प्रोग्राम के पूल में भेजती है.
- रिवर्स क्वेरी मैचर यह देखने के लिए काम करता है कि अपडेट किया गया दस्तावेज़, फ़िलहाल रजिस्टर किए गए किसी स्नैपशॉट लिसनर से मैच करता है या नहीं. इस उदाहरण में, दस्तावेज़, क्लाइंट B के स्नैपशॉट लिसनर से मैच करता है. जैसा कि नाम से पता चलता है, रिवर्स क्वेरी मैचर को सामान्य डेटाबेस क्वेरी के तौर पर देखा जा सकता है. हालांकि, यह क्वेरी रिवर्स में की जाती है. यह किसी क्वेरी से मैच करने वाले दस्तावेज़ों को खोजने के बजाय, आने वाले दस्तावेज़ से मैच करने वाली क्वेरी को खोजता है. मैच मिलने पर, सिस्टम उस दस्तावेज़ को स्नैपशॉट सुनने वालों को फ़ॉरवर्ड करता है. इसके बाद, सिस्टम डेटाबेस के Firebase के सुरक्षा नियमों का आकलन करता है, ताकि यह पक्का किया जा सके कि सिर्फ़ अनुमति वाले उपयोगकर्ताओं को डेटा मिले.
- सिस्टम, दस्तावेज़ के अपडेट को क्लाइंट B के डिवाइस पर SDK टूल पर फ़ॉरवर्ड करता है और
onSnapshotकॉलबैक ट्रिगर होता है. अगर लोकल पर्सिस्टेंस की सुविधा चालू है, तो SDK, अपडेट को लोकल कैश मेमोरी में भी लागू करता है.
Cloud Firestore को स्केल करने का एक अहम हिस्सा, बदलावों की सूची से सदस्यता मैनेजर और फ़्रंटएंड सर्वर तक फैन-आउट पर निर्भर करता है. फ़ैन-आउट की मदद से, किसी एक डेटा में हुए बदलाव को रीयल-टाइम में लाखों क्वेरी और कनेक्ट किए गए उपयोगकर्ताओं तक पहुंचाने में मदद मिलती है. एक से ज़्यादा क्षेत्रों में डिप्लॉय किए जाने पर, Cloud Firestore कई ज़ोन (या एक से ज़्यादा क्षेत्रों) में इन सभी कॉम्पोनेंट की कई कॉपी चलाता है. इससे, Cloud Firestore की उपलब्धता और स्केलिंग बेहतर होती है.
ध्यान दें कि मोबाइल और वेब SDK टूल से जारी किए गए सभी रीड ऑपरेशन, ऊपर दिए गए मॉडल के मुताबिक होते हैं. ये पोल की क्वेरी के बाद, सुनने के मोड का इस्तेमाल करते हैं, ताकि एक जैसी क्वालिटी बनाए रखी जा सके. यह रीयल-टाइम में सुनने वालों, किसी दस्तावेज़ को वापस पाने के लिए किए गए कॉल, और एक बार में की जाने वाली क्वेरी पर भी लागू होता है. एक दस्तावेज़ को फिर से पाने और एक बार में कई क्वेरी करने की सुविधा को, कुछ समय के लिए काम करने वाले स्नैपशॉट लिसनर के तौर पर देखा जा सकता है. इन परफ़ॉर्मेंस से जुड़ी समस्याएं भी स्नैपशॉट लिसनर जैसी ही होती हैं.
रीयल-टाइम क्वेरी को स्केल करने के लिए सबसे सही तरीके अपनाना
स्केलेबल रीयल-टाइम क्वेरी डिज़ाइन करने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं.
सिस्टम में डेटा लिखने के लिए आने वाले ज़्यादा ट्रैफ़िक को समझना
इस सेक्शन से आपको यह समझने में मदद मिलती है कि लिखने के बढ़ते अनुरोधों पर सिस्टम कैसे प्रतिक्रिया देता है.
रीयल-टाइम क्वेरी चलाने वाले Cloud Firestore बदलावों की जानकारी वाले डेटाबेस, लिखने के ट्रैफ़िक बढ़ने पर अपने-आप हॉरिज़ॉन्टल तौर पर स्केल होते हैं. जब किसी डेटाबेस के लिए लिखने की दर, एक सर्वर के मैनेज करने की सीमा से ज़्यादा हो जाती है, तो बदलावों की सूची को कई सर्वर में बांट दिया जाता है. साथ ही, क्वेरी प्रोसेसिंग एक के बजाय कई सदस्यता हैंडलर से डेटा का इस्तेमाल शुरू कर देती है. क्लाइंट और SDK के नज़रिए से, यह पूरी तरह से पारदर्शी है. साथ ही, आय के बंटवारे के दौरान ऐप्लिकेशन को कुछ करने की ज़रूरत नहीं होती. इस डायग्राम में दिखाया गया है कि रीयल-टाइम क्वेरी कैसे स्केल करती हैं:
अपने-आप स्केल होने की सुविधा की मदद से, लिखने के ट्रैफ़िक को बिना किसी सीमा के बढ़ाया जा सकता है. हालांकि, ट्रैफ़िक बढ़ने पर, सिस्टम को जवाब देने में कुछ समय लग सकता है. लिखने के लिए हॉटस्पॉट बनाने से बचने के लिए, 5-5-5 नियम के सुझावों का पालन करें. की विज़ुअलाइज़र, लिखने के हॉटस्पॉट का विश्लेषण करने के लिए एक मददगार टूल है.
कई ऐप्लिकेशन में ऑर्गैनिक तरीके से होने वाली बढ़ोतरी का अनुमान लगाया जा सकता है. Cloud Firestore के लिए, इनमें कोई सावधानी बरतने की ज़रूरत नहीं होती. हालांकि, बड़े डेटासेट को इंपोर्ट करने जैसे बैच वर्कलोड की वजह से, डेटा को लिखने की प्रोसेस बहुत तेज़ी से बढ़ सकती है. ऐप्लिकेशन डिज़ाइन करते समय, इस बात का ध्यान रखें कि आपका लिखने वाला ट्रैफ़िक कहां से आता है.
यह समझना कि लिखने और पढ़ने की सुविधाएं कैसे इंटरैक्ट करती हैं
रीयल-टाइम क्वेरी सिस्टम को, लिखने के ऑपरेशन को रीडर से जोड़ने वाली पाइपलाइन के तौर पर देखा जा सकता है. जब भी कोई दस्तावेज़ बनाया जाता है, अपडेट किया जाता है या मिटाया जाता है, तो बदलाव स्टोरेज सिस्टम से, फ़िलहाल रजिस्टर किए गए लिसनर को भेज दिया जाता है. Cloud Firestore के बदलावों की जानकारी वाले पेज का स्ट्रक्चर, डेटा में होने वाले बदलावों के लिए एक जैसा रहता है. इसका मतलब है कि आपके ऐप्लिकेशन को कभी भी ऐसे अपडेट की सूचनाएं नहीं मिलतीं जो डेटाबेस में डेटा में हुए बदलावों के मुकाबले, गलत क्रम में हों. इससे डेटा के एक जैसे होने से जुड़े एज केस हट जाते हैं और ऐप्लिकेशन डेवलप करना आसान हो जाता है.
कनेक्ट की गई इस पाइपलाइन का मतलब है कि हॉटस्पॉट या लॉक पर दावा करने की वजह से, लिखने की प्रोसेस पर बुरा असर पड़ सकता है. जब डेटा लिखने की प्रोसेस पूरी नहीं होती या डेटा ट्रॉथलिंग की समस्या आती है, तो हो सकता है कि बदलावों की जानकारी देने वाले लॉग से डेटा मिलने का इंतज़ार करते समय, डेटा पढ़ने की प्रोसेस रुक जाए. अगर आपके ऐप्लिकेशन में ऐसा होता है, तो आपको डेटा लिखने में लगने वाला समय धीमा लग सकता है. साथ ही, क्वेरी के लिए जवाब मिलने में लगने वाला समय भी धीमा लग सकता है. इस समस्या से बचने के लिए, हॉटस्पॉट से दूर रहें.
दस्तावेज़ों और लिखने के ऑपरेशन को छोटा रखें
स्नैपशॉट लिसनर की मदद से ऐप्लिकेशन बनाते समय, आम तौर पर आपके पास यह तय करने का विकल्प होता है कि उपयोगकर्ताओं को डेटा में हुए बदलावों के बारे में तुरंत पता चलना चाहिए या नहीं. ऐसा करने के लिए, वीडियो को छोटा रखें. सिस्टम, ज़्यादा फ़ील्ड वाले छोटे दस्तावेज़ों को बहुत तेज़ी से प्रोसेस कर सकता है. सैकड़ों फ़ील्ड और बड़े डेटा वाले बड़े दस्तावेज़ों को प्रोसेस करने में ज़्यादा समय लगता है.
इसी तरह, इंतज़ार का समय कम रखने के लिए, कम और तेज़ी से कमिट करने और लिखने की सुविधा का इस्तेमाल करें. बड़े बैच से, डेटा लिखने वाले के हिसाब से आपको ज़्यादा थ्रूपुट मिल सकता है. हालांकि, इससे स्नैपशॉट सुनने वालों को सूचना मिलने में ज़्यादा समय लग सकता है. यह अक्सर अन्य डेटाबेस सिस्टम के इस्तेमाल की तुलना में, गलत साबित होता है. इन सिस्टम में, परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक साथ कई टास्क करने की सुविधा का इस्तेमाल किया जा सकता है.
असरदार तरीके से सुनने वाले लोगों का इस्तेमाल करना
आपके डेटाबेस में डेटा लिखने की दर बढ़ने पर, Cloud Firestore डेटा प्रोसेसिंग को कई सर्वर पर बांट देता है. Cloud Firestore का शार्डिंग एल्गोरिदम, एक ही कलेक्शन या कलेक्शन ग्रुप के डेटा को एक ही चैंजलॉग सर्वर पर एक साथ रखने की कोशिश करता है. सिस्टम, क्वेरी को प्रोसेस करने में शामिल सर्वर की संख्या को कम से कम रखते हुए, डेटा को ज़्यादा से ज़्यादा तेज़ी से लिखने की कोशिश करता है.
हालांकि, कुछ पैटर्न की वजह से हो सकता है कि स्नैपशॉट सुनने वालों को अब भी बेहतर परफ़ॉर्मेंस न मिले. उदाहरण के लिए, अगर आपका ऐप्लिकेशन अपना ज़्यादातर डेटा एक बड़े कलेक्शन में सेव करता है, तो हो सकता है कि Listener को ज़रूरी डेटा पाने के लिए कई सर्वर से कनेक्ट करना पड़े. क्वेरी फ़िल्टर लागू करने पर भी यह बात लागू होती है. कई सर्वर से कनेक्ट करने पर, जवाब मिलने में ज़्यादा समय लग सकता है.
रिस्पॉन्स मिलने में लगने वाले समय को कम करने के लिए, अपना स्कीमा और ऐप्लिकेशन इस तरह डिज़ाइन करें कि सिस्टम, कई अलग-अलग सर्वर पर जाने के बिना ही गाने सुनने वालों को गाने दिखा सके. अपने डेटा को छोटे कलेक्शन में बांटकर, कम लिखने की दर से डेटा डालने पर बेहतर नतीजे मिल सकते हैं.
यह उसी तरह है जैसे किसी रिलेशनल डेटाबेस में परफ़ॉर्मेंस क्वेरी के बारे में सोचना, जिसमें पूरी टेबल को स्कैन करना ज़रूरी होता है. रिलेशनल डेटाबेस में, ऐसी क्वेरी जिसे पूरी टेबल को स्कैन करने की ज़रूरत होती है वह स्नैपशॉट लिसनर के बराबर होती है, जो ज़्यादा चर्न आउट वाले कलेक्शन को देखता है. यह क्वेरी, किसी ऐसी क्वेरी की तुलना में धीमी हो सकती है जिसे डेटाबेस, ज़्यादा सटीक इंडेक्स का इस्तेमाल करके दिखा सकता है. ज़्यादा सटीक इंडेक्स वाली क्वेरी, स्नैपशॉट लिसनर की तरह होती है. यह किसी एक दस्तावेज़ या ऐसे कलेक्शन को देखती है जो कम बार बदलता है. आपको अपने ऐप्लिकेशन को लोड करके उसकी जांच करनी चाहिए, ताकि इस्तेमाल के उदाहरण के व्यवहार और ज़रूरत को बेहतर तरीके से समझा जा सके.
पोल से जुड़ी क्वेरी को तेज़ी से प्रोसेस करना
रिस्पॉन्सिव रीयल-टाइम क्वेरी का एक और अहम हिस्सा यह पक्का करना है कि डेटा को बूटस्ट्रैप करने के लिए, पल्सिंग क्वेरी तेज़ और असरदार हो. जब कोई नया स्नैपशॉट लिसनर पहली बार कनेक्ट होता है, तो उसे पूरा नतीजा सेट लोड करना होता है और उसे उपयोगकर्ता के डिवाइस पर भेजना होता है. धीमी क्वेरी से आपका ऐप्लिकेशन धीमा हो जाता है. उदाहरण के लिए, इसमें ऐसी क्वेरी शामिल हैं जो कई दस्तावेज़ों को पढ़ने की कोशिश करती हैं या ऐसी क्वेरी जो सही इंडेक्स का इस्तेमाल नहीं करती हैं.
कुछ मामलों में, हो सकता है कि सुनने की स्थिति से, फिर से पोलिंग की स्थिति पर स्विच किया जाए. यह अपने-आप होता है और SDK टूल और आपके ऐप्लिकेशन के लिए साफ़ तौर पर दिखता है. इन स्थितियों में, पोलिंग की स्थिति ट्रिगर हो सकती है:
- लोड में हुए बदलावों की वजह से, सिस्टम बदलावों की सूची को फिर से बैलेंस करता है.
- हॉटस्पॉट की वजह से, डेटाबेस में डेटा को लिखने में देरी होती है या वह लिखा ही नहीं जाता.
- सर्वर के कुछ समय के लिए बंद होने पर, दर्शकों पर कुछ समय के लिए असर पड़ता है.
अगर पोलिंग क्वेरी तेज़ी से पूरी होती हैं, तो आपके ऐप्लिकेशन के उपयोगकर्ताओं को पोलिंग की स्थिति साफ़ तौर पर दिखती है.
लंबे समय तक सुनने वाले दर्शकों को प्राथमिकता दी जाती है
Cloud Firestore का इस्तेमाल करने वाले ऐप्लिकेशन को बनाने का सबसे किफ़ायती तरीका यह है कि दर्शकों को ऐप्लिकेशन पर जितनी देर हो सके उतनी देर तक बनाए रखें. Cloud Firestore का इस्तेमाल करने पर, आपके ऐप्लिकेशन में वापस भेजे गए दस्तावेज़ों के लिए शुल्क लिया जाता है, न कि खुले कनेक्शन को बनाए रखने के लिए. लंबे समय तक चलने वाला स्नैपशॉट लिसनर, अपने पूरे जीवनकाल के दौरान सिर्फ़ वह डेटा पढ़ता है जिसकी ज़रूरत उसे क्वेरी को पूरा करने के लिए होती है. इसमें, शुरुआती पोलिंग ऑपरेशन के बाद, डेटा में असल बदलाव होने पर सूचनाएं भेजी जाती हैं. दूसरी ओर, वन-शॉट क्वेरी, उस डेटा को फिर से पढ़ती हैं जो ऐप्लिकेशन के आखिरी बार क्वेरी लागू करने के बाद शायद बदला न हो.
अगर आपके ऐप्लिकेशन को ज़्यादा डेटा की ज़रूरत है, तो हो सकता है कि स्नैपशॉट लिसनर सही न हों. उदाहरण के लिए, अगर आपके इस्तेमाल के उदाहरण में, लंबे समय तक किसी कनेक्शन के ज़रिए हर सेकंड कई दस्तावेज़ भेजे जाते हैं, तो कम फ़्रीक्वेंसी पर चलने वाली वन-शॉट क्वेरी चुनना बेहतर होगा.
आगे क्या करना है
- स्नैपशॉट लिसनर इस्तेमाल करने का तरीका जानें.
- सबसे सही तरीकों के बारे में ज़्यादा पढ़ें.