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

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

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

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

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

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

मुफ़्त कोटा

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

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

सिर्फ़ (default) डेटाबेस के लिए, मुफ़्त कोटा मिलता है.

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

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

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

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

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

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

डेटाबेस

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

100

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

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

सीमा विवरण
कलेक्शन आईडी से जुड़ी पाबंदियां
  • 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 एमबी - 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 एमआईबी

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

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

    1500 बाइट

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

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

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

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

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

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

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

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

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

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

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

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

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