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