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