रीयलटाइम डेटाबेस की सीमाएं

Firebase Realtime Database में डेटा स्टोरेज और कार्रवाइयों पर ये पाबंदियां लागू होती हैं. इनमें से किसी भी सीमा से आगे बढ़ने के लिए, एक से ज़्यादा डेटाबेस का इस्तेमाल करें.

ग्लोबल

कार्रवाई	सीमा	ब्यौरा
एक साथ काम करने वाले कनेक्शन	2,00,000*	एक साथ कई कनेक्शन का मतलब है कि डेटाबेस से एक मोबाइल डिवाइस, ब्राउज़र टैब या सर्वर ऐप्लिकेशन कनेक्ट है. यह आपके ऐप्लिकेशन के उपयोगकर्ताओं की कुल संख्या से अलग है, क्योंकि आपके सभी उपयोगकर्ता एक साथ कनेक्ट नहीं होते. उदाहरण के लिए, जिन ऐप्लिकेशन के हर महीने 1 करोड़ सक्रिय उपयोगकर्ता होते हैं उनमें आम तौर पर, एक साथ 2,00,000 से कम कनेक्शन होते हैं. एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह आपके उपयोगकर्ताओं की कुल संख्या और आपके ऐप्लिकेशन में उपयोगकर्ताओं के बिताए गए औसत समय पर निर्भर करता है. हालांकि, अगर आपको इस सीमा से ज़्यादा डेटा स्टोर करना है, तो एक से ज़्यादा डेटाबेस इस्तेमाल करके देखें. *Spark प्लान में, एक साथ 100 कनेक्शन बनाए जा सकते हैं.
एक ही डेटाबेस से एक साथ कई जवाब भेजे जाते हैं.	~1,00,000/सेकंड	रिस्पॉन्स में, एक ही समय पर सर्वर से भेजे गए ब्रॉडकास्ट और रीड ऑपरेशन शामिल होते हैं. ये ऑपरेशन, किसी तय समय पर एक ही डेटाबेस से भेजे जाते हैं. इस सीमा का मतलब, डेटा पैकेट से है. ये पैकेट, डेटाबेस से भेजे गए हर रीड या ब्रॉडकास्ट ऑपरेशन को दिखाते हैं. इनमें पुश नोटिफ़िकेशन भी शामिल हैं. यह सलाह लगातार लोड के लिए है, लेकिन डेटाबेस कभी-कभी ज़्यादा लोड को भी हैंडल कर सकता है.
एक बार डेटा लिखने पर ट्रिगर होने वाले Cloud Functions की संख्या	1, 000; या Cloud Functions v2 के लिए, हर इलाके के हिसाब से 500	एक फ़ंक्शन से, डेटा को पढ़ने या लिखने की कितनी कार्रवाइयां ट्रिगर की जा सकती हैं, इसकी कोई सीमा नहीं है. हालांकि, डेटाबेस में डेटा लिखने की एक कार्रवाई से, सिर्फ़ 1,000 फ़ंक्शन ट्रिगर किए जा सकते हैं. इसके अलावा, Cloud Functions v2 के लिए हर इलाके में 500 फ़ंक्शन ट्रिगर किए जा सकते हैं. Cloud Functions को सिर्फ़ डेटा लिखने की प्रोसेस से ट्रिगर किया जा सकता है. साथ ही, हर फ़ंक्शन, डेटा लिखने की ज़्यादा प्रोसेस को भी ट्रिगर कर सकता है. इससे ज़्यादा फ़ंक्शन ट्रिगर होते हैं. हर फ़ंक्शन के लिए, 1,000 फ़ंक्शन या हर क्षेत्र के लिए 500 फ़ंक्शन की सीमा होती है.
राइट ऑपरेशन से ट्रिगर होने वाले किसी एक इवेंट का साइज़	1 एमबी	किसी इवेंट के साइज़ में ये वैल्यू शामिल होती हैं: राइट लोकेशन पर मौजूद डेटा. अपडेट की गई वैल्यू या डेटा में मौजूद डेल्टा, जो जगह की जानकारी में नया डेटा लिखने के लिए ज़रूरी है. डेटाबेस में 1 एमबी से ज़्यादा के राइट ऑपरेशन पूरे हो जाते हैं, लेकिन वे फ़ंक्शन को ट्रिगर नहीं करते.
Cloud Functions में डेटा ट्रांसफ़र करना	10 एमबी/सेकंड की स्पीड लगातार बनी रहती है	इवेंट डेटा की वह दर जिसे Cloud Functions पर फ़ॉरवर्ड किया जा सकता है.

ट्रिगर की सीमाओं के लिए, नीति उल्लंघन ठीक करने के सख्त तरीके को बंद करना

