अपने ऐप्लिकेशन में, Firebase Realtime Database परफ़ॉर्मेंस को बेहतर बनाने के कुछ अलग-अलग तरीके हैं. Realtime Databaseपरफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, Realtime Database की निगरानी करने वाले अलग-अलग टूल की मदद से डेटा इकट्ठा करें. इसके बाद, अपने ऐप्लिकेशन या Realtime Databaseके इस्तेमाल में ज़रूरी बदलाव करें.
Realtime Database की परफ़ॉर्मेंस को मॉनिटर करना
अपने Realtime Database's की परफ़ॉर्मेंस के बारे में डेटा इकट्ठा करने के लिए, कुछ अलग-अलग टूल का इस्तेमाल किया जा सकता है. यह इस बात पर निर्भर करता है कि आपको डेटा की कितनी बारीकी से जानकारी चाहिए:
- खास जानकारी: इंडेक्स न की गई क्वेरी की सूची और पढ़ने/लिखने की कार्रवाइयों की रीयल टाइम खास जानकारी पाने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें.
- बिल किए गए इस्तेमाल का अनुमान: बिल किए गए इस्तेमाल और परफ़ॉर्मेंस की खास जानकारी देखने के लिए, Firebase कंसोल में उपलब्ध इस्तेमाल की मेट्रिक का इस्तेमाल करें.
- बारीकी से जानकारी: समय के साथ-साथ, आपके डेटाबेस की परफ़ॉर्मेंस की ज़्यादा विस्तृत जानकारी पाने के लिए, Cloud Monitoring का इस्तेमाल करें.
मेट्रिक के हिसाब से परफ़ॉर्मेंस बेहतर बनाना
डेटा इकट्ठा करने के बाद, परफ़ॉर्मेंस के उस क्षेत्र के हिसाब से यहां दिए गए सबसे सही तरीकों और रणनीतियों को एक्सप्लोर करें जिसे आपको बेहतर बनाना है.
| परफ़ॉर्मेंस बेहतर बनाने की रणनीतियों की खास जानकारी | ||
|---|---|---|
| मेट्रिक | ब्यौरा | सबसे सही तरीके |
| लोड/इस्तेमाल | ऑप्टिमाइज़ करें कि किसी भी समय, अनुरोधों को प्रोसेस करने के लिए आपके डेटाबेस की कितनी क्षमता का इस्तेमाल किया जा रहा है. यह **लोड** या **io/database_load** मेट्रिक में दिखता है. |
अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करें डेटा को अलग-अलग डेटाबेस में बांटें लिसनर की परफ़ॉर्मेंस बेहतर बनाएं क्वेरी पर आधारित नियमों से डाउनलोड सीमित करें कनेक्शन ऑप्टिमाइज़ करें |
| चालू कनेक्शन | एक साथ चालू कनेक्शन की संख्या को 2,00,000 कनेक्शन की सीमा के अंदर रखने के लिए, अपने डेटाबेस से एक साथ चालू कनेक्शन की संख्या को बैलेंस करें. |
डेटा को अलग-अलग डेटाबेस में बांटें नए कनेक्शन कम करें |
| आउटगोइंग बैंडविड्थ | अगर आपके डेटाबेस से डाउनलोड, आपकी उम्मीद से ज़्यादा हो रहे हैं, तो पढ़ने की कार्रवाइयों की परफ़ॉर्मेंस बेहतर बनाई जा सकती है और एन्क्रिप्शन ओवरहेड कम किया जा सकता है. |
कनेक्शन ऑप्टिमाइज़ करें अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करें क्वेरी पर आधारित नियमों से डाउनलोड सीमित करें एसएसएल सेशन का फिर से इस्तेमाल करें लिसनर की परफ़ॉर्मेंस बेहतर बनाएं डेटा के ऐक्सेस पर पाबंदी लगाएं |
| स्टोरेज | पक्का करें कि इस्तेमाल न किया गया डेटा सेव न किया जा रहा हो. साथ ही, कोटे के अंदर रहने के लिए, सेव किए गए डेटा को अन्य डेटाबेस और/या Firebase प्रॉडक्ट में बैलेंस करें. |
इस्तेमाल न किए गए डेटा से स्टोरेज में जगह बनाएं अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करें डेटा को अलग-अलग डेटाबेस में बांटें इस्तेमाल करें Cloud Storage for Firebase |
कनेक्शन ऑप्टिमाइज़ करें
RESTful अनुरोधों जैसे कि GET और PUT के लिए भी कनेक्शन की ज़रूरत होती है. भले ही, यह कनेक्शन कम समय के लिए हो. बार-बार होने वाले ये कम समय के कनेक्शन, आपके डेटाबेस से रीयल टाइम, चालू कनेक्शन की तुलना में, कनेक्शन की लागत, डेटाबेस लोड, और आउटगोइंग बैंडविड्थ को काफ़ी ज़्यादा बढ़ा सकते हैं.
जब भी मुमकिन हो, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म के लिए, नेटिव एसडीके का इस्तेमाल करें. एसडीके, कनेक्शन को चालू रखते हैं. इससे, एसएसएल एन्क्रिप्शन की लागत और डेटाबेस लोड कम होता है. REST API के साथ ये लागतें बढ़ सकती हैं.
अगर REST API का इस्तेमाल किया जाता है, तो चालू कनेक्शन बनाए रखने के लिए, एचटीटीपी कीप-अलाइव का इस्तेमाल करें या सर्वर-सेंट इवेंट का इस्तेमाल करें. इससे, एसएसएल हैंडशेक की लागत कम हो सकती है.
डेटा को अलग-अलग डेटाबेस में बांटना
अपने डेटा को Realtime Database के एक से ज़्यादा इंस्टेंस में बांटने को डेटाबेस शार्डिंग कहा जाता है. इसके तीन फ़ायदे हैं:
- डेटाबेस इंस्टेंस में डेटा बांटकर, अपने ऐप्लिकेशन पर एक साथ चालू कनेक्शन की कुल संख्या बढ़ाएं.
- डेटाबेस इंस्टेंस में लोड को बैलेंस करें.
- अगर आपके पास उपयोगकर्ताओं के ऐसे अलग-अलग ग्रुप हैं जिन्हें सिर्फ़ अलग-अलग डेटा सेट का ऐक्सेस चाहिए, तो ज़्यादा थ्रूपुट और कम समय में डेटा लोड होने के लिए, अलग-अलग डेटाबेस इंस्टेंस का इस्तेमाल करें.
अगर आपके पास Blaze प्लान है, तो एक ही Firebase प्रोजेक्ट में, डेटाबेस के एक से ज़्यादा इंस्टेंस बनाए जा सकते हैं. इसके लिए, डेटाबेस के सभी इंस्टेंस में, उपयोगकर्ता की पुष्टि करने के एक ही तरीके का इस्तेमाल किया जा सकता है.
डेटा को अलग-अलग डेटाबेस में बांटने के तरीके और समय के बारे में ज़्यादा जानें.
डेटा के असरदार स्ट्रक्चर बनाना
चूंकि Realtime Database किसी पाथ के चाइल्ड नोड के साथ-साथ पाथ से भी डेटा लेता है, इसलिए अपने डेटा स्ट्रक्चर को जितना हो सके, फ़्लैट रखें. इससे, क्लाइंट के लिए गैर-ज़रूरी डेटा डाउनलोड किए बिना, सिर्फ़ वह डेटा लिया जा सकता है जिसकी ज़रूरत है.
खास तौर पर, डेटा को स्ट्रक्चर करते समय, लिखने और मिटाने की कार्रवाइयों पर ध्यान दें. उदाहरण के लिए, ऐसे पाथ मिटाने में ज़्यादा लागत लग सकती है जिनमें हज़ारों लीफ़ नोड हों. इन्हें एक से ज़्यादा सबट्री वाले पाथ में बांटने और हर नोड में कम लीफ़ नोड रखने से, मिटाने की प्रोसेस तेज़ हो सकती है.
इसके अलावा, हर लिखने की कार्रवाई में, आपके डेटाबेस के कुल इस्तेमाल का 0.1% लग सकता है.
अपने डेटा को इस तरह से स्ट्रक्चर करें कि एसडीके में मौजूद update() तरीकों या RESTful PATCH अनुरोधों के ज़रिए, एक ही कार्रवाई में कई पाथ अपडेट के तौर पर, बैच में डेटा लिखा जा सके.
अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करने और परफ़ॉर्मेंस बेहतर बनाने के लिए, डेटा स्ट्रक्चर के सबसे सही तरीके अपनाएं.
बिना अनुमति के ऐक्सेस करने से रोकने की सुविधा
अपने डेटाबेस पर बिना अनुमति के की जाने वाली कार्रवाइयों को रोकें Realtime Database Security Rules. उदाहरण के लिए, नियमों का इस्तेमाल करके, ऐसे हालात से बचा जा सकता है जहां कोई दुर्भावनापूर्ण उपयोगकर्ता, बार-बार आपका पूरा डेटाबेस डाउनलोड करता है.
Firebase रीयलटाइम डेटाबेस के नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.
क्वेरी पर आधारित नियमों का इस्तेमाल करके, डाउनलोड सीमित करना
Realtime Database Security Rules आपके डेटाबेस में मौजूद डेटा के ऐक्सेस को सीमित करते हैं. हालांकि, ये पढ़ने की कार्रवाइयों के ज़रिए वापस किए गए डेटा की सीमा के तौर पर भी काम कर सकते हैं.
क्वेरी पर आधारित नियमों का इस्तेमाल करने पर, query. एक्सप्रेशन जैसे कि query.limitToFirst से तय किए गए
क्वेरी सिर्फ़ नियम के तहत आने वाला डेटा लेती हैं.
उदाहरण के लिए, यहां दिया गया नियम, प्राथमिकता के क्रम में, किसी क्वेरी के सिर्फ़ पहले 1,000 नतीजों के लिए, पढ़ने के ऐक्सेस को सीमित करता है:
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
Realtime Database Security Rules के बारे में ज़्यादा जानें.
क्वेरी इंडेक्स करना
अपने डेटा को इंडेक्स करने से, आपके ऐप्लिकेशन की हर क्वेरी के लिए इस्तेमाल की जाने वाली कुल बैंडविड्थ कम हो जाती है.
एसएसएल सेशन का फिर से इस्तेमाल करना
TLS सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन ओवरहेड की लागत कम करें. यह खास तौर पर तब काम आता है, जब आपको डेटाबेस से बार-बार, सुरक्षित कनेक्शन की ज़रूरत होती है.
लिसनर की परफ़ॉर्मेंस बेहतर बनाना
लिसनर को पाथ में जितना हो सके, नीचे की ओर रखें, ताकि वे कम डेटा सिंक करें. आपके लिसनर, उस डेटा के पास होने चाहिए जिसे आपको पाना है. डेटाबेस के रूट पर न सुनें, क्योंकि इससे आपका पूरा डेटाबेस डाउनलोड हो जाता है.
लिसन की कार्रवाइयों से मिलने वाले डेटा को सीमित करने के लिए, क्वेरी जोड़ें. साथ ही, ऐसे
लिसनर का इस्तेमाल करें जो सिर्फ़ डेटा के अपडेट डाउनलोड करते हैं. उदाहरण के लिए, on() के बजाय
once() का इस्तेमाल करें. .once() का इस्तेमाल सिर्फ़ उन कार्रवाइयों के लिए करें जिनके लिए डेटा अपडेट की ज़रूरत नहीं होती.
इसके अलावा, बेहतर परफ़ॉर्मेंस के लिए, जब भी मुमकिन हो, orderByKey() का इस्तेमाल करके अपनी क्वेरी को क्रम में लगाएं. orderByChild() से क्रम में लगाने में 6 से 8 गुना ज़्यादा समय लग सकता है. वहीं, orderByValue() से क्रम में लगाने में, बड़े डेटा सेट के लिए बहुत ज़्यादा समय लग सकता है. ऐसा इसलिए, क्योंकि इसके लिए परसिस्टेंस लेयर से पूरी जगह को पढ़ना पड़ता है.
यह भी पक्का करें कि लिसनर को डाइनैमिक तरीके से जोड़ा जाए और ज़रूरत न होने पर उन्हें हटा दिया जाए.
इस्तेमाल न किए गए डेटा से स्टोरेज में जगह बनाएं
अपने डेटाबेस में मौजूद, इस्तेमाल न किए गए या डुप्लीकेट डेटा को समय-समय पर हटाएं. अपने डेटा की मैन्युअल तरीके से जांच करने के लिए, बैकअप लिए जा सकते हैं. इसके अलावा, Google Cloud Storage बकेट में समय-समय पर डेटा का बैकअप लिया जा सकता है. सेव किए गए डेटा को Cloud Storage for Firebaseके ज़रिए होस्ट करने पर भी विचार करें.
स्केलेबल कोड भेजना जिसे अपडेट किया जा सके
IoT डिवाइस में बने ऐप्लिकेशन में, स्केलेबल कोड शामिल होना चाहिए जिसे आसानी से अपडेट किया जा सके. पक्का करें कि इस्तेमाल के उदाहरणों की अच्छी तरह जांच की गई हो. साथ ही, ऐसे हालात का ध्यान रखा गया हो जिनमें आपका उपयोगकर्ता आधार तेज़ी से बढ़ सकता है. इसके अलावा, अपने कोड में अपडेट डिप्लॉय करने की सुविधा शामिल करें. अगर आपको बाद में बड़े बदलाव करने पड़ सकते हैं, तो इस बारे में ध्यान से सोचें. उदाहरण के लिए, अगर आपको अपने डेटा को अलग-अलग डेटाबेस में बांटना है.