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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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