रीयलटाइम डेटाबेस की बिलिंग के बारे में जानकारी

अगर आपका प्रोजेक्ट बिना किसी शुल्क वाले स्पार्क प्लान पर है, तो आपसे Realtime Database के इस्तेमाल का शुल्क नहीं लिया जाएगा. आपको बिना किसी शुल्क के इस्तेमाल करने की सुविधा मिलती है. इसमें 1 जीबी डेटा स्टोरेज और हर महीने 10 जीबी डेटा डाउनलोड करने की सुविधा शामिल है.

इस्तेमाल के हिसाब से पैसे चुकाने वाले ब्लेज़ प्लान पर अपग्रेड करने पर, आपको बिना किसी शुल्क के इस्तेमाल करने की सुविधा मिलती है. इसमें 1 जीबी डेटा स्टोरेज और हर महीने 10 जीबी डेटा डाउनलोड करने की सुविधा शामिल है. इसके बाद, इस्तेमाल किए गए डेटा के लिए आपसे शुल्क लिया जाता है. अगर आपका प्रोजेक्ट, ब्लेज़ प्राइसिंग प्लान पर है, तो हमारा सुझाव है कि आप अपने प्रोजेक्ट के लिए बजट से जुड़ी सूचनाएं सेट अप करें.

इस पेज के बाकी हिस्से में, बिलिंग के बारे में ज़्यादा जानकारी दी गई है.

Realtime Database बिलिंग का हिसाब कैसे लगाता है

Firebase, आपके डेटाबेस में सेव किए गए डेटा और ओएसआई मॉडल की सेशन लेयर (लेयर 5) पर होने वाले सभी आउटबाउंड नेटवर्क ट्रैफ़िक के लिए बिल भेजता है. स्टोरेज के लिए, हर महीने हर जीबी के हिसाब से पांच डॉलर का शुल्क लिया जाता है. इसका आकलन हर दिन किया जाता है. आपके डेटाबेस की जगह की वजह से, बिलिंग पर कोई असर नहीं पड़ता. आउटबाउंड ट्रैफ़िक में, डेटाबेस की सभी कार्रवाइयों और डेटाबेस से पढ़े गए डेटा को डाउनलोड करने से जुड़ा कनेक्शन और एन्क्रिप्शन ओवरहेड शामिल होता है. डेटाबेस से डेटा पढ़ने और लिखने, दोनों से आपके बिल में कनेक्शन के लिए शुल्क लग सकता है. आपके डेटाबेस से आने-जाने वाले सभी ट्रैफ़िक के लिए बिलिंग की जाती है. इसमें सुरक्षा नियमों के उल्लंघन की वजह से अस्वीकार की गई कार्रवाइयां भी शामिल हैं.

बिल किया गया ट्रैफ़िक, इन वजहों से जनरेट हो सकता है:

