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

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

इस्तेमाल पर नज़र रखना

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

Google Cloud कंसोल में इस्तेमाल की ज़्यादा जानकारी

Firebase प्रोजेक्ट बनाने पर, Google Cloud प्रोजेक्ट भी बन जाता है. Google Cloud कंसोल में मौजूद Cloud Firestore एपीआई कोटा और App Engine कोटा पेज, Cloud Firestore के इस्तेमाल और कोटा की जानकारी को ट्रैक करते हैं.

मुफ़्त कोटा

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

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

यहां दी गई टेबल में, बिना किसी शुल्क के उपलब्ध कोटा की जानकारी दी गई है:

फ़्री टियर कोटा
संग्रहित डेटा 1 GiB
दस्तावेज़ पढ़ना हर दिन 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 एमआईबी (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

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

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

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

7.5 केआईबी

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

8 एमआईबी

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

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

    1,500 बाइट

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

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

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

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

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

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

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

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

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

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

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

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

    बजट और बजट से जुड़ी सूचनाएं सेट अप करने के बारे में ज़्यादा जानें.