Cloud Firestore में इंडेक्स टाइप

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

इस पेज पर, Cloud Firestore के इस्तेमाल किए जाने वाले दो तरह के इंडेक्स के बारे में बताया गया है: अपने-आप तैयार होने वाले इंडेक्स और मैन्युअल इंडेक्स.

इंडेक्स की परिभाषा और स्ट्रक्चर

किसी दस्तावेज़ के फ़ील्ड की सूची पर इंडेक्स तय किया जाता है. साथ ही, हर फ़ील्ड के लिए उससे जुड़ा इंडेक्स मोड तय किया जाता है.

किसी इंडेक्स में, इंडेक्स की परिभाषा में बताए गए हर फ़ील्ड के लिए एक एंट्री होती है. इंडेक्स में वे सभी दस्तावेज़ शामिल होते हैं जो इंडेक्स पर आधारित क्वेरी के संभावित नतीजे होते हैं. किसी दस्तावेज़ को इंडेक्स में सिर्फ़ तब शामिल किया जाता है, जब इंडेक्स में इस्तेमाल किए गए हर फ़ील्ड के लिए इंडेक्स की गई वैल्यू सेट की गई हो. अगर इंडेक्स की परिभाषा में ऐसे फ़ील्ड का रेफ़रंस दिया गया है जिसके लिए दस्तावेज़ में कोई वैल्यू सेट नहीं है, तो वह दस्तावेज़ इंडेक्स में नहीं दिखेगा. इस मामले में, इंडेक्स पर आधारित किसी भी क्वेरी के नतीजे के तौर पर दस्तावेज़ कभी नहीं दिखाया जाएगा.

इंडेक्स को फ़ील्ड वैल्यू के हिसाब से क्रम में लगाया जाता है. यह क्रम, इंडेक्स की परिभाषा में तय किया जाता है.

हर क्वेरी के पीछे एक इंडेक्स

अगर किसी क्वेरी के लिए कोई इंडेक्स मौजूद नहीं है, तो ज़्यादातर डेटाबेस अपने कॉन्टेंट को एक-एक करके क्रॉल करते हैं. यह एक धीमी प्रोसेस है. डेटाबेस के बढ़ने के साथ-साथ यह प्रोसेस और धीमी हो जाती है. Cloud Firestore, सभी क्वेरी के लिए इंडेक्स का इस्तेमाल करके, क्वेरी की बेहतर परफ़ॉर्मेंस देने में मदद करता है. इसलिए, क्वेरी की परफ़ॉर्मेंस, नतीजे के सेट के साइज़ पर निर्भर करती है. यह डेटाबेस में मौजूद आइटम की संख्या पर निर्भर नहीं करती.

इंडेक्स को मैनेज करने में कम समय लगता है और ऐप्लिकेशन को डेवलप करने में ज़्यादा समय मिलता है

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

इंडेक्स के टाइप

Cloud Firestore दो तरह के इंडेक्स का इस्तेमाल करता है: ऑटोमैटिक और मैन्युअल. मैन्युअल और अपने-आप जनरेट होने वाले इंडेक्स को मैनेज करने का तरीका अलग-अलग होता है.

अपने-आप बनने वाले इंडेक्स

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

अपने-आप बनने वाली इंडेक्स फ़ाइलों की डिफ़ॉल्ट सेटिंग

