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