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

अपने ऐप्लिकेशन की 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 इंस्टेंस में बांटने से, डेटाबेस को अलग-अलग हिस्सों में बांटने के नाम से भी जाना जाता है. इससे तीन फ़ायदे मिलते हैं:

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

अगर आपने 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 के ज़रिए सेव किए गए डेटा को होस्ट करें.

स्केल किए जा सकने वाले कोड को शिप करें, जिसे अपडेट किया जा सकता है

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