Cloud Firestore अपने-आप इंडेक्स बनाने की सुविधा के लिए, इन डिफ़ॉल्ट सेटिंग का इस्तेमाल करता है:

  • ऐरे और मैप फ़ील्ड के अलावा, हर फ़ील्ड के लिए Cloud Firestore दो collection-scope इंडेक्स तय करता है. इनमें से एक इंडेक्स, बढ़ते क्रम में होता है और दूसरा घटते क्रम में.

  • हर मैप फ़ील्ड के लिए, Cloud Firestore ये बनाता है:

    • ऐरे और मैप नहीं किए गए हर सब-फ़ील्ड के लिए, कलेक्शन-स्कोप वाला एक बढ़ता हुआ इंडेक्स.
    • हर नॉन-ऐरे और नॉन-मैप सब-फ़ील्ड के लिए, कलेक्शन-स्कोप वाला एक डिसेंडिंग इंडेक्स.
    • पूरी मैप वैल्यू के लिए, कलेक्शन-स्कोप वाला एक बढ़ता हुआ इंडेक्स
    • पूरी मैप वैल्यू के लिए, कलेक्शन-स्कोप वाला डिसेंडिंग इंडेक्स
    • हर ऐरे सबफ़ील्ड के लिए, कलेक्शन-स्कोप वाला एक array-contains इंडेक्स.
    • Cloud Firestore हर मैप सबफ़ील्ड को बार-बार इंडेक्स करता है.
  • किसी दस्तावेज़ में मौजूद हर कलेक्शन फ़ील्ड के लिए, Cloud Firestore ये चीज़ें बनाता है:

    • पूरी ऐरे वैल्यू के लिए, कलेक्शन-स्कोप वाला एक बढ़ता हुआ इंडेक्स
    • पूरी ऐरे वैल्यू के लिए, कलेक्शन-स्कोप वाला डिसेंडिंग इंडेक्स
    • कलेक्शन के स्कोप वाला एक array-contains इंडेक्स.
  • कलेक्शन ग्रुप के स्कोप वाले ऑटोमैटिक इंडेक्स, डिफ़ॉल्ट रूप से मैनेज नहीं किए जाते.

अपने-आप इंडेक्स होने से जुड़ी छूट

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

कलेक्शन ग्रुप के सभी फ़ील्ड पर, कलेक्शन-लेवल के इंडेक्स से जुड़ी छूट जोड़ने के लिए, * फ़ील्ड पाथ वैल्यू का इस्तेमाल करें. उदाहरण के लिए, कलेक्शन ग्रुप comments के लिए, फ़ील्ड पाथ को * पर सेट करें, ताकि comments कलेक्शन ग्रुप के सभी फ़ील्ड मैच हो जाएं. साथ ही, कलेक्शन ग्रुप के सभी फ़ील्ड की इंडेक्सिंग बंद हो जाए. इसके बाद, सिर्फ़ उन फ़ील्ड को इंडेक्स करने के लिए छूट दी जा सकती है जिनकी ज़रूरत आपकी क्वेरी के लिए है. इंडेक्स किए गए फ़ील्ड की संख्या कम करने से, स्टोरेज की लागत कम हो जाती है. साथ ही, इससे लिखने की परफ़ॉर्मेंस बेहतर हो सकती है.

अगर किसी मैप फ़ील्ड के लिए इंडेक्सिंग से छूट दी जाती है, तो मैप के सब-फ़ील्ड में वे सेटिंग अपने-आप लागू हो जाती हैं. हालांकि, कुछ सब-फ़ील्ड के लिए इंडेक्सिंग से छूट दी जा सकती है. किसी सब-फ़ील्ड के लिए छूट मिटाने पर, सब-फ़ील्ड में छूट की सेटिंग उसके पैरंट फ़ील्ड से इनहेरिट हो जाएंगी. ऐसा तब होगा, जब पैरंट फ़ील्ड के लिए छूट की सेटिंग मौजूद हों. अगर पैरंट फ़ील्ड के लिए छूट की सेटिंग मौजूद नहीं हैं, तो डेटाबेस-वाइड सेटिंग लागू होंगी.

अपने-आप इंडेक्स होने से छूट पाने की सुविधा को बनाने और मैनेज करने के लिए, इंडेक्स मैनेज करना लेख पढ़ें.

मैन्युअल इंडेक्स

मैन्युअल इंडेक्स में, किसी कलेक्शन में मौजूद सभी दस्तावेज़ों की क्रम से लगाई गई मैपिंग सेव होती है. यह मैपिंग, इंडेक्स किए जाने वाले फ़ील्ड की क्रम से लगाई गई सूची पर आधारित होती है.

Cloud Firestore मैन्युअल इंडेक्स का इस्तेमाल करता है, ताकि उन क्वेरी को सपोर्ट किया जा सके जिन्हें ऑटोमैटिक इंडेक्स पहले से सपोर्ट नहीं करते.

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

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

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

इंडेक्स मोड और क्वेरी स्कोप

