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

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

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

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

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

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

शुल्क लिए जाने वाले ट्रैफ़िक के कुछ सामान्य उदाहरण यहां दिए गए हैं:

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

शुल्क लिए जाने वाले इस्तेमाल का अनुमान लगाना

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

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

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

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

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

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

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