डेटाबेस की परफ़ॉर्मेंस ऑप्टिमाइज़ करें

अपने ऐप्लिकेशन में, Firebase Realtime Database परफ़ॉर्मेंस को बेहतर बनाने के कुछ अलग-अलग तरीके हैं. अपनी Realtime Database परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, अलग-अलग Realtime Database मॉनिटरिंग टूल की मदद से डेटा इकट्ठा करें. इसके बाद, अपने ऐप्लिकेशन या Realtime Database के इस्तेमाल में ज़रूरी बदलाव करें.

Realtime Database की परफ़ॉर्मेंस को मॉनिटर करना

अपने Realtime Database's की परफ़ॉर्मेंस के बारे में डेटा इकट्ठा करने के लिए, कुछ अलग-अलग टूल का इस्तेमाल किया जा सकता है. यह इस बात पर निर्भर करता है कि आपको डेटा की कितनी बारीकी से जानकारी चाहिए:

• खास जानकारी: इंडेक्स न की गई क्वेरी की सूची और पढ़ने/लिखने की कार्रवाइयों की रीयल टाइम में खास जानकारी पाने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें.
• बिल किए गए इस्तेमाल का अनुमान: बिल किए गए इस्तेमाल और परफ़ॉर्मेंस की खास जानकारी देखने के लिए, Firebase कंसोल में उपलब्ध इस्तेमाल की मेट्रिक का इस्तेमाल करें.
• बारीकी से जानकारी: समय के साथ-साथ आपके डेटाबेस की परफ़ॉर्मेंस की ज़्यादा बारीकी से जानकारी पाने के लिए, Cloud Monitoring का इस्तेमाल करें.

मेट्रिक के हिसाब से परफ़ॉर्मेंस बेहतर बनाना

डेटा इकट्ठा करने के बाद, परफ़ॉर्मेंस के उस क्षेत्र के आधार पर, सबसे सही तरीकों और रणनीतियों के बारे में जानें जिसे आपको बेहतर बनाना है.

कनेक्शन ऑप्टिमाइज़ करना

GET और PUT जैसे RESTful अनुरोधों के लिए अब भी कनेक्शन की ज़रूरत होती है. भले ही, यह कनेक्शन कुछ समय के लिए ही हो. बार-बार होने वाले ये कनेक्शन, आपके डेटाबेस से रीयल टाइम में चालू कनेक्शन की तुलना में, कनेक्शन की लागत, डेटाबेस लोड, और आउटगोइंग बैंडविड्थ को काफ़ी बढ़ा सकते हैं.

जहां तक हो सके, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म के लिए, नेटिव एसडीके का इस्तेमाल करें. एसडीके, कनेक्शन को चालू रखते हैं. इससे, एसएसएल एन्क्रिप्शन की लागत और डेटाबेस लोड कम होता है. REST API के साथ ऐसा नहीं होता.

अगर REST API का इस्तेमाल किया जाता है, तो चालू कनेक्शन बनाए रखने के लिए, HTTP कीप-अलाइव का इस्तेमाल करें या सर्वर-सेंट इवेंटका इस्तेमाल करें. इससे, एसएसएल हैंडशेक की लागत कम हो सकती है.

डेटा को अलग-अलग डेटाबेस में बांटना

अपने डेटा को Realtime Database के एक से ज़्यादा इंस्टेंस में बांटने को डेटाबेस शार्डिंग कहा जाता है. इसके तीन फ़ायदे हैं:

1. डेटाबेस इंस्टेंस में डेटा बांटकर, अपने ऐप्लिकेशन पर एक साथ चालू कनेक्शन की कुल संख्या बढ़ाएं.
2. डेटाबेस इंस्टेंस में लोड को बैलेंस करें.
3. अगर आपके पास उपयोगकर्ताओं के ऐसे अलग-अलग ग्रुप हैं जिन्हें सिर्फ़ अलग-अलग डेटा सेट का ऐक्सेस चाहिए, तो ज़्यादा थ्रूपुट और कम लेटेंसी के लिए, अलग-अलग डेटाबेस इंस्टेंस का इस्तेमाल करें.