ऑटोमैटिक और मैन्युअल इंडेक्स को अलग-अलग तरीके से कॉन्फ़िगर किया जाता है. हालांकि, दोनों के लिए यह ज़रूरी है कि आप अपने इंडेक्स के लिए इंडेक्स मोड और क्वेरी स्कोप कॉन्फ़िगर करें.

इंडेक्स के मोड

इंडेक्स तय करते समय, इंडेक्स किए गए हर फ़ील्ड के लिए इंडेक्स मोड चुना जाता है. हर फ़ील्ड का इंडेक्स मोड, उस फ़ील्ड पर खास क्वेरी क्लॉज़ के साथ काम करता है. इनमें से कोई इंडेक्स मोड चुना जा सकता है:

इंडेक्स मोड ब्यौरा
बढ़ते क्रम में यह <, <=, ==, >=, >, !=, in, और not-in के साथ-साथ फ़ील्ड पर क्वेरी क्लॉज़ का इस्तेमाल करने की सुविधा देता है. साथ ही, इस फ़ील्ड की वैल्यू के आधार पर नतीजों को बढ़ते क्रम में क्रम से लगाने की सुविधा देता है.
घटते क्रम में यह फ़ील्ड पर <, <=, ==, >=, >, !=, in, और not-in क्वेरी क्लॉज़ के साथ काम करता है. साथ ही, इस फ़ील्ड की वैल्यू के आधार पर, नतीजों को घटते क्रम में क्रमबद्ध करने की सुविधा देता है.
array‑contains यह फ़ील्ड पर array-contains और array-contains-any क्वेरी क्लॉज़ के साथ काम करता है.
वेक्टर इस फ़ील्ड पर FindNearest क्वेरी क्लॉज़ काम करते हैं.

क्वेरी के स्कोप

हर इंडेक्स का दायरा, किसी कलेक्शन या कलेक्शन ग्रुप तक सीमित होता है. इसे इंडेक्स की क्वेरी स्कोप के तौर पर जाना जाता है:

कलेक्शन का स्कोप
Cloud Firestore डिफ़ॉल्ट रूप से, कलेक्शन स्कोप वाले इंडेक्स बनाता है. ये इंडेक्स, ऐसी क्वेरी के साथ काम करते हैं जो किसी एक कलेक्शन से नतीजे दिखाती हैं.

कलेक्शन ग्रुप का स्कोप
कलेक्शन ग्रुप में, एक ही कलेक्शन आईडी वाले सभी कलेक्शन शामिल होते हैं. कलेक्शन ग्रुप क्वेरी चलाने के लिए, आपको कलेक्शन ग्रुप के स्कोप वाला इंडेक्स बनाना होगा. इससे कलेक्शन ग्रुप से फ़िल्टर किए गए या क्रम से लगाए गए नतीजे मिलते हैं.

डिफ़ॉल्ट क्रम और __name__ फ़ील्ड

हर फ़ील्ड के लिए तय किए गए इंडेक्स मोड (बढ़ते या घटते क्रम में) के हिसाब से दस्तावेज़ों को क्रम से लगाने के अलावा, इंडेक्स हर दस्तावेज़ के __name__ फ़ील्ड के हिसाब से, क्रम से लगाने की सुविधा भी देते हैं. __name__ फ़ील्ड की वैल्यू, पूरे दस्तावेज़ के पाथ पर सेट की जाती है. इसका मतलब है कि नतीजे के सेट में, एक जैसी फ़ील्ड वैल्यू वाले दस्तावेज़ों को दस्तावेज़ के पाथ के हिसाब से क्रम में लगाया जाता है.

डिफ़ॉल्ट रूप से, __name__ फ़ील्ड को इंडेक्स की परिभाषा में, क्रम से लगाए गए आखिरी फ़ील्ड के हिसाब से क्रम से लगाया जाता है. उदाहरण के लिए:

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
शहर नाम, __name__ कलेक्शन
शहर राज्य, __name__ कलेक्शन
शहर देश, जनसंख्या, __name__ कलेक्शन

नतीजों को नॉन-डिफ़ॉल्ट __name__ के हिसाब से क्रम से लगाने के लिए, आपको वह इंडेक्स बनाना होगा.

इंडेक्स प्रॉपर्टी

