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