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