क्वेरी को सबसे असरदार तरीके से चलाने की अनुमति देने वाले इंडेक्स को इन प्रॉपर्टी के हिसाब से तय किया जाता है:

  • समानता वाले फ़िल्टर में इस्तेमाल किए गए फ़ील्ड
  • सॉर्ट करने के क्रम में इस्तेमाल किए गए फ़ील्ड
  • रेंज और असमानता वाले फ़िल्टर में इस्तेमाल किए गए फ़ील्ड (जो पहले से ही क्रम में शामिल नहीं हैं)
  • एग्रीगेशन में इस्तेमाल किए गए फ़ील्ड (जो पहले से ही क्रम से लगाने, रेंज, और असमानता वाले फ़िल्टर में शामिल नहीं हैं)

Cloud Firestore, क्वेरी के नतीजे इस तरह से दिखाता है:

  1. इससे क्वेरी के कलेक्शन, फ़िल्टर प्रॉपर्टी, फ़िल्टर ऑपरेटर, और क्रम से लगाने के तरीकों से जुड़े इंडेक्स की पहचान होती है.
  2. यह उस इंडेक्स की पहचान करता है जहां से स्कैनिंग शुरू होती है. शुरुआत की पोज़िशन में, क्वेरी के समानता वाले फ़िल्टर पहले से जुड़े होते हैं. साथ ही, यह पहले orderBy फ़ील्ड पर रेंज और असमानता वाले फ़िल्टर के साथ खत्म होती है.
  3. यह इंडेक्स को स्कैन करना शुरू करता है. साथ ही, हर उस दस्तावेज़ को दिखाता है जो सभी फ़िल्टर की शर्तों को पूरा करता है. यह तब तक ऐसा करता है, जब तक स्कैनिंग की प्रोसेस इनमें से कोई एक काम न कर ले:
    • फ़िल्टर करने की शर्तों को पूरा न करने वाला कोई दस्तावेज़ मिलता है और पुष्टि करता है कि इसके बाद मिलने वाला कोई भी दस्तावेज़, फ़िल्टर करने की शर्तों को कभी पूरी तरह से पूरा नहीं करेगा.
    • इंडेक्स के आखिर तक पहुंच जाता है.
    • यह क्वेरी में अनुरोध किए गए ज़्यादा से ज़्यादा नतीजे इकट्ठा करता है.

इंडेक्स करने का उदाहरण

Cloud Firestore आपके लिए सिंगल-फ़ील्ड इंडेक्स अपने-आप बनाता है. इससे आपका ऐप्लिकेशन, डेटाबेस की सबसे बुनियादी क्वेरी को तुरंत सपोर्ट कर पाता है. सिंगल-फ़ील्ड इंडेक्स की मदद से, फ़ील्ड वैल्यू और तुलना करने वाले ऑपरेटर <, <=, ==, >=, >, और in के आधार पर सामान्य क्वेरी की जा सकती हैं. ऐरे फ़ील्ड के लिए, ये array-contains और array-contains-any क्वेरी चलाने की अनुमति देते हैं.

उदाहरण के लिए, इंडेक्स बनाने के नज़रिए से यहां दिए गए उदाहरणों को देखें. यहां दिए गए स्निपेट में, cities कलेक्शन में कुछ city दस्तावेज़ बनाए गए हैं. साथ ही, हर दस्तावेज़ के लिए name, state, country, capital, population, और regions फ़ील्ड सेट किए गए हैं:

वेब
var citiesRef = db.collection("cities");

citiesRef.doc("SF").set({
    name: "San Francisco", state: "CA", country: "USA",
    capital: false, population: 860000,
    regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
    name: "Los Angeles", state: "CA", country: "USA",
    capital: false, population: 3900000,
    regions: ["west_coast", "socal"] });
citiesRef.doc("DC").set({
    name: "Washington, D.C.", state: null, country: "USA",
    capital: true, population: 680000,
    regions: ["east_coast"] });
citiesRef.doc("TOK").set({
    name: "Tokyo", state: null, country: "Japan",
    capital: true, population: 9000000,
    regions: ["kanto", "honshu"] });
citiesRef.doc("BJ").set({
    name: "Beijing", state: null, country: "China",
    capital: true, population: 21500000,
    regions: ["jingjinji", "hebei"] });

