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