• डाउनलोड किया गया डेटा: जब क्लाइंट आपके डेटाबेस से डेटा पाते हैं, तो Firebase डाउनलोड किए गए डेटा के लिए शुल्क लेता है. आम तौर पर, इससे आपके बैंडविथ के ज़्यादातर खर्च का पता चलता है. हालांकि, यह आपके बिल में शामिल होने वाला एकमात्र फ़ैक्टर नहीं है.
• प्रोटोकॉल ओवरहेड: सेशन को चालू रखने के लिए, सर्वर और क्लाइंट के बीच कुछ अतिरिक्त ट्रैफ़िक ज़रूरी होता है. नीचे दिए गए प्रोटोकॉल के आधार पर, इस ट्रैफ़िक में ये शामिल हो सकते हैं: Firebase रीयलटाइम डेटाबेस के रीयलटाइम प्रोटोकॉल का ओवरहेड, WebSocket का ओवरहेड, और एचटीटीपी हेडर का ओवरहेड. हर बार कनेक्शन स्थापित होने पर, यह ओवरहेड, एसएसएल एन्क्रिप्शन के ओवरहेड के साथ मिलकर, कनेक्शन की लागत में योगदान देता है. हालांकि, एक अनुरोध के लिए यह बहुत ज़्यादा बैंडविथ नहीं है. अगर आपके पेलोड छोटे हैं या बार-बार छोटे कनेक्शन किए जाते हैं, तो यह आपके बिल का एक बड़ा हिस्सा हो सकता है.
• एसएसएल एन्क्रिप्शन ओवरहेड: सुरक्षित कनेक्शन के लिए ज़रूरी एसएसएल एन्क्रिप्शन ओवरहेड से जुड़ी लागत होती है. औसतन, शुरुआती हैंडशेक के लिए यह लागत करीब 3.5 केबी होती है. साथ ही, हर जाने वाले मैसेज पर टीएलएस रिकॉर्ड हेडर के लिए करीब 10 बाइट होती है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा हिस्सा होता है. हालांकि, अगर आपके मामले में बहुत ज़्यादा एसएसएल हैंडशेक की ज़रूरत होती है, तो यह प्रतिशत ज़्यादा हो सकता है. उदाहरण के लिए, जिन डिवाइसों पर TLS सेशन टिकट काम नहीं करते उन्हें एसएसएल कनेक्शन हैंडशेक की ज़्यादा ज़रूरत पड़ सकती है.
• Firebase कंसोल का डेटा: आम तौर पर, यह Realtime Database की लागत का अहम हिस्सा नहीं होता. हालांकि, Firebase, Firebase कंसोल से पढ़े और लिखे गए डेटा के लिए शुल्क लेता है.

बिल किए गए इस्तेमाल का अनुमान लगाना

अपने मौजूदा Realtime Database कनेक्शन और डेटा खर्च की जानकारी देखने के लिए, Firebase कंसोल में इस्तेमाल टैब देखें. मौजूदा बिलिंग अवधि, पिछले 30 दिनों या पिछले 24 घंटों के दौरान इस्तेमाल की गई स्टोरेज की जानकारी देखी जा सकती है.

Firebase, इस्तेमाल के आंकड़े दिखाता है. ये आंकड़े इन मेट्रिक के लिए होते हैं:

• कनेक्शन: आपके डेटाबेस से एक साथ कनेक्ट किए गए, फ़िलहाल खुले हुए, और रीयलटाइम कनेक्शन की संख्या. इसमें ये रीयलटाइम कनेक्शन शामिल हैं: WebSocket, लॉन्ग पोलिंग, और एचटीएमएल सर्वर-सेंड इवेंट. इसमें RESTful अनुरोध शामिल नहीं होते.
• स्टोरेज: आपके डेटाबेस में कितना डेटा सेव है. इसमें Firebase होस्टिंग या Firebase के अन्य प्रॉडक्ट के ज़रिए सेव किया गया डेटा शामिल नहीं है.
• डाउनलोड: आपके डेटाबेस से डाउनलोड किए गए सभी बाइट. इनमें प्रोटोकॉल और एन्क्रिप्शन ओवरहेड शामिल है.
• लोड: यह ग्राफ़ दिखाता है कि आपके डेटाबेस का कितना हिस्सा इस्तेमाल किया जा रहा है और अनुरोधों को प्रोसेस किया जा रहा है. यह जानकारी, एक मिनट के अंतराल में मिलती है. डेटाबेस के 100% तक पहुंचने पर, आपको परफ़ॉर्मेंस से जुड़ी समस्याएं दिख सकती हैं.

इस्तेमाल को ऑप्टिमाइज़ करना

डेटाबेस के इस्तेमाल और बैंडविड्थ की लागत को ऑप्टिमाइज़ करने के लिए, कुछ सबसे सही तरीके अपनाए जा सकते हैं.