ऑटोमैटिक इंडेक्सिंग की डिफ़ॉल्ट सेटिंग के हिसाब से, Cloud Firestore हर फ़ील्ड के लिए एक एसेंडिंग सिंगल-फ़ील्ड इंडेक्स, हर फ़ील्ड के लिए एक डिसेंडिंग सिंगल-फ़ील्ड इंडेक्स, और ऐरे फ़ील्ड के लिए एक array-contains सिंगल-फ़ील्ड इंडेक्स अपडेट करता है. नीचे दी गई टेबल की हर लाइन, सिंगल-फ़ील्ड इंडेक्स में मौजूद किसी एंट्री को दिखाती है:

कलेक्शन फ़ील्ड को इंडेक्स किया गया क्वेरी का दायरा
शहर का नाम कलेक्शन
शहर राज्य कलेक्शन
शहर देश कलेक्शन
शहर कैपिटल लेटर कलेक्शन
शहर जनसंख्या कलेक्शन
शहर देश/इलाके कलेक्शन
शहर नाम कलेक्शन
शहर राज्य कलेक्शन
शहर देश कलेक्शन
शहर कैपिटल कलेक्शन
शहर जनसंख्या कलेक्शन
शहर देश/इलाके कलेक्शन
शहर array-contains देश/इलाके कलेक्शन

सिंगल-फ़ील्ड इंडेक्स के साथ काम करने वाली क्वेरी

अपने-आप बनाए गए इन सिंगल-फ़ील्ड इंडेक्स का इस्तेमाल करके, इस तरह की सामान्य क्वेरी चलाई जा सकती हैं:

वेब
const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");

आपके पास in और कंपाउंड इक्वैलिटी (==) क्वेरी बनाने का विकल्प भी है:

वेब
citiesRef.where('country', 'in', ["USA", "Japan", "China"])

// Compound equality queries
citiesRef.where("state", "==", "CO").where("name", "==", "Denver")
citiesRef.where("country", "==", "USA")
         .where("capital", "==", false)
         .where("state", "==", "CA")
         .where("population", "==", 860000)

अगर आपको रेंज की तुलना (<, <=, > या >=) करने वाली कोई कंपाउंड क्वेरी चलानी है या आपको किसी दूसरे फ़ील्ड के हिसाब से क्रम से लगाना है, तो आपको उस क्वेरी के लिए मैन्युअल इंडेक्स बनाना होगा.

array-contains इंडेक्स की मदद से, regions ऐरे फ़ील्ड को क्वेरी किया जा सकता है:

वेब
citiesRef.where("regions", "array-contains", "west_coast")
// array-contains-any and array-contains use the same indexes
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])

मैन्युअल इंडेक्स के साथ काम करने वाली क्वेरी

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

वेब
citiesRef.where("country", "==", "USA").orderBy("population", "asc")
citiesRef.where("country", "==", "USA").where("population", "<", 3800000)
citiesRef.where("country", "==", "USA").where("population", ">", 690000)
// in and == clauses use the same index
citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)

इन क्वेरी के लिए, इस इंडेक्स की ज़रूरत होती है. क्वेरी में country फ़ील्ड के लिए, समानता (== या in) का इस्तेमाल किया जाता है. इसलिए, इस फ़ील्ड के लिए एसेंडिंग या डिसेंडिंग इंडेक्स मोड का इस्तेमाल किया जा सकता है. डिफ़ॉल्ट रूप से, असमानता वाले क्लॉज़ में, असमानता वाले क्लॉज़ के फ़ील्ड के आधार पर बढ़ते क्रम में सॉर्ट करने का नियम लागू होता है.

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
शहर (या ) देश, जनसंख्या कलेक्शन

अगर आपको एक ही क्वेरी को घटते क्रम में सॉर्ट करके चलाना है, तो आपको population के लिए घटते क्रम में एक अतिरिक्त इंडेक्स की ज़रूरत होगी:

वेब
citiesRef.where("country", "==", "USA").orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", "<", 3800000)
         .orderBy("population", "desc")

citiesRef.where("country", "==", "USA")
         .where("population", ">", 690000)
         .orderBy("population", "desc")

citiesRef.where("country", "in", ["USA", "Japan", "China"])
         .where("population", ">", 690000)
         .orderBy("population", "desc")
कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
शहर देश, जनसंख्या कलेक्शन
शहर country, population कलेक्शन

इंडेक्स मर्ज करने की वजह से परफ़ॉर्मेंस में होने वाले नुकसान से बचने के लिए, हमारा सुझाव है कि आप array-contains या array-contains-any क्वेरी को अन्य क्लॉज़ के साथ मिलाकर एक इंडेक्स बनाएं:

वेब
citiesRef.where("regions", "array-contains", "east_coast")
         .where("capital", "==", true)

// array-contains-any and array-contains use the same index
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
         .where("capital", "==", true)
कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
शहर array-contains टैग, (या ) कैपिटल कलेक्शन

कलेक्शन ग्रुप इंडेक्स के साथ काम करने वाली क्वेरी

कलेक्शन ग्रुप के स्कोप वाले इंडेक्स को दिखाने के लिए, कुछ city दस्तावेज़ों में landmarks सब-कलेक्शन जोड़ें:

वेब
var citiesRef = db.collection("cities");

citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Bridge",
    category : "bridge" });
citiesRef.doc("SF").collection("landmarks").doc().set({
    name: "Golden Gate Park",
    category : "park" });

citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Gallery of Art",
    category : "museum" });
citiesRef.doc("DC").collection("landmarks").doc().set({
    name: "National Mall",
    category : "park" });

कलेक्शन के स्कोप वाले इस सिंगल-फ़ील्ड इंडेक्स का इस्तेमाल करके, category फ़ील्ड के आधार पर किसी शहर के landmarks कलेक्शन के बारे में क्वेरी की जा सकती है:

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
लैंडमार्क (या ) कैटगरी कलेक्शन
वेब
citiesRef.doc("SF").collection("landmarks").where("category", "==", "park")
citiesRef.doc("SF").collection("landmarks").where("category", "in", ["park", "museum"])

अगर आपको सभी शहरों के लैंडमार्क के बारे में क्वेरी करनी है, तो उदाहरण के लिए, आपको इस क्वेरी को उस कलेक्शन ग्रुप पर चलाना होगा जिसमें सभी landmarksकलेक्शन शामिल हैं. आपको कलेक्शन ग्रुप के स्कोप वाला landmarks सिंगल-फ़ील्ड इंडेक्स भी चालू करना होगा:

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
लैंडमार्क (या ) कैटगरी कलेक्शन ग्रुप

इस इंडेक्स को चालू करने पर, landmarks कलेक्शन ग्रुप से क्वेरी की जा सकती है:

वेब
var landmarksGroupRef = db.collectionGroup("landmarks");

landmarksGroupRef.where("category", "==", "park")
landmarksGroupRef.where("category", "in", ["park", "museum"])

कलेक्शन ग्रुप की क्वेरी चलाने के लिए, आपको कलेक्शन ग्रुप के स्कोप वाला इंडेक्स चालू करना होगा. इससे फ़िल्टर किए गए या क्रम से लगाए गए नतीजे दिखेंगे. हालांकि, कलेक्शन ग्रुप की ऐसी क्वेरी के लिए इंडेक्स की कोई अतिरिक्त परिभाषा ज़रूरी नहीं होती है जो नतीजों को फ़िल्टर या क्रम से नहीं लगाती हैं.

उदाहरण के लिए, किसी अतिरिक्त इंडेक्स को चालू किए बिना, कलेक्शन ग्रुप की इस क्वेरी को चलाया जा सकता है:

वेब
db.collectionGroup("landmarks").get()

इंडेक्स एंट्री

आपके प्रोजेक्ट के कॉन्फ़िगर किए गए इंडेक्स और किसी दस्तावेज़ का स्ट्रक्चर यह तय करता है कि किसी दस्तावेज़ के लिए इंडेक्स एंट्री की संख्या कितनी होगी. इंडेक्स की एंट्री, इंडेक्स की एंट्री की संख्या की सीमा में शामिल होती हैं.

यहां दिए गए उदाहरण में, किसी दस्तावेज़ की इंडेक्स एंट्री दिखाई गई हैं.

दस्तावेज़

/cities/SF

city_name : "San Francisco"
temperatures : {summer: 67, winter: 55}
neighborhoods : ["Mission", "Downtown", "Marina"]

