अपने ऐप्लिकेशन में 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 टूल का इस्तेमाल करें. SDK टूल, कनेक्शन को खुला रखते हैं. इससे एसएसएल एन्क्रिप्शन की लागत और डेटाबेस का लोड कम होता है. यह लोड, REST API के साथ बढ़ सकता है.
अगर REST API का इस्तेमाल किया जाता है, तो कनेक्शन को खुला रखने के लिए एचटीटीपी कीप-अलाइव का इस्तेमाल करें या सर्वर से भेजे गए इवेंट का इस्तेमाल करें. इससे एसएसएल हैंडशेक की लागत कम हो सकती है.
कई डेटाबेस में डेटा को शार्ड करना
अपने डेटा को कई Realtime Database इंस्टेंस में बांटने से तीन फ़ायदे मिलते हैं. इसे डेटाबेस शार्डिंग भी कहा जाता है:
- डेटाबेस इंस्टेंस में बांटकर, अपने ऐप्लिकेशन पर एक साथ इस्तेमाल किए जा सकने वाले ऐक्टिव कनेक्शन की कुल संख्या बढ़ाएं.
- डेटाबेस इंस्टेंस के बीच बैलेंस लोड.
- अगर आपके पास उपयोगकर्ताओं के ऐसे अलग-अलग ग्रुप हैं जिन्हें सिर्फ़ अलग-अलग डेटा सेट का ऐक्सेस चाहिए, तो ज़्यादा थ्रूपुट और कम इंतज़ार के समय के लिए, अलग-अलग डेटाबेस इंस्टेंस का इस्तेमाल करें.
अगर आपने ब्लेज़ प्लान लिया है, तो एक ही 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 के बारे में और जानें.
इंडेक्स क्वेरी
अपने डेटा को इंडेक्स करने से, आपके ऐप्लिकेशन की हर क्वेरी के लिए इस्तेमाल होने वाला कुल बैंडविड्थ कम हो जाता है.
एसएसएल सेशन फिर से इस्तेमाल करना
टीएलएस सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन ओवरहेड की लागत कम करें. यह तरीका तब ज़्यादा मददगार होता है, जब आपको डेटाबेस से बार-बार और सुरक्षित कनेक्शन की ज़रूरत होती है.
लिसनर की परफ़ॉर्मेंस को बेहतर बनाना
अपने लिसनर को पाथ में जितना हो सके उतना नीचे रखें, ताकि वे कम से कम डेटा सिंक करें. आपके लिसनर, उस डेटा के करीब होने चाहिए जिसे आपको उन्हें देना है. डेटाबेस रूट पर न सुनें, क्योंकि इससे आपका पूरा डेटाबेस डाउनलोड हो जाता है.
क्वेरी जोड़ें, ताकि आपके लिसन ऑपरेशन से मिलने वाले डेटा को सीमित किया जा सके. साथ ही, ऐसे लिसनर इस्तेमाल करें जो सिर्फ़ डेटा के अपडेट डाउनलोड करते हैं. उदाहरण के लिए, once() के बजाय on(). .once() को उन कार्रवाइयों के लिए रिज़र्व करें जिनमें डेटा अपडेट करने की ज़रूरत नहीं होती.
इसके अलावा, बेहतर परफ़ॉर्मेंस के लिए, जब भी संभव हो, orderByKey() का इस्तेमाल करके अपनी क्वेरी को क्रम से लगाएं. orderByChild() का इस्तेमाल करके डेटा को क्रम से लगाने में, 6 से 8 गुना ज़्यादा समय लग सकता है. साथ ही, बड़े डेटा सेट के लिए orderByValue() का इस्तेमाल करके डेटा को क्रम से लगाने में काफ़ी समय लग सकता है. ऐसा इसलिए, क्योंकि इसके लिए पर्सिस्टेंस लेयर से पूरी जगह को रीड करना पड़ता है.
लिसनर को डाइनैमिक तौर पर जोड़ें और ज़रूरत न होने पर उन्हें हटा दें.
इस्तेमाल नहीं किए जा रहे डेटा को मिटाना
अपने डेटाबेस से, इस्तेमाल न किए गए या डुप्लीकेट डेटा को समय-समय पर हटाएं. अपने डेटा की मैन्युअल तरीके से जांच करने के लिए, बैकअप चलाए जा सकते हैं. इसके अलावा, समय-समय पर Google Cloud Storage बकेट में डेटा का बैकअप लिया जा सकता है. स्टोर किए गए डेटा को Cloud Storage for Firebase की मदद से होस्ट करने के बारे में भी सोचें.
ऐसा कोड शिप करें जिसे ज़रूरत के हिसाब से बढ़ाया जा सके और अपडेट किया जा सके
आईओटी डिवाइसों में पहले से मौजूद ऐप्लिकेशन में, ऐसा कोड शामिल होना चाहिए जिसे आसानी से अपडेट किया जा सके. इस्तेमाल के उदाहरणों की अच्छी तरह से जांच करें. साथ ही, उन स्थितियों को ध्यान में रखें जिनमें आपके उपयोगकर्ता आधार में तेज़ी से बढ़ोतरी हो सकती है. इसके अलावा, अपने कोड में अपडेट डिप्लॉय करने की सुविधा भी बनाएं. अगर आपको बाद में कोई बड़ा बदलाव करना पड़े, तो उसके बारे में ध्यान से सोचें. उदाहरण के लिए, अगर आपको अपने डेटा को शार्ड करना है, तो उसके बारे में ध्यान से सोचें.