नेटिव मोड: कोटा और सीमाएं

इस पेज पर, नेटिव मोड में Cloud Firestore के लिए अनुरोध कोटा और Enterprise वर्शन की सीमाओं के बारे में बताया गया है.

फ़्री टियर का इस्तेमाल

नेटिव मोड में Cloud Firestore के साथ, बिना किसी शुल्क के शुरुआत करने के लिए, आपको मुफ़्त टियर मिलता है. मुफ़्त टियर में मिलने वाली सुविधाओं की जानकारी यहां दी गई है.

मुफ़्त टियर की रकम हर दिन लागू होती है और पैसिफ़िक टाइम के मुताबिक आधी रात को रीसेट होती है.

मुफ़्त टियर, हर प्रोजेक्ट के लिए सिर्फ़ एक Cloud Firestore डेटाबेस पर लागू होता है. अगर किसी प्रोजेक्ट में फ़्री टीयर वाला डेटाबेस नहीं है, तो उसमें बनाए गए पहले डेटाबेस को फ़्री टीयर मिलेगा. अगर फ़्री टियर वाला डेटाबेस मिटा दिया जाता है, तो बनाए गए अगले डेटाबेस को फ़्री टियर मिलेगा.

फ़्री टियर कोटा
संग्रहित डेटा 1 GiB
यूनिट पढ़ने की अनुमति हर दिन 50,000
रीयल-टाइम अपडेट यूनिट हर दिन 50,000
यूनिट लिखना हर दिन 40,000
आउटबाउंड डेटा ट्रांसफ़र हर महीने 10 GiB

स्टैंडर्ड सीमाएं

यहां दी गई टेबल में, नेटिव मोड में Cloud Firestore पर लागू होने वाली सीमाओं के बारे में बताया गया है. ये तय सीमाएं हैं. हालांकि, कुछ मामलों में इनमें बदलाव किया जा सकता है.

डेटाबेस

सीमा विवरण
हर प्रोजेक्ट के लिए ज़्यादा से ज़्यादा डेटाबेस

100

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

हर प्रोजेक्ट के लिए, ज़्यादा से ज़्यादा ग्राहक की ओर से मैनेज की जाने वाली एन्क्रिप्शन कुंजियों (सीएमईके) वाले डेटाबेस

0

डिफ़ॉल्ट रूप से कोटा 0 होता है, क्योंकि यह सुविधा अनुमति वाली सूची में शामिल है. सीएमईके के ऐक्सेस का अनुरोध करने वाला फ़ॉर्म भरकर, कोटा बढ़ाने का अनुरोध किया जा सकता है.

कलेक्शन, दस्तावेज़, और फ़ील्ड

सीमा विवरण
कलेक्शन आईडी पर पाबंदियां
  • मान्य UTF-8 वर्ण होने चाहिए
  • यह 1,500 बाइट से ज़्यादा नहीं होना चाहिए
  • इसमें फ़ॉरवर्ड स्लैश (/) नहीं होना चाहिए
  • इसमें सिर्फ़ एक पीरियड (.) या दो पीरियड (..) नहीं होने चाहिए
  • रेगुलर एक्सप्रेशन __.*__ से मेल नहीं खा सकता
सब-कलेक्शन की ज़्यादा से ज़्यादा डेप्थ 100
दस्तावेज़ के आईडी पर पाबंदियां
  • मान्य UTF-8 वर्ण होने चाहिए
  • यह 1,500 बाइट से ज़्यादा नहीं होना चाहिए
  • इसमें फ़ॉरवर्ड स्लैश (/) नहीं होना चाहिए
  • इसमें सिर्फ़ एक पीरियड (.) या दो पीरियड (..) नहीं होने चाहिए
  • रेगुलर एक्सप्रेशन __.*__ से मेल नहीं खा सकता
  • Datastore की इकाइयों को Firestore डेटाबेस में इंपोर्ट करने पर, संख्या वाले इकाई आईडी __id[0-9]+__ के तौर पर दिखते हैं
दस्तावेज़ के नाम का ज़्यादा से ज़्यादा साइज़ 6 केआईबी
किसी दस्तावेज़ का ज़्यादा से ज़्यादा साइज़ 1 एमआईबी (1,048,576 बाइट)
फ़ील्ड के नामों से जुड़ी शर्तें
  • मान्य UTF-8 वर्ण होने चाहिए
  • रेगुलर एक्सप्रेशन __.*__ से मेल नहीं खा सकता
