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