अपने ऐप्लिकेशन में, 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 |
कनेक्शन ऑप्टिमाइज़ करना
GET और PUT जैसे RESTful अनुरोधों के लिए भी कनेक्शन की ज़रूरत होती है. भले ही, यह कनेक्शन कम समय के लिए हो. बार-बार होने वाले ये कम समय के कनेक्शन, आपके डेटाबेस से रीयल टाइम, चालू कनेक्शन की तुलना में, कनेक्शन की लागत, डेटाबेस लोड, और आउटगोइंग बैंडविड्थ को काफ़ी बढ़ा सकते हैं.
जहां तक हो सके, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म के लिए, नेटिव एसडीके का इस्तेमाल करें. एसडीके, कनेक्शन को चालू रखते हैं. इससे, एसएसएल एन्क्रिप्शन की लागत और डेटाबेस लोड कम होता है. REST API के साथ ये लागतें बढ़ सकती हैं.
अगर REST API का इस्तेमाल किया जाता है, तो चालू कनेक्शन बनाए रखने के लिए, एचटीटीपी कीप-अलाइव का इस्तेमाल करें. इसके अलावा, सर्वर-सेंट इवेंट का इस्तेमाल किया जा सकता है. इससे, एसएसएल हैंडशेक की लागत कम हो सकती है.
डेटा को अलग-अलग डेटाबेस में बांटना
अपने डेटा को Realtime Database के एक से ज़्यादा इंस्टेंस में बांटने को डेटाबेस शार्डिंग कहा जाता है. इसके तीन फ़ायदे हैं:
- डेटाबेस इंस्टेंस में डेटा बांटकर, अपने ऐप्लिकेशन पर एक साथ चालू कनेक्शन की कुल संख्या बढ़ाना.
- डेटाबेस इंस्टेंस में लोड को बैलेंस करना.
- अगर आपके पास उपयोगकर्ताओं के ऐसे अलग-अलग ग्रुप हैं जिन्हें सिर्फ़ अलग-अलग डेटा सेट का ऐक्सेस चाहिए, तो ज़्यादा थ्रूपुट और कम समय में डेटा पाने के लिए, अलग-अलग डेटाबेस इंस्टेंस का इस्तेमाल करें.
अगर आपके पास Blaze प्लान है, तो एक ही Firebase प्रोजेक्ट में, Realtime Database के एक से ज़्यादा इंस्टेंस बनाए जा सकते हैं. साथ ही, डेटाबेस इंस्टेंस में उपयोगकर्ता की पुष्टि करने के एक ही तरीके का इस्तेमाल किया जा सकता है.
डेटा को अलग-अलग डेटाबेस में बांटने के तरीके और समय के बारे में ज़्यादा जानें.
डेटा के लिए असरदार स्ट्रक्चर बनाना
चूंकि Realtime Database किसी पाथ के चाइल्ड नोड के साथ-साथ पाथ से भी डेटा लेता है, इसलिए अपने डेटा स्ट्रक्चर को जितना हो सके, फ़्लैट रखना बेहतर है. इससे, क्लाइंट के लिए गैर-ज़रूरी डेटा डाउनलोड किए बिना, सिर्फ़ वह डेटा लिया जा सकता है जिसकी ज़रूरत है.
खास तौर पर, डेटा को स्ट्रक्चर करते समय, लिखने और मिटाने की कार्रवाइयों पर ध्यान दें. उदाहरण के लिए, ऐसे पाथ मिटाने में ज़्यादा लागत लग सकती है जिनमें हज़ारों लीफ़ नोड हों. इन्हें एक से ज़्यादा सबट्री वाले पाथ में बांटने और हर नोड के लिए कम लीफ़ नोड रखने से, मिटाने की प्रोसेस तेज़ हो सकती है.
इसके अलावा, हर लिखने की कार्रवाई में, आपके डेटाबेस के कुल इस्तेमाल का 0.1% लग सकता है.
अपने डेटा को इस तरह से स्ट्रक्चर करें कि एसडीके में update() तरीकों या RESTful PATCH अनुरोधों के ज़रिए, एक ही कार्रवाई में कई पाथ अपडेट के तौर पर, बैच में डेटा लिखा जा सके.
अपने डेटा स्ट्रक्चर को ऑप्टिमाइज़ करने और परफ़ॉर्मेंस बेहतर बनाने के लिए, डेटा स्ट्रक्चर के सबसे सही तरीके अपनाएं.
बिना अनुमति के ऐक्सेस करने से रोकने की सुविधा
अपने डेटाबेस पर बिना अनुमति के होने वाली कार्रवाइयों को रोकें Realtime Database Security Rules. उदाहरण के लिए, नियमों का इस्तेमाल करके, ऐसे हालात से बचा जा सकता है जहां कोई गलत इरादे वाला उपयोगकर्ता, बार-बार आपका पूरा डेटाबेस डाउनलोड करता है.
Firebase Realtime Database के नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.
क्वेरी पर आधारित नियमों का इस्तेमाल करके, डाउनलोड सीमित करना
Realtime Database Security Rules आपके डेटाबेस में मौजूद डेटा के ऐक्सेस को सीमित करते हैं. हालांकि, ये पढ़ने की कार्रवाइयों के ज़रिए वापस किए गए डेटा की सीमा के तौर पर भी काम कर सकते हैं.
क्वेरी पर आधारित नियमों का इस्तेमाल करने पर, क्वेरी सिर्फ़ नियम के तहत आने वाला डेटा लेती हैं. जैसे, query.limitToFirst एक्सप्रेशन से तय किए गए, query..
उदाहरण के लिए, यहां दिया गया नियम, प्राथमिकता के हिसाब से क्रम में लगाई गई क्वेरी के सिर्फ़ पहले 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 डिवाइस में बने ऐप्लिकेशन में, स्केलेबल कोड शामिल होना चाहिए जिसे आसानी से अपडेट किया जा सके. पक्का करें कि इस्तेमाल के उदाहरणों की अच्छी तरह जांच की जाए. साथ ही, ऐसे हालात का ध्यान रखा जाए जहां आपके उपयोगकर्ता आधार में तेज़ी से बढ़ोतरी हो सकती है. इसके अलावा, अपने कोड में अपडेट डिप्लॉय करने की सुविधा शामिल करें. अगर आपको बाद में बड़े बदलाव करने पड़ सकते हैं, तो इस बारे में ध्यान से सोचें. उदाहरण के लिए, अगर आपको अपने डेटा को अलग-अलग डेटाबेस में बांटना है.