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

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

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

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

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

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

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

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

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

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

बिल किए गए इस्तेमाल का अनुमान लगाना

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

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

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

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

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

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

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

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