अपने ऐप्लिकेशन की Firebase Realtime Database परफ़ॉर्मेंस को बेहतर बनाने के लिए, कई तरीके अपनाए जा सकते हैं. अपनी Realtime Database परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, अलग-अलग Realtime Database मॉनिटरिंग टूल से डेटा इकट्ठा करें. इसके बाद, अपने ऐप्लिकेशन में बदलाव करें या Realtime Database का इस्तेमाल करें.
Realtime Database की परफ़ॉर्मेंस मॉनिटर करना
आपको जिस लेवल की जानकारी चाहिए उसके हिसाब से, Realtime Database की परफ़ॉर्मेंस के बारे में डेटा इकट्ठा करने के लिए, कुछ अलग-अलग टूल इस्तेमाल किए जा सकते हैं:
- खास जानकारी: इंडेक्स नहीं की गई क्वेरी की सूची और पढ़ने/लिखने की कार्रवाइयों की रीयलटाइम खास जानकारी के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें.
- बिल किए गए इस्तेमाल का अनुमान: बिल किए गए इस्तेमाल और परफ़ॉर्मेंस मेट्रिक देखने के लिए, Firebase कंसोल में उपलब्ध इस्तेमाल की मेट्रिक का इस्तेमाल करें.
- ज़्यादा जानकारी वाला ड्रिल-डाउन: Cloud Monitoring का इस्तेमाल करके, यह देखा जा सकता है कि समय के साथ आपका डेटाबेस कैसा परफ़ॉर्म कर रहा है.
मेट्रिक के हिसाब से परफ़ॉर्मेंस को बेहतर बनाना
डेटा इकट्ठा करने के बाद, यहां दिए गए सबसे सही तरीकों और रणनीतियों को अपनाएं. ये रणनीतियां, परफ़ॉर्मेंस के उस क्षेत्र पर आधारित हैं जिसमें आपको सुधार करना है.
| एक नज़र में परफ़ॉर्मेंस को बेहतर बनाने की रणनीतियां | ||
|---|---|---|
| मेट्रिक | ब्यौरा | सबसे सही तरीके |
| लोड/इस्तेमाल | यह ऑप्टिमाइज़ करें कि किसी भी समय अनुरोधों को प्रोसेस करने के लिए, आपके डेटाबेस की कितनी क्षमता का इस्तेमाल किया जा रहा है. यह **लोड** या **io/database_load** मेट्रिक में दिखता है. |
अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करें डेटा को अलग-अलग डेटाबेस में बांटें लिसनर की परफ़ॉर्मेंस को बेहतर बनाएं क्वेरी पर आधारित नियमों की मदद से, डाउनलोड की संख्या सीमित करें कनेक्शन ऑप्टिमाइज़ करें |
| चालू कनेक्शन | अपने डेटाबेस से एक साथ चालू कनेक्शन की संख्या को इस तरह से मैनेज करें कि यह 2, 00,000 कनेक्शन की सीमा से ज़्यादा न हो. |
डेटा को कई डेटाबेस में बांटना नए कनेक्शन कम करना |
| आउटगोइंग बैंडविथ | अगर आपको लगता है कि आपके डेटाबेस से डाउनलोड किए गए डेटा की संख्या आपकी ज़रूरत से ज़्यादा है, तो पढ़ने की कार्रवाइयों को ज़्यादा असरदार बनाया जा सकता है. साथ ही, एन्क्रिप्शन के ओवरहेड को कम किया जा सकता है. |
कनेक्शन ऑप्टिमाइज़ करना अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करना क्वेरी पर आधारित नियमों की मदद से, डाउनलोड की संख्या सीमित करना एसएसएल सेशन का दोबारा इस्तेमाल करना लिसनर की परफ़ॉर्मेंस बेहतर बनाना डेटा का ऐक्सेस सीमित करना |
| स्टोरेज | पक्का करें कि आपने ऐसे डेटा को सेव न किया हो जिसका इस्तेमाल नहीं किया जा रहा है. इसके अलावा, अपने सेव किए गए डेटा को अन्य डेटाबेस और/या Firebase प्रॉडक्ट में इस तरह से बाँटें कि वह कोटे के अंदर रहे. |
इस्तेमाल न किए गए डेटा को हटाना डेटा स्ट्रक्चर को ऑप्टिमाइज़ करना डेटा को अलग-अलग डेटाबेस में बांटना Cloud Storage for Firebase का इस्तेमाल करना |
कनेक्शन ऑप्टिमाइज़ करना
GET और PUT जैसे RESTful अनुरोधों के लिए अब भी कनेक्शन की ज़रूरत होती है. भले ही, यह कनेक्शन कम समय के लिए हो. बार-बार और कम समय के लिए होने वाले ये कनेक्शन, आपके डेटाबेस से रीयलटाइम में चालू कनेक्शन की तुलना में, कनेक्शन की लागत, डेटाबेस लोड, और आउटगोइंग बैंडविथ को काफ़ी हद तक बढ़ा सकते हैं.
जब भी मुमकिन हो, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म के लिए नेटिव SDK टूल का इस्तेमाल करें. एसडीके, ओपन कनेक्शन बनाए रखते हैं. इससे एसएसएल एन्क्रिप्शन की लागत कम हो जाती है. साथ ही, डेटाबेस का लोड भी कम हो जाता है. ऐसा इसलिए, क्योंकि REST API के साथ ऐसा नहीं होता.
अगर REST API का इस्तेमाल किया जाता है, तो खुले कनेक्शन को बनाए रखने के लिए, एचटीटीपी कीप-अलाइव का इस्तेमाल करें. इसके अलावा, सर्वर-सेंट इवेंट का इस्तेमाल करें. इससे एसएसएल हैंडशेक की लागत कम हो सकती है.
डेटा को कई डेटाबेस में बांटना
अपने डेटा को कई Realtime Database इंस्टेंस में बांटने से, आपको तीन फ़ायदे मिलते हैं. इसे डेटाबेस शार्डिंग भी कहा जाता है:
- डेटाबेस इंस्टेंस के बीच कनेक्शन बांटकर, अपने ऐप्लिकेशन पर एक साथ चालू कनेक्शन की कुल संख्या बढ़ाएं.
- डेटाबेस इंस्टेंस में लोड को बैलेंस करें.
- अगर आपके पास उपयोगकर्ताओं के ऐसे ग्रुप हैं जिन्हें सिर्फ़ अलग-अलग डेटा सेट का ऐक्सेस चाहिए, तो ज़्यादा थ्रूपुट और कम लेटेन्सी के लिए, अलग-अलग डेटाबेस इंस्टेंस का इस्तेमाल करें.
अगर आपने ब्लेज़ प्लान चुना है, तो एक ही Firebase प्रोजेक्ट में कई डेटाबेस इंस्टेंस बनाए जा सकते हैं. साथ ही, डेटाबेस के सभी इंस्टेंस के लिए, उपयोगकर्ता की पुष्टि करने के एक ही तरीके का इस्तेमाल किया जा सकता है.
डेटा को शार्ड करने के तरीके और समय के बारे में ज़्यादा जानें.
डेटा के बेहतर स्ट्रक्चर बनाना
Realtime Database, पाथ के साथ-साथ पाथ के चाइल्ड नोड से भी डेटा वापस लाता है. इसलिए, अपने डेटा स्ट्रक्चर को जितना हो सके उतना आसान रखें. इस तरह, आपको सिर्फ़ वह डेटा मिलता है जिसकी आपको ज़रूरत है. साथ ही, क्लाइंट को गैर-ज़रूरी डेटा डाउनलोड करने की ज़रूरत नहीं पड़ती.
खास तौर पर, डेटा को व्यवस्थित करते समय, लिखने और मिटाने की कार्रवाइयों पर ध्यान दें. उदाहरण के लिए, हज़ारों पत्तियों वाले पाथ को मिटाने में ज़्यादा समय लग सकता है. उन्हें कई सबट्री और हर नोड में कम लीफ़ वाले पाथ में बांटने से, उन्हें तेज़ी से मिटाया जा सकता है.
इसके अलावा, हर राइट ऑपरेशन में आपके डेटाबेस के कुल इस्तेमाल का 0.1% हिस्सा लग सकता है.
अपने डेटा को इस तरह से स्ट्रक्चर करें कि एक ही ऑपरेशन में कई बार लिखने की अनुमति हो. इसके लिए, एसडीके में मौजूद update() तरीकों या RESTful PATCH अनुरोधों के ज़रिए, मल्टी-पाथ अपडेट का इस्तेमाल करें.
अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करने और परफ़ॉर्मेंस को बेहतर बनाने के लिए, डेटा स्ट्रक्चर के लिए सबसे सही तरीके अपनाएं.
बिना अनुमति के ऐक्सेस को रोकना
Realtime Database Security Rules की मदद से, अपने डेटाबेस पर बिना अनुमति के होने वाली कार्रवाइयों को रोकें. उदाहरण के लिए, नियमों का इस्तेमाल करके ऐसे हालात से बचा जा सकता है जहां कोई दुर्भावनापूर्ण उपयोगकर्ता बार-बार आपका पूरा डेटाबेस डाउनलोड करता है.
Firebase Realtime Database के नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.
डाउनलोड सीमित करने के लिए, क्वेरी पर आधारित नियमों का इस्तेमाल करना
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 सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन की ओवरहेड लागत कम करें. यह खास तौर पर तब फ़ायदेमंद होता है, जब आपको डेटाबेस से बार-बार सुरक्षित कनेक्शन की ज़रूरत होती है.
पॉडकास्ट सुनने वालों की संख्या बढ़ाना
अपने लिसनर को पाथ में सबसे नीचे रखें, ताकि वे कम से कम डेटा सिंक कर सकें. आपके श्रोता, उस डेटा के आस-पास होने चाहिए जिसे आपको उन्हें दिखाना है. डेटाबेस के रूट पर न सुनें, क्योंकि इससे आपका पूरा डेटाबेस डाउनलोड हो जाता है.
क्वेरी जोड़कर, उस डेटा को सीमित करें जिसे सुनने की कार्रवाइयां वापस लाती हैं. साथ ही, ऐसे लिसनर का इस्तेमाल करें जो सिर्फ़ डेटा के अपडेट डाउनलोड करते हैं. उदाहरण के लिए, once() के बजाय on() का इस्तेमाल करें. .once() को उन कार्रवाइयों के लिए रिज़र्व करें जिनके लिए डेटा अपडेट की ज़रूरत नहीं होती.
इसके अलावा, बेहतर परफ़ॉर्मेंस के लिए, जब भी हो सके अपनी क्वेरी को orderByKey() का इस्तेमाल करके क्रम से लगाएं. orderByChild() का इस्तेमाल करके सॉर्ट करने में, orderByValue() का इस्तेमाल करके सॉर्ट करने की तुलना में छह से आठ गुना ज़्यादा समय लग सकता है. साथ ही, बड़े डेटा सेट के लिए orderByValue() का इस्तेमाल करके सॉर्ट करने में बहुत ज़्यादा समय लग सकता है. ऐसा इसलिए, क्योंकि इसके लिए परसिस्टेंस लेयर से पूरी जगह की जानकारी को पढ़ना पड़ता है.
यह भी पक्का करें कि लिसनर को डाइनैमिक तरीके से जोड़ा जाए और जब उनकी ज़रूरत न हो, तो उन्हें हटा दिया जाए.
इस्तेमाल नहीं किए जा रहे डेटा को मिटाना
अपने डेटाबेस में मौजूद ऐसे डेटा को समय-समय पर हटाएं जिसका इस्तेमाल नहीं किया जा रहा है या जो डुप्लीकेट है. अपने डेटा की मैन्युअल तरीके से जांच करने के लिए, बैकअप लिए जा सकते हैं. इसके अलावा, समय-समय पर Google Cloud Storage बकेट में डेटा का बैकअप लिया जा सकता है. इसके अलावा, Cloud Storage for Firebase के ज़रिए स्टोर किए गए डेटा को होस्ट करने पर भी विचार करें.
स्केल किए जा सकने वाले ऐसे कोड को शिप करें जिसे अपडेट किया जा सकता है
IoT डिवाइसों में पहले से मौजूद ऐप्लिकेशन में ऐसा कोड शामिल होना चाहिए जिसे आसानी से अपडेट किया जा सके. पक्का करें कि इस्तेमाल के उदाहरणों की अच्छी तरह से जांच की गई हो. साथ ही, उन स्थितियों को ध्यान में रखा गया हो जिनमें आपके उपयोगकर्ता आधार में तेज़ी से बढ़ोतरी हो सकती है. इसके अलावा, अपने कोड में अपडेट डिप्लॉय करने की सुविधा भी शामिल करें. अगर आपको बाद में कोई बड़ा बदलाव करना है, तो उसके बारे में पहले से सोच लें. उदाहरण के लिए, अगर आपको अपने डेटा को शार्ड करना है, तो इसके बारे में पहले से सोच लें.