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

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

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

नेटिव मोड में 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 MiB - 89 बाइट (10,48,487 बाइट)
किसी मैप या कलेक्शन में फ़ील्ड की ज़्यादा से ज़्यादा गहराई

20

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


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

डेटा में बदलाव करने की कार्रवाइयां और लेन-देन

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

इंडेक्स

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

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

40,000

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

7.5 केआईबी

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

8 एमआईबी

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

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

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

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

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

सीमा विवरण
किसी प्रोजेक्ट के लिए, हर मिनट एक्सपोर्ट और इंपोर्ट के अनुरोधों की ज़्यादा से ज़्यादा संख्या 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 कंसोल या सीएलआई से firebase deploy का इस्तेमाल करके पब्लिश किए गए नियमों के सेट के टेक्स्ट सोर्स का साइज़ 256 केबी से ज़्यादा नहीं होना चाहिए.
  • कंपाइल किए गए नियमों के सेट का साइज़ 250 केबी से ज़्यादा नहीं होना चाहिए. यह सेट तब बनता है, जब Firebase सोर्स को प्रोसेस करता है और उसे बैक-एंड पर चालू करता है.

सेव की गई क्वेरी की सीमाएं

वैल्यू सीमा
हर प्रोजेक्ट के लिए, सेव की गई क्वेरी की ज़्यादा से ज़्यादा संख्या (इसमें अन्य Google Cloud प्रॉडक्ट के लिए सेव की गई क्वेरी भी शामिल हैं) 10,000
हर क्वेरी का ज़्यादा से ज़्यादा साइज़ 1 एमआईबी