• नेटिव एसडीके का इस्तेमाल करें: जब भी मुमकिन हो, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म से जुड़े एसडीके का इस्तेमाल करें. एसडीके, ओपन कनेक्शन बनाए रखते हैं. इससे SSL एन्क्रिप्शन की लागत कम हो जाती है. आम तौर पर, REST API के साथ यह लागत बढ़ जाती है.
• बग की जांच करें: अगर बैंडविड्थ का शुल्क उम्मीद से ज़्यादा है, तो पुष्टि करें कि आपका ऐप्लिकेशन, आपके तय किए गए डेटा से ज़्यादा डेटा सिंक नहीं कर रहा है या ज़्यादा बार सिंक नहीं कर रहा है. समस्याओं का पता लगाने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें. इससे आपको रीड ऑपरेशन को मेज़र करने में मदद मिलेगी. साथ ही, Android, Objective-C, और Web SDK टूल में डीबग लॉगिंग चालू करने में मदद मिलेगी. अपने ऐप्लिकेशन में बैकग्राउंड और सिंक करने की प्रोसेस की जांच करें. इससे यह पक्का किया जा सकेगा कि सब कुछ आपकी उम्मीद के मुताबिक काम कर रहा है या नहीं.
• कनेक्शन कम करें: अगर हो सके, तो कनेक्शन के बैंडविड्थ को ऑप्टिमाइज़ करने की कोशिश करें. बार-बार किए जाने वाले छोटे-छोटे REST अनुरोधों पर, नेटिव SDK का इस्तेमाल करके एक बार में किए जाने वाले लगातार कनेक्शन की तुलना में ज़्यादा खर्च आ सकता है. अगर REST API का इस्तेमाल किया जाता है, तो एचटीटीपी कीप-अलाइव या सर्वर-सेंट इवेंट का इस्तेमाल करें. इससे एसएसएल हैंडशेक की लागत कम हो सकती है.
• TLS सेशन टिकट का इस्तेमाल करें: TLS सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन की ओवरहेड लागत को कम करें. यह खास तौर पर तब फ़ायदेमंद होता है, जब आपको डेटाबेस से बार-बार और सुरक्षित तरीके से कनेक्ट करना हो.
• इंडेक्स क्वेरी: अपने डेटा को इंडेक्स करने से, क्वेरी के लिए इस्तेमाल किए जाने वाले कुल बैंडविथ को कम किया जा सकता है. इससे दो फ़ायदे मिलते हैं: लागत कम होती है और डेटाबेस की परफ़ॉर्मेंस बेहतर होती है. अपने डेटाबेस में ऐसी क्वेरी ढूंढने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें जिन्हें इंडेक्स नहीं किया गया है.
• लिसनर को ऑप्टिमाइज़ करें: क्वेरी जोड़कर, लिसन ऑपरेशन से मिलने वाले डेटा को सीमित करें. साथ ही, ऐसे लिसनर का इस्तेमाल करें जो सिर्फ़ डेटा के अपडेट डाउनलोड करते हैं. उदाहरण के लिए, once() के बजाय on() का इस्तेमाल करें. इसके अलावा, अपने लिसनर को पाथ में जितना हो सके उतना नीचे रखें, ताकि वे कम से कम डेटा सिंक करें.
• स्टोरेज की लागत कम करें: समय-समय पर डेटा को हटाने वाले जॉब चलाएं और अपने डेटाबेस में मौजूद डुप्लीकेट डेटा को कम करें.
• नियमों का इस्तेमाल करें: अपने डेटाबेस पर बिना अनुमति वाली ऐसी कार्रवाइयों को रोकें जिनसे आपको नुकसान हो सकता है. उदाहरण के लिए, Firebase Realtime Database Security Rules का इस्तेमाल करके, ऐसे हालात से बचा जा सकता है जहां कोई दुर्भावनापूर्ण उपयोगकर्ता आपके पूरे डेटाबेस को बार-बार डाउनलोड करता है. Firebase रीयलटाइम डेटाबेस नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.

आपके ऐप्लिकेशन के लिए सबसे अच्छा ऑप्टिमाइज़ेशन प्लान, इस्तेमाल के आपके उदाहरण पर निर्भर करता है. यहां सबसे सही तरीकों की पूरी सूची नहीं दी गई है. हालांकि, Firebase के विशेषज्ञों से ज़्यादा सलाह और सुझाव पाने के लिए, हमारे Slack चैनल पर जाएं या Stack Overflow पर जाएं.