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

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

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

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

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

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

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

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

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

डेटाबेस

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

100

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

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

0

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

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

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

टाइम-टू-लाइव (TTL)

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

  • अगर आपने अपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू नहीं की है, तो 200.

    अगर आपको ज़्यादा कोटा चाहिए, तो आपको अपने प्रोजेक्ट के लिए बिलिंग चालू करनी होगी.Google Cloud

  • अगर आपने अपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू की है, तो 1,000.

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

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

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

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

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

सीमा विवरण
हर अनुरोध के लिए, exists(), get(), और getAfter() कॉल की ज़्यादा से ज़्यादा संख्या
  • सिंगल-डॉक्यूमेंट के अनुरोधों और क्वेरी के अनुरोधों के लिए 10.

  • मल्टी-डॉक्यूमेंट रीड, लेन-देन, और बैच में किए गए राइट के लिए 20. पिछली सीमा (10) हर ऑपरेशन पर भी लागू होती है.

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

किसी भी सीमा से ज़्यादा होने पर, अनुमति नहीं होने की गड़बड़ी दिखती है.

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