Firebase, आपके डेटाबेस में सेव किए गए डेटा और ओएसआई मॉडल की सेशन लेयर (लेयर 5) पर, आउटबाउंड नेटवर्क ट्रैफ़िक के लिए बिल भेजता है. स्टोरेज के लिए हर जीबी/महीने पर 50 रुपये का शुल्क लिया जाता है. इसका आकलन हर दिन किया जाता है. आपके डेटाबेस की जगह से बिलिंग पर कोई असर नहीं पड़ता. आउटबाउंड ट्रैफ़िक में, डेटाबेस के सभी ऑपरेशन से जुड़े कनेक्शन और एन्क्रिप्शन ओवरहेड और डेटाबेस रीड के ज़रिए डाउनलोड किए गए डेटा को शामिल किया जाता है. डेटाबेस में डेटा पढ़ने और डेटा लिखने, दोनों से आपके बिल में कनेक्शन शुल्क जुड़ सकता है. आपके डेटाबेस में आने और उससे बाहर जाने वाले सभी ट्रैफ़िक पर शुल्क लिया जाता है. इसमें सुरक्षा नियमों के मुताबिक, अस्वीकार की गई कार्रवाइयां भी शामिल हैं.
बिलिंग वाले ट्रैफ़िक के कुछ सामान्य उदाहरणों में ये शामिल हैं:
- डाउनलोड किया गया डेटा: जब क्लाइंट को आपके डेटाबेस से डेटा मिलता है, तब Firebase डाउनलोड किए गए डेटा के लिए शुल्क लेता है. आम तौर पर, बैंडविड्थ की ज़्यादातर लागत इसी से जुड़ी होती है. हालांकि, आपके बिल में सिर्फ़ यह एक फ़ैक्टर नहीं होता.
- प्रोटोकॉल ओवरहेड: सेशन शुरू करने और उसे बनाए रखने के लिए, सर्वर और क्लाइंट के बीच कुछ अतिरिक्त ट्रैफ़िक ज़रूरी होता है. इस्तेमाल किए जा रहे प्रोटोकॉल के आधार पर, इस ट्रैफ़िक में ये शामिल हो सकते हैं: Firebase रीयलटाइम डेटाबेस का रीयलटाइम प्रोटोकॉल ओवरहेड, वेबसोकेट ओवरहेड, और एचटीटीपी हेडर ओवरहेड. जब भी कोई कनेक्शन बनाया जाता है, तो यह ओवरहेड, एसएसएल एन्क्रिप्शन के ओवरहेड के साथ मिलकर, कनेक्शन की लागत को बढ़ाता है. हालांकि, यह किसी एक अनुरोध के लिए ज़्यादा बैंडविथ नहीं है, लेकिन अगर आपका पेलोड कम है या बार-बार छोटे कनेक्शन बनाए जाते हैं, तो यह आपके बिल का एक बड़ा हिस्सा हो सकता है.
- एसएसएल एन्क्रिप्शन ओवरहेड: सुरक्षित कनेक्शन के लिए, एसएसएल एन्क्रिप्शन ओवरहेड ज़रूरी है. इसके लिए शुल्क देना होता है. औसतन, शुरुआती हैंडशेक के लिए यह लागत करीब 3.5 केबी है और हर आउटगोइंग मैसेज पर टीएलएस रिकॉर्ड हेडर के लिए करीब दस बाइट है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा हिस्सा होता है. हालांकि, अगर आपके मामले में एसएसएल हैंडशेक की ज़रूरत बहुत ज़्यादा है, तो यह प्रतिशत काफ़ी ज़्यादा हो सकता है. उदाहरण के लिए, TLS सेशन टिकट के साथ काम न करने वाले डिवाइसों के लिए, एसएसएल कनेक्शन के हैंडशेक की संख्या ज़्यादा हो सकती है.
- Firebase कंसोल का डेटा: आम तौर पर, यह Realtime Database की लागत का ज़्यादा हिस्सा नहीं होता. हालांकि, Firebase उस डेटा के लिए शुल्क लेता है जिसे Firebase कंसोल से पढ़ा और लिखा जाता है.
बिलिंग के लिए इस्तेमाल किए गए डेटा का अनुमान लगाना
अपने मौजूदा Realtime Database कनेक्शन और डेटा खर्च की जानकारी देखने के लिए, Firebase कंसोल में इस्तेमाल टैब देखें. मौजूदा बिलिंग अवधि, पिछले 30 दिनों या पिछले 24 घंटों के दौरान, डेटा के इस्तेमाल की जानकारी देखी जा सकती है.
Firebase इन मेट्रिक के इस्तेमाल के आंकड़े दिखाता है:
- कनेक्शन: आपके डेटाबेस से रीयल टाइम में कनेक्ट होने वाले, एक साथ खुले हुए कनेक्शन की संख्या. इसमें ये रीयल टाइम कनेक्शन शामिल हैं: WebSocket, लंबी पोलिंग, और एचटीएमएल सर्वर से भेजे गए इवेंट. इसमें 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 पर जाएं.