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