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

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 जीबी
दस्तावेज़ पढ़ना हर दिन 50,000
दस्तावेज़ लिखना हर दिन 20,000
दस्तावेज़ मिटाना हर दिन 20,000
आउटबाउंड डेटा ट्रांसफ़र हर महीने 10 जीबी

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

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

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

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

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

डेटाबेस

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

100

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

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

0

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

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

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

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