इस्तेमाल और सीमाएं

Cloud Firestore की सीमाओं को समझने के लिए, इस गाइड का इस्तेमाल करें. साथ ही, Cloud Firestore की कीमत के बारे में पूरी और विस्तृत जानकारी पाने के लिए, Cloud Firestore की कीमत देखें. इसमें, आपको किन बातों का ध्यान रखना है, यह भी बताया गया है.

इस्तेमाल की निगरानी करना

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

Google Cloud कंसोल में इस्तेमाल की विस्तृत जानकारी

Firebase प्रोजेक्ट बनाने पर, Google Cloud प्रोजेक्ट भी बनता है. Cloud Firestore API के कोटा और App Engine के कोटा वाले पेजों पर, Google Cloud कंसोल में, Cloud Firestore के इस्तेमाल और कोटा की जानकारी ट्रैक की जाती है.

मुफ़्त कोटा

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

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

मुफ़्त कोटा की रकम के बारे में जानकारी, यहां दी गई टेबल में दी गई है:

फ़्री टियर कोटा
संग्रहित डेटा 1 जीबी
दस्तावेज़ पढ़ना हर दिन 50,000
दस्तावेज़ लिखना हर दिन 20,000
दस्तावेज़ मिटाना हर दिन 20,000
आउटबाउंड डेटा ट्रांसफ़र हर महीने 10 जीबी

इन कार्रवाइयों और सुविधाओं के लिए, मुफ़्त कोटा उपलब्ध नहीं है. इन सुविधाओं का इस्तेमाल करने के लिए, आपको बिलिंग की सुविधा चालू करनी होगी:

  • TTL (टीटीएल) के तहत मिटाने की सुविधा
  • पीआईटीआर डेटा
  • बैकअप डेटा
  • डेटा को वापस पाने की कार्रवाइयां
  • क्लोन करने की कार्रवाइयां

इन सुविधाओं के लिए बिलिंग कैसे की जाती है, इस बारे में ज़्यादा जानने के लिए, स्टोरेज की कीमत देखें.

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

यहां दी गई टेबल में, 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

किसी दस्तावेज़ के लिए, इंडेक्स एंट्री की संख्या, इन चीज़ों का योग होती है:

  • सिंगल-फ़ील्ड इंडेक्स एंट्री की संख्या
  • कंपोज़िट इंडेक्स एंट्री की संख्या

यह देखने के लिए कि Cloud Firestore किसी दस्तावेज़ और इंडेक्स के सेट को इंडेक्स एंट्री में कैसे बदलता है, इंडेक्स एंट्री की संख्या का यह उदाहरण देखें.
कंपोज़िट इंडेक्स में फ़ील्ड की ज़्यादा से ज़्यादा संख्या 100
इंडेक्स एंट्री का ज़्यादा से ज़्यादा साइज़

7.5 केबी

यह देखने के लिए कि Cloud Firestore इंडेक्स एंट्री के साइज़ का हिसाब कैसे लगाता है, इंडेक्स एंट्री का साइज़ देखें.
किसी दस्तावेज़ की इंडेक्स एंट्री के साइज़ का ज़्यादा से ज़्यादा योग

8 एमबी

किसी दस्तावेज़ के लिए, कुल साइज़, इन चीज़ों का योग होता है:

  • किसी दस्तावेज़ की सिंगल-फ़ील्ड इंडेक्स एंट्री के साइज़ का योग
  • किसी दस्तावेज़ की कंपोज़िट इंडेक्स एंट्री के साइज़ का योग
    		•
    इंडेक्स किए गए फ़ील्ड की वैल्यू का ज़्यादा से ज़्यादा साइज़

    1,500 बाइट

    1,500 बाइट से ज़्यादा की फ़ील्ड वैल्यू को काट दिया जाता है. काटी गई फ़ील्ड वैल्यू वाली क्वेरी से, गलत नतीजे मिल सकते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

    खर्च मैनेज करना

    बिल पर लगने वाले अनचाहे शुल्कों से बचने के लिए, हर महीने का बजट और चेतावनियां सेट करें.

    हर महीने का बजट सेट करना

    अपनी Cloud Firestore लागत ट्रैक करने के लिए, Google Cloud कंसोल में हर महीने का बजट बनाएं. बजट सेट करने से, आपके इस्तेमाल पर कोई सीमा नहीं लगती. हालांकि, चेतावनियां सेट की जा सकती हैं. इससे, महीने के लिए तय की गई लागत के आस-पास पहुंचने या उससे ज़्यादा खर्च होने पर, आपको सूचनाएं मिलती हैं.

    बजट सेट करने के लिए, बिलिंग सेक्शन पर जाएं और अपने Cloud Billing खाते के लिए बजट बनाएं.Google Cloud चेतावनी की डिफ़ॉल्ट सेटिंग का इस्तेमाल किया जा सकता है. इसके अलावा, हर महीने के बजट के अलग-अलग प्रतिशत पर सूचनाएं भेजने के लिए, चेतावनियों में बदलाव किया जा सकता है.

    बजट और बजट की चेतावनियां सेट अप करने के बारे में ज़्यादा जानें .