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