इवेंट ट्रिगर करने वाले राइट ऑपरेशन के लिए, सख्त पुष्टि की सुविधा डिफ़ॉल्ट रूप से चालू होती है. अगर डेटा सेव करने की किसी कार्रवाई से 1,000 से ज़्यादा Cloud Functions ट्रिगर होते हैं या 1 एमबी से ज़्यादा साइज़ का कोई इवेंट ट्रिगर होता है, तो वह कार्रवाई पूरी नहीं होगी. साथ ही, आपको गड़बड़ी का मैसेज दिखेगा. इसमें बताया जाएगा कि तय सीमा पार हो गई है. इसका मतलब यह हो सकता है कि अगर कुछ Cloud Functions की पहले से पुष्टि नहीं हो पाती है, तो वे ट्रिगर नहीं होते.

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

strictTriggerValidation को बंद करने के लिए, यह तरीका अपनाएं:

1. Firebase कंसोल में, प्रोजेक्ट सेटिंग के सेवा खाते टैब से अपना डेटाबेस सीक्रेट पाएं.
2. अपनी कमांड लाइन से यह CURL अनुरोध चलाएं:
curl -X PUT -d "false" https://<namespace>.firebaseio.com/.settings/strictTriggerValidation/.json?auth\=<SECRET>

डेटा ट्री

प्रॉपर्टी	सीमा	ब्यौरा
चाइल्ड नोड की ज़्यादा से ज़्यादा गहराई	32	आपके डेटा ट्री में मौजूद हर पाथ में 32 से कम लेवल होने चाहिए.
कुंजी की लंबाई	768 बाइट	कुंजियां UTF-8 कोड में बदली गई होती हैं. इनमें नई लाइनें या इनमें से कोई भी वर्ण शामिल नहीं हो सकता: . $ # [ ] / या कोई भी ASCII कंट्रोल वर्ण (0x00 - 0x1F और 0x7F)
स्ट्रिंग का ज़्यादा से ज़्यादा साइज़	10 एमबी	डेटा, UTF-8 में एन्कोड किया गया हो.

पढ़ा गया

ब्यौरा	सीमा	नोट
डेटाबेस से मिले किसी एक जवाब का साइज़	256 एमबी	डेटाबेस से एक ही जगह पर डाउनलोड किए गए डेटा का साइज़, हर बार डेटा पढ़ने के लिए 256 एमबी से कम होना चाहिए. किसी बड़ी जगह पर डेटा पढ़ने के लिए, इनमें से कोई एक विकल्प आज़माएं: बैकअप का इस्तेमाल करें. क्वेरी की मदद से डेटा को पेज के हिसाब से बांटना. शैलो क्वेरी का इस्तेमाल करें.
किसी पाथ में मौजूद कुल नोड, जिनमें लिसनर या क्वेरी मौजूद हैं	7.5 करोड़*	कुल मिलाकर 7.5 करोड़ से ज़्यादा नोड वाले पाथ को न तो सुना जा सकता है और न ही क्वेरी की जा सकती है. हालांकि, चाइल्ड नोड को अब भी सुना जा सकता है या उनसे क्वेरी की जा सकती है. पाथ में ज़्यादा गहराई से ड्रिल करने की कोशिश करें या पाथ के ज़्यादा खास हिस्सों के लिए अलग-अलग लिसनर या क्वेरी बनाएं. *Firebase कंसोल में डेटा व्यूअर से, 30,000 से ज़्यादा नोड वाले पाथ नहीं देखे जा सकते.
किसी क्वेरी को चलाने में लगने वाला समय	15 मिनट*	एक क्वेरी ज़्यादा से ज़्यादा 15 मिनट तक काम कर सकती है. इसके बाद, वह काम नहीं कर पाती. *Firebase कंसोल में की गई कोई क्वेरी, सिर्फ़ पांच सेकंड तक चल सकती है. इसके बाद, वह काम नहीं कर पाती.

लिखना

ब्यौरा	सीमा	नोट
डेटा सेव करने की दर	1,000 राइट/सेकंड	एक डेटाबेस पर, हर सेकंड में डेटा लिखने की सीमा. हालांकि, यह कोई तय सीमा नहीं है, लेकिन अगर हर सेकंड 1,000 से ज़्यादा बार डेटा सेव किया जाता है, तो डेटा सेव करने की गतिविधि को सीमित किया जा सकता है.
डेटाबेस में डेटा सेव करने के लिए किए गए किसी एक अनुरोध का साइज़	REST API से 256 एमबी; एसडीके से 16 एमबी.	हर राइट ऑपरेशन में कुल डेटा 256 एमबी से कम होना चाहिए. मल्टी-पाथ अपडेट के लिए भी साइज़ की यही सीमा लागू होती है.
लिखी गई बाइट	64 एमबी/मिनट	किसी भी समय, डेटाबेस पर एक साथ किए गए राइट ऑपरेशन से लिखे गए कुल बाइट.