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