अपने-आप बनने वाले इंडेक्स

  • city_name ASC
  • city_name DESC
  • आस-पास के इलाके के हिसाब से बढ़ते क्रम में
  • neighborhoods DESC
  • तापमान के हिसाब से बढ़ते क्रम में
  • temperatures DESC
  • temperatures.summer ASC
  • temperatures.summer DESC
  • temperatures.winter ASC
  • temperatures.winter DESC
  • neighborhoods Array Contains

मैन्युअल इंडेक्स

  • city_name ASC, neighborhoods ARRAY
  • city_name DESC, neighborhoods ARRAY

इंडेक्स एंट्री

इस इंडेक्सिंग कॉन्फ़िगरेशन से, दस्तावेज़ के लिए इंडेक्स की ये एंट्री मिलती हैं:

इंडेक्स इंडेक्स किया गया डेटा
अपने-आप इंडेक्स एंट्री बनने की सुविधा
city_name ASC city_name: "San Francisco"
city_name DESC city_name: "San Francisco"
आस-पास के इलाके के हिसाब से बढ़ते क्रम में neighborhoods: ["Mission", "Downtown", "Marina"]
neighborhoods DESC neighborhoods: ["Mission", "Downtown", "Marina"]
तापमान के हिसाब से बढ़ते क्रम में temperatures: {summer: 67, winter: 55}
temperatures DESC temperatures: {summer: 67, winter: 55}
temperatures.summer ASC temperatures.summer: 67
temperatures.summer DESC temperatures.summer: 67
temperatures.winter ASC temperatures.winter: 55
temperatures.winter DESC temperatures.winter: 55
neighborhoods Array Contains पड़ोस: "मिशन"
neighborhoods Array Contains पड़ोस: "डाउनटाउन"
neighborhoods Array Contains पड़ोस: "मरीना"
मैन्युअल इंडेक्स एंट्री
city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Mission"
city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Downtown"
city_name ASC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Marina"
city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Mission"
city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Downtown"
city_name DESC, neighborhoods ARRAY city_name: "San Francisco", neighborhoods: "Marina"

इंडेक्स और कीमत

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

इंडेक्स मर्ज करने की सुविधा का इस्तेमाल करना

Cloud Firestore हर क्वेरी के लिए इंडेक्स का इस्तेमाल करता है. हालांकि, हर क्वेरी के लिए एक इंडेक्स की ज़रूरत नहीं होती. एक से ज़्यादा समानता (==) क्लॉज़ वाली क्वेरी और ज़रूरत पड़ने पर orderBy क्लॉज़ के लिए, Cloud Firestore मौजूदा इंडेक्स का फिर से इस्तेमाल कर सकता है. Cloud Firestore, सामान्य समानता वाले फ़िल्टर के लिए इंडेक्स को मर्ज कर सकता है, ताकि समानता वाली बड़ी क्वेरी के लिए ज़रूरी इंडेक्स बनाए जा सकें.

इंडेक्सिंग की लागत को कम किया जा सकता है. इसके लिए, उन स्थितियों की पहचान करें जहां इंडेक्स मर्जिंग का इस्तेमाल किया जा सकता है. उदाहरण के लिए, रेस्टोरेंट की रेटिंग देने वाले ऐप्लिकेशन के लिए restaurants कलेक्शन में:

  • रेस्टोरेंट

    • burgerthyme

      name : "Burger Thyme"
      category : "burgers"
      city : "San Francisco"
      editors_pick : true
      star_rating : 4

यह ऐप्लिकेशन, इस तरह की क्वेरी का इस्तेमाल करता है. यह ऐप्लिकेशन, category, city, और editors_pick के लिए समानता वाले क्लॉज़ के कॉम्बिनेशन का इस्तेमाल करता है. हालांकि, यह हमेशा star_rating के बढ़ते क्रम के हिसाब से क्रम में लगाता है:

वेब
db.collection("restaurants").where("category", "==", "burgers")
                            .orderBy("star_rating")

db.collection("restaurants").where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .orderBy("star_rating")

db.collection("restaurants").where("category", "==", "burgers")
                            .where("city", "==", "San Francisco")
                            .where("editors_pick", "==", true )
                            .orderBy("star_rating")