अगर आपके पास Blaze प्लान है, तो एक ही Firebase प्रोजेक्ट में, Realtime Database के एक से ज़्यादा इंस्टेंस बनाए जा सकते हैं. इसके लिए, सभी डेटाबेस इंस्टेंस में उपयोगकर्ता की पुष्टि करने के एक ही तरीके का इस्तेमाल किया जा सकता है.

डेटा को अलग-अलग डेटाबेस में बांटने के तरीके और समय के बारे में ज़्यादा जानें.

डेटा के असरदार स्ट्रक्चर बनाना

चूंकि 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 सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन ओवरहेड की लागत कम करें. यह खास तौर पर तब काम आता है, जब आपको डेटाबेस से बार-बार सुरक्षित कनेक्शन की ज़रूरत होती है.

लिसनर की परफ़ॉर्मेंस बेहतर बनाना

लिसनर को पाथ में जितना हो सके, नीचे की ओर रखें, ताकि वे कम डेटा सिंक करें. आपके लिसनर, उस डेटा के पास होने चाहिए जिसे आपको लेना है. डेटाबेस के रूट पर न सुनें, क्योंकि इससे आपका पूरा डेटाबेस डाउनलोड हो जाता है.

लिसन की कार्रवाइयों से मिलने वाले डेटा को सीमित करने के लिए, क्वेरी जोड़ें. साथ ही, ऐसे लिसनर का इस्तेमाल करें जो सिर्फ़ डेटा के अपडेट डाउनलोड करते हैं. उदाहरण के लिए, on() के बजाय once() का इस्तेमाल करें. .once() का इस्तेमाल सिर्फ़ उन कार्रवाइयों के लिए करें जिनमें डेटा अपडेट की ज़रूरत नहीं होती. इसके अलावा, बेहतर परफ़ॉर्मेंस के लिए, जहां तक हो सके, orderByKey() का इस्तेमाल करके अपनी क्वेरी को क्रम में लगाएं. orderByChild() से क्रम में लगाने में 6 से 8 गुना ज़्यादा समय लग सकता है. वहीं, orderByValue() से क्रम में लगाने में, बड़े डेटा सेट के लिए बहुत ज़्यादा समय लग सकता है, क्योंकि इसके लिए परसिस्टेंस लेयर से पूरी जगह को पढ़ना पड़ता है.

यह भी पक्का करें कि लिसनर को डाइनैमिक तरीके से जोड़ा जाए और ज़रूरत न होने पर उन्हें हटाया जाए.

इस्तेमाल न किया गया डेटा हटाएं

अपने डेटाबेस में मौजूद, इस्तेमाल न किए गए या डुप्लीकेट डेटा को समय-समय पर हटाएं. अपने डेटा की मैन्युअल तरीके से जांच करने के लिए, बैकअप लिए जा सकते हैं. इसके अलावा, Google Cloud Storage बकेट में समय-समय पर डेटा का बैकअप लिया जा सकता है. सेव किए गए डेटा को Cloud Storage for Firebaseके ज़रिए होस्ट करने पर भी विचार करें.

स्केलेबल कोड शिप करना जिसे अपडेट किया जा सके

IoT डिवाइस में बने ऐप्लिकेशन में, स्केलेबल कोड शामिल होना चाहिए जिसे आसानी से अपडेट किया जा सके. पक्का करें कि इस्तेमाल के उदाहरणों की अच्छी तरह जांच की गई हो. साथ ही, ऐसे हालात का ध्यान रखा गया हो जिनमें आपके उपयोगकर्ता आधार में तेज़ी से बढ़ोतरी हो सकती है. इसके अलावा, अपने कोड में अपडेट डिप्लॉय करने की सुविधा शामिल करें. अगर आपको बाद में बड़े बदलाव करने पड़ सकते हैं, तो इस बारे में ध्यान से सोचें. उदाहरण के लिए, अगर आपको अपने डेटा को अलग-अलग डेटाबेस में बांटना है.