Firebase, आपके डेटाबेस में सेव किए गए डेटा और ओएसआई मॉडल की सेशन लेयर (लेयर 5) पर, आउटबाउंड नेटवर्क ट्रैफ़िक के लिए बिल भेजता है. स्टोरेज के लिए हर जीबी/महीने पर 50 रुपये का शुल्क लिया जाता है. इसका आकलन हर दिन किया जाता है. आपके डेटाबेस की जगह से बिलिंग पर कोई असर नहीं पड़ता. आउटबाउंड ट्रैफ़िक में, डेटाबेस के सभी ऑपरेशन से जुड़े कनेक्शन और एन्क्रिप्शन ओवरहेड और डेटाबेस रीड के ज़रिए डाउनलोड किए गए डेटा को शामिल किया जाता है. डेटाबेस में डेटा पढ़ने और डेटा लिखने, दोनों से आपके बिल में कनेक्शन शुल्क जुड़ सकता है. आपके डेटाबेस में आने और उससे बाहर जाने वाले सभी ट्रैफ़िक के लिए शुल्क लिया जाता है. इसमें सुरक्षा नियमों के मुताबिक, अनुमति न मिलने वाली कार्रवाइयां भी शामिल हैं.
बिलिंग वाले ट्रैफ़िक के कुछ सामान्य उदाहरणों में ये शामिल हैं:
- डाउनलोड किया गया डेटा: जब क्लाइंट आपके डेटाबेस से डेटा पाते हैं, तो Firebase डाउनलोड किए गए डेटा के लिए शुल्क लेता है. आम तौर पर, बैंडविड्थ की ज़्यादातर लागत इसी से जुड़ी होती है. हालांकि, आपके बिल में सिर्फ़ यह एक फ़ैक्टर नहीं होता.
- प्रोटोकॉल ओवरहेड: सेशन शुरू करने और उसे बनाए रखने के लिए, सर्वर और क्लाइंट के बीच कुछ अतिरिक्त ट्रैफ़िक ज़रूरी होता है. इस्तेमाल किए जा रहे प्रोटोकॉल के आधार पर, इस ट्रैफ़िक में ये शामिल हो सकते हैं: Firebase रीयलटाइम डेटाबेस का रीयलटाइम प्रोटोकॉल ओवरहेड, वेबसोकेट ओवरहेड, और एचटीटीपी हेडर ओवरहेड. हर बार कनेक्शन बनने पर, इस ओवरहेड के साथ-साथ एसएसएल एन्क्रिप्शन के ओवरहेड की वजह से, कनेक्शन की लागत बढ़ जाती है. हालांकि, एक अनुरोध के लिए यह बैंडविड्थ ज़्यादा नहीं है, लेकिन अगर आपके पेलोड छोटे हैं या बार-बार छोटे कनेक्शन किए जाते हैं, तो यह आपके बिल का एक अहम हिस्सा हो सकता है.
- एसएसएल एन्क्रिप्शन ओवरहेड: सुरक्षित कनेक्शन के लिए, एसएसएल एन्क्रिप्शन ओवरहेड की ज़रूरत होती है. इसकी लागत होती है. शुरुआती हैंडशेक के लिए, यह लागत औसतन 3.5 केबी होती है. साथ ही, हर आउटगोइंग मैसेज पर टीएलएस रिकॉर्ड हेडर के लिए, यह लागत करीब 10 केबी होती है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा हिस्सा होता है. हालांकि, अगर आपके मामले में एसएसएल हैंडशेक की ज़रूरत बहुत ज़्यादा है, तो यह प्रतिशत काफ़ी ज़्यादा हो सकता है. उदाहरण के लिए, TLS सेशन टिकट के साथ काम न करने वाले डिवाइसों के लिए, एसएसएल कनेक्शन के हैंडशेक की संख्या ज़्यादा हो सकती है.
- Firebase कंसोल का डेटा: आम तौर पर, यह Realtime Database की लागत का ज़्यादा हिस्सा नहीं होता. हालांकि, Firebase उस डेटा के लिए शुल्क लेता है जिसे Firebase कंसोल से पढ़ा और लिखा जाता है.
बिलिंग के लिए इस्तेमाल किए गए डेटा का अनुमान लगाना
अपने मौजूदा Realtime Database कनेक्शन और डेटा के इस्तेमाल को देखने के लिए, Firebase कंसोल में इस्तेमाल टैब देखें. मौजूदा बिलिंग अवधि, पिछले 30 दिनों या पिछले 24 घंटों के दौरान, डेटा के इस्तेमाल की जानकारी देखी जा सकती है.
Firebase, इन मेट्रिक के इस्तेमाल के आंकड़े दिखाता है:
- कनेक्शन: आपके डेटाबेस से रीयल टाइम में कनेक्ट होने वाले, एक साथ खुले हुए कनेक्शन की संख्या. इसमें ये रीयल टाइम कनेक्शन शामिल हैं: वेबसोकेट, लॉन्ग पोलिंग, और एचटीएमएल सर्वर से भेजे गए इवेंट. इसमें RESTful अनुरोध शामिल नहीं होते.
- स्टोरेज: आपके डेटाबेस में कितना डेटा सेव है. इसमें Firebase होस्टिंग या Firebase के अन्य प्रॉडक्ट से सेव किया गया डेटा शामिल नहीं है.
- डाउनलोड: आपके डेटाबेस से डाउनलोड किए गए सभी बाइट. इसमें प्रोटोकॉल और एन्क्रिप्शन ओवरहेड भी शामिल है.
- लोड: यह ग्राफ़ दिखाता है कि एक मिनट के अंतराल में, आपके डेटाबेस का कितना हिस्सा इस्तेमाल किया जा रहा है और कितने अनुरोध प्रोसेस किए जा रहे हैं. आपका डाटाबेस 100% होने पर, आपको परफ़ॉर्मेंस से जुड़ी समस्याएं दिख सकती हैं.
इस्तेमाल को ऑप्टिमाइज़ करना
डेटाबेस के इस्तेमाल और बैंडविड्थ की लागत को ऑप्टिमाइज़ करने के लिए, कुछ सबसे सही तरीके अपनाए जा सकते हैं.
- नेटिव SDK टूल का इस्तेमाल करें: जब भी हो सके, REST API के बजाय अपने ऐप्लिकेशन के प्लैटफ़ॉर्म के हिसाब से SDK टूल का इस्तेमाल करें. SDK, ओपन कनेक्शन बनाए रखते हैं. इससे, एसएसएल एन्क्रिप्शन की लागत कम हो जाती है, जो आम तौर पर REST API के साथ जुड़ जाती है.
- बग की जांच करना: अगर आपके बैंडविड्थ की लागत अचानक ज़्यादा हो जाती है, तो पुष्टि करें कि आपका ऐप्लिकेशन ज़्यादा डेटा सिंक न कर रहा हो या ज़रूरत से ज़्यादा बार सिंक न कर रहा हो. समस्याओं का पता लगाने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करके, अपने पढ़ने के ऑपरेशन को मेज़र करें. साथ ही, Android, Objective-C, और वेब SDK टूल में, डीबग लॉगिंग की सुविधा चालू करें. अपने ऐप्लिकेशन में बैकग्राउंड और सिंक करने की प्रोसेस की जांच करें, ताकि यह पक्का किया जा सके कि सब कुछ आपकी उम्मीद के मुताबिक काम कर रहा है.
- कनेक्शन कम करना: अगर हो सके, तो अपने कनेक्शन की बैंडविड्थ को ऑप्टिमाइज़ करने की कोशिश करें. बार-बार किए जाने वाले छोटे REST अनुरोध, नेटिव SDK टूल का इस्तेमाल करके किए जाने वाले एक बार के और लगातार कनेक्शन की तुलना में ज़्यादा खर्चीले हो सकते हैं. अगर REST API का इस्तेमाल किया जाता है, तो एचटीटीपी की 'किंग-ऐलिव' सुविधा या सर्वर से भेजे गए इवेंट का इस्तेमाल करें. इससे एसएसएल हैंडशेक की लागत कम हो सकती है.
- TLS सेशन टिकट का इस्तेमाल करना: TLS सेशन टिकट जारी करके, फिर से शुरू किए गए कनेक्शन पर एसएसएल एन्क्रिप्शन के ओवरहेड की लागत कम करें. यह सुविधा खास तौर पर तब काम आती है, जब आपको डेटाबेस से बार-बार और सुरक्षित तरीके से कनेक्ट करना हो.
- क्वेरी को इंडेक्स करना: अपने डेटा को इंडेक्स करने से, क्वेरी के लिए इस्तेमाल किए जाने वाले कुल बैंडविड्थ में कमी आती है. इससे, आपकी लागत कम होने के साथ-साथ आपके डेटाबेस की परफ़ॉर्मेंस भी बेहतर होती है. अपने डेटाबेस में इंडेक्स नहीं की गई क्वेरी ढूंढने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल करें.
- अपने दर्शकों को ऑप्टिमाइज़ करें: क्वेरी जोड़ें, ताकि आपके सुनने के ऑपरेशन से मिलने वाले डेटा को सीमित किया जा सके. साथ ही, सिर्फ़ डेटा के अपडेट डाउनलोड करने वाले दर्शकों का इस्तेमाल करें. उदाहरण के लिए,
once()के बजायon(). इसके अलावा, अपने दर्शकों को पाथ में जितना हो सके उतना नीचे रखें, ताकि वे ज़्यादा डेटा सिंक न कर सकें. - स्टोरेज के लिए कम पैसे चुकाएं: समय-समय पर क्लीनअप जॉब चलाएं और अपने डेटाबेस में डुप्लीकेट डेटा को कम करें.
- नियमों का इस्तेमाल करें: अपने डेटाबेस पर, संभावित तौर पर ज़्यादा खर्च करने वाले और बिना अनुमति वाले किसी भी ऑपरेशन को रोकें. उदाहरण के लिए, Firebase Realtime Database Security Rules का इस्तेमाल करके, उस स्थिति से बचा जा सकता है जहां कोई नुकसान पहुंचाने वाला उपयोगकर्ता आपके पूरे डेटाबेस को बार-बार डाउनलोड करता है. Firebase रियल टाइम डेटाबेस के नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.
आपके ऐप्लिकेशन के लिए सबसे अच्छा ऑप्टिमाइज़ेशन प्लान, आपके इस्तेमाल के उदाहरण पर निर्भर करता है. हालांकि, यह सबसे सही तरीकों की पूरी सूची नहीं है. Firebase के विशेषज्ञों से ज़्यादा सलाह और सुझाव पाने के लिए, हमारे Slack चैनल या Stack Overflow पर जाएं.