फ़ील्ड के नाम का ज़्यादा से ज़्यादा साइज़ 1,500 बाइट
फ़ील्ड पाथ पर पाबंदियां
  • फ़ील्ड के नामों को एक पीरियड (.) से अलग करना ज़रूरी है
  • इसे डॉट-डिलिमिटेड (.) सेगमेंट की स्ट्रिंग के तौर पर पास किया जा सकता है. इसमें हर सेगमेंट, सामान्य फ़ील्ड का नाम या कोट किया गया फ़ील्ड का नाम होता है (नीचे बताया गया है).
फ़ील्ड का आसान नाम वह होता है जिसमें ये सभी बातें सही हों:
  • इसमें सिर्फ़ a-z, A-Z, 0-9, और अंडरस्कोर (_) वर्ण शामिल हों
  • 0-9 से शुरू नहीं होता
कोट किया गया फ़ील्ड का नाम, बैकटिक वर्ण (`) से शुरू और खत्म होता है. उदाहरण के लिए, foo.`x&y`, foo फ़ील्ड में नेस्ट किए गए x&y फ़ील्ड को दिखाता है. बैकिट्क वर्ण का इस्तेमाल करके फ़ील्ड का नाम बनाने के लिए, बैकिट्क वर्ण को बैक्स्लैश वर्ण (\) से एस्केप करें. आसानी के लिए, फ़ील्ड के पाथ को FieldPath ऑब्जेक्ट के तौर पर पास करके, कोट किए गए फ़ील्ड के नामों से बचा जा सकता है (उदाहरण के लिए, JavaScript FieldPath देखें).
फ़ील्ड पाथ का ज़्यादा से ज़्यादा साइज़ 1,500 बाइट
किसी फ़ील्ड की वैल्यू का ज़्यादा से ज़्यादा साइज़ 1 MiB - 89 बाइट (1,048,487 बाइट)
मैप या ऐरे में फ़ील्ड की ज़्यादा से ज़्यादा डेप्थ

20

मैप और ऐरे फ़ील्ड, किसी ऑब्जेक्ट की कुल डेप्थ में एक लेवल जोड़ते हैं. उदाहरण के लिए, यहां दिए गए ऑब्जेक्ट में कुल तीन लेवल हैं:


{
  nested_map: {         #depth 1
    nested_array: [     #depth 2
      {
        foo: "bar"      #depth 3
      }
    ]
  }
}
      

लिखना और लेन-देन करना

सीमा विवरण
एपीआई अनुरोध का ज़्यादा से ज़्यादा साइज़ 10 एमआईबी
लेन-देन के लिए समयसीमा 270 सेकंड, जिसमें 60 सेकंड तक इनऐक्टिव रहने पर समयसीमा खत्म हो जाती है
Commit ऑपरेशन या किसी लेन-देन में, एक दस्तावेज़ पर ज़्यादा से ज़्यादा कितने फ़ील्ड ट्रांसफ़ॉर्मेशन किए जा सकते हैं 500

इंडेक्स

सीमा विवरण
किसी डेटाबेस के लिए इंडेक्स की ज़्यादा से ज़्यादा संख्या

हर दस्तावेज़ के लिए इंडेक्स एंट्री की ज़्यादा से ज़्यादा संख्या

40,000

किसी इंडेक्स में ज़्यादा से ज़्यादा फ़ील्ड 100
इंडेक्स एंट्री का ज़्यादा से ज़्यादा साइज़

7.5 केआईबी

किसी दस्तावेज़ की इंडेक्स एंट्री के साइज़ का ज़्यादा से ज़्यादा योग

8 एमआईबी

टाइम-टू-लाइव (टीटीएल)

सीमा विवरण
किसी डेटाबेस के लिए, सिंगल-फ़ील्ड कॉन्फ़िगरेशन की ज़्यादा से ज़्यादा संख्या

एक फ़ील्ड लेवल कॉन्फ़िगरेशन में, एक ही फ़ील्ड के लिए कई कॉन्फ़िगरेशन हो सकते हैं. उदाहरण के लिए, एक ही फ़ील्ड के लिए इंडेक्सिंग से छूट और टीटीएल की नीति को सीमा के हिसाब से एक फ़ील्ड कॉन्फ़िगरेशन माना जाता है.

एक्सपोर्ट/इंपोर्ट

मैनेज किए गए इंपोर्ट और एक्सपोर्ट ऑपरेशन पर ये सीमाएं लागू होती हैं:

सीमा विवरण
किसी प्रोजेक्ट के लिए, हर मिनट में एक्सपोर्ट और इंपोर्ट के ज़्यादा से ज़्यादा अनुरोध किए जा सकते हैं 20
एक साथ एक्सपोर्ट और इंपोर्ट किए जा सकने वाले डेटा की ज़्यादा से ज़्यादा संख्या 50
एक्सपोर्ट और इंपोर्ट के अनुरोधों के लिए, कलेक्शन आईडी फ़िल्टर की ज़्यादा से ज़्यादा संख्या 100

सुरक्षा के नियम

सीमा विवरण
हर अनुरोध के लिए, exists(), get(), और getAfter() के ज़्यादा से ज़्यादा कॉल
  • एक दस्तावेज़ के लिए अनुरोध और क्वेरी के अनुरोधों के लिए 10.
  • एक से ज़्यादा दस्तावेज़ों को पढ़ने, लेन-देन करने, और बैच में लिखने के लिए 20. हर ऑपरेशन के लिए, 10 की पिछली सीमा भी लागू होती है.

    उदाहरण के लिए, मान लें कि आपने तीन राइट ऑपरेशन वाला एक बैच्ड राइट अनुरोध बनाया है. साथ ही, आपकी सुरक्षा से जुड़े नियम, हर राइट की पुष्टि करने के लिए दस्तावेज़ के ऐक्सेस के दो कॉल का इस्तेमाल करते हैं. इस मामले में, हर राइट ऑपरेशन के लिए 10 में से 2 ऐक्सेस कॉल का इस्तेमाल किया जाता है. साथ ही, बैच किए गए राइट अनुरोध के लिए 20 में से 6 ऐक्सेस कॉल का इस्तेमाल किया जाता है.

इनमें से किसी भी सीमा के पार जाने पर, अनुमति नहीं दी जाएगी.

दस्तावेज़ के ऐक्सेस से जुड़े कुछ कॉल को कैश मेमोरी में सेव किया जा सकता है. कैश मेमोरी में सेव किए गए कॉल, सीमा में शामिल नहीं होते.

नेस्ट किए गए match स्टेटमेंट की ज़्यादा से ज़्यादा डेप्थ 10
नेस्ट किए गए match स्टेटमेंट के सेट में, पाथ सेगमेंट में पाथ की ज़्यादा से ज़्यादा लंबाई 100
नेस्ट किए गए match स्टेटमेंट के सेट में, पाथ कैप्चर करने वाले वैरिएबल की ज़्यादा से ज़्यादा संख्या 20
फ़ंक्शन कॉल की ज़्यादा से ज़्यादा डेप्थ 20
फ़ंक्शन के आर्ग्युमेंट की ज़्यादा से ज़्यादा संख्या 7
हर फ़ंक्शन के लिए, let वैरिएबल बाइंडिंग की ज़्यादा से ज़्यादा संख्या 10
फ़ंक्शन को बार-बार या साइकल के हिसाब से कॉल करने की ज़्यादा से ज़्यादा संख्या 0 (अनुमति नहीं है)
हर अनुरोध के लिए, ज़्यादा से ज़्यादा एक्सप्रेशन का आकलन किया जा सकता है 1,000
नियमों के सेट का ज़्यादा से ज़्यादा साइज़ रूलसेट के लिए, साइज़ से जुड़ी दो सीमाएं तय की गई हैं. इनका पालन करना ज़रूरी है:
  • Firebase कंसोल या firebase deploy का इस्तेमाल करके सीएलआई से पब्लिश किए गए, नियमों के सेट के टेक्स्ट सोर्स का साइज़ 256 केबी से ज़्यादा नहीं होना चाहिए.
  • कंपाइल किए गए नियमों के सेट का साइज़ 250 केबी से ज़्यादा नहीं होना चाहिए. यह साइज़ तब तय होता है, जब Firebase सोर्स को प्रोसेस करता है और उसे बैक-एंड पर चालू करता है.