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

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

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

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

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

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

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

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

अगर आपका प्रोजेक्ट, ब्लेज़ प्राइसिंग प्लान पर है, कंसोल का इस्तेमाल करके बजट के अलर्ट सेट अप करें. हर महीने की लागत का अनुमान लगाने के लिए, ब्लेज़ प्लान कैलकुलेटर का इस्तेमाल किया जा सकता है.

ध्यान रखें कि बजट के अलर्ट, आपके इस्तेमाल या शुल्क की सीमा तय नहीं करते. ये आपकी लागत के बारे में अलर्ट होते हैं, ताकि ज़रूरत पड़ने पर कार्रवाई की जा सके. उदाहरण के लिए, किसी प्रोजेक्ट पर Cloud Billing को प्रोग्राम के ज़रिए बंद करने के लिए, बजट की सूचनाओं का इस्तेमाल किया जा सकता है.

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

मौजूदा 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 रीयलटाइम डेटाबेस के नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें .

प्रोफ़ाइलर टूल के बारे में ध्यान दें: प्रोफ़ाइलर टूल, नेटवर्क ट्रैफ़िक का हिसाब नहीं रखता. यह सिर्फ़ जवाबों में भेजे गए ऐप्लिकेशन डेटा के अनुमान को रिकॉर्ड करता है. प्रोफ़ाइलर टूल का मकसद, आपको अपने डेटाबेस की परफ़ॉर्मेंस की पूरी जानकारी देना है, ताकि आपको ऑपरेशन की निगरानी करने और समस्याओं को हल करने में मदद मिल सके. इसका इस्तेमाल बिलिंग का अनुमान लगाने के लिए नहीं किया जाता. ज़्यादा जानने के लिए, प्रोफ़ाइलर टूल का दस्तावेज़ देखें.

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