हर क्वेरी के लिए एक इंडेक्स बनाया जा सकता है:

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
रेस्टोरेंट category, star_rating कलेक्शन
रेस्टोरेंट शहर, star_rating कलेक्शन
रेस्टोरेंट कैटगरी, शहर, star_rating कलेक्शन
रेस्टोरेंट कैटगरी, शहर, संपादकों की पसंद, स्टार रेटिंग कलेक्शन

बेहतर समाधान के तौर पर, समानता वाले क्लॉज़ के लिए इंडेक्स मर्ज करने की Cloud Firestore की सुविधा का इस्तेमाल करके, इंडेक्स की संख्या कम की जा सकती है:

कलेक्शन इंडेक्स किए गए फ़ील्ड क्वेरी का दायरा
रेस्टोरेंट category, star_rating कलेक्शन
रेस्टोरेंट शहर, star_rating कलेक्शन
रेस्टोरेंट editors_pick, star_rating कलेक्शन

यह इंडेक्स सेट छोटा होने के साथ-साथ, एक और क्वेरी के साथ काम करता है:

वेब
db.collection("restaurants").where("editors_pick", "==", true)
                            .orderBy("star_rating")

इंडेक्स करने की सीमाएं

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

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

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

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

40,000

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

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

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

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

7.5 केआईबी

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

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

8 एमआईबी

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

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

    1,500 बाइट

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

    इंडेक्स करने के सबसे सही तरीके

    ज़्यादातर ऐप्लिकेशन के लिए, अपने-आप इंडेक्स होने की सुविधा का इस्तेमाल किया जा सकता है. साथ ही, गड़बड़ी के मैसेज में दिए गए लिंक पर जाकर, अपने इंडेक्स मैनेज किए जा सकते हैं. हालांकि, इन मामलों में आपको अपने-आप इंडेक्स होने की सुविधा से छूट मिल सकती है:

    कारक ब्यौरा
    बड़े स्ट्रिंग फ़ील्ड

    अगर आपके पास कोई ऐसा स्ट्रिंग फ़ील्ड है जिसमें अक्सर लंबी स्ट्रिंग वैल्यू होती हैं और जिनका इस्तेमाल क्वेरी करने के लिए नहीं किया जाता है, तो फ़ील्ड को इंडेक्सिंग से बाहर रखकर स्टोरेज की लागत कम की जा सकती है.

    ऐसे कलेक्शन में दस्तावेज़ों को लिखने की ज़्यादा दरें जिनमें क्रम से वैल्यू होती हैं

    अगर आपने किसी ऐसे फ़ील्ड को इंडेक्स किया है जिसकी वैल्यू, कलेक्शन में मौजूद दस्तावेज़ों के बीच क्रम से बढ़ती या घटती है, जैसे कि टाइमस्टैंप, तो कलेक्शन में डेटा लिखने की ज़्यादा से ज़्यादा दर 500 बार प्रति सेकंड होती है. अगर आपने क्रम से दी गई वैल्यू वाले फ़ील्ड के आधार पर क्वेरी नहीं की है, तो इस सीमा को बायपास करने के लिए, फ़ील्ड को इंडेक्सिंग से हटाया जा सकता है.

    अगर IoT के किसी ऐसे इस्तेमाल के उदाहरण में डेटा को तेज़ी से लिखा जाता है जिसमें टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ शामिल हैं, तो हो सकता है कि वह हर सेकंड 500 बार लिखने की सीमा के करीब पहुंच जाए.

    टीटीएल फ़ील्ड

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

    बड़ी कैटगरी या मैप फ़ील्ड

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

    अगर एक से ज़्यादा फ़ील्ड पर रेंज और असमानता वाले ऑपरेटर के साथ क्वेरी का इस्तेमाल किया जा रहा है, तो Cloud Firestore क्वेरी की परफ़ॉर्मेंस और लागत को ऑप्टिमाइज़ करने के लिए, इंडेक्सिंग से जुड़ी बातों को ध्यान में रखें.

    इंडेक्स करने से जुड़ी समस्याओं (इंडेक्स फ़ैनआउट, INVALID_ARGUMENT गड़बड़ियां) को हल करने के बारे में ज़्यादा जानकारी के लिए, समस्या हल करने वाला पेज देखें.