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

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

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

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

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

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