原生模式下的 Cloud Firestore 企业版现已推出！了解详情。

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__`	कलेक्शन
शहर	state, `__name__`	कलेक्शन
शहर	देश, जनसंख्या, `__name__`	कलेक्शन

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

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

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

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

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

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

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

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

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

वेब

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"] });test.firestore.js

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

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

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

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

वेब

const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");test.firestore.js

आपके पास 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")

कलेक्शन	इंडेक्स किए गए फ़ील्ड	क्वेरी का स्कोप
शहर	देश, जनसंख्या	कलेक्शन
cities	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
आस-पास के इलाके ASC
neighborhoods DESC
temperatures ASC
temperatures DESC
temperatures.summer ASC
temperatures.summer DESC
temperatures.winter ASC
temperatures.winter DESC
नेबरहुड ऐरे में शामिल है

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

city_name ASC, neighborhoods ARRAY
city_name DESC, neighborhoods ARRAY

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

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

इंडेक्स	इंडेक्स किया गया डेटा
अपने-आप इंडेक्स एंट्री जनरेट होने की सुविधा
city_name ASC	city_name: "San Francisco"
city_name DESC	city_name: "San Francisco"
आस-पास के इलाके ASC	neighborhoods: ["Mission", "Downtown", "Marina"]
neighborhoods DESC	neighborhoods: ["Mission", "Downtown", "Marina"]
temperatures ASC	तापमान: {summer: 67, winter: 55}
temperatures DESC	तापमान: {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
नेबरहुड ऐरे में शामिल है	पड़ोस: "मिशन"
नेबरहुड ऐरे में शामिल है	आस-पास के इलाके: "डाउनटाउन"
नेबरहुड ऐरे में शामिल है	आस-पास के इलाके: "मरीना"
मैन्युअल तरीके से इंडेक्स की गई एंट्री
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	कलेक्शन
रेस्टोरेंट	city, star_rating	कलेक्शन
रेस्टोरेंट	category, city, star_rating	कलेक्शन
रेस्टोरेंट	कैटगरी, शहर, संपादकों की पसंद, स्टार रेटिंग	कलेक्शन

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

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

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

वेब

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

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

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

सीमा	विवरण
किसी डेटाबेस के लिए कंपोज़िट इंडेक्स की ज़्यादा से ज़्यादा संख्या	अगर आपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू नहीं की है, तो 200. अगर आपको ज़्यादा कोटा चाहिए, तो आपको अपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू करनी होगी. Google Cloud प्रोजेक्ट के लिए बिलिंग चालू करने पर 1,000 डॉलर. इस सीमा को बढ़ाने का अनुरोध करने के लिए, सहायता टीम से संपर्क करें.
किसी डेटाबेस के लिए, सिंगल-फ़ील्ड कॉन्फ़िगरेशन की ज़्यादा से ज़्यादा संख्या	अगर आपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू नहीं की है, तो 200. अगर आपको ज़्यादा कोटा चाहिए, तो आपको अपने Google Cloud प्रोजेक्ट के लिए बिलिंग चालू करनी होगी. Google Cloud प्रोजेक्ट के लिए बिलिंग चालू करने पर 1,000 रुपये. एक फ़ील्ड लेवल कॉन्फ़िगरेशन में, एक ही फ़ील्ड के लिए कई कॉन्फ़िगरेशन हो सकते हैं. उदाहरण के लिए, एक ही फ़ील्ड के लिए इंडेक्सिंग से छूट और टीटीएल की नीति को सीमा के हिसाब से एक फ़ील्ड कॉन्फ़िगरेशन माना जाता है.
हर दस्तावेज़ के लिए इंडेक्स एंट्री की ज़्यादा से ज़्यादा संख्या	40,000 किसी दस्तावेज़ के लिए इंडेक्स एंट्री की संख्या, इन सभी का योग होती है: सिंगल-फ़ील्ड इंडेक्स एंट्री की संख्या कंपोज़िट इंडेक्स की एंट्री की संख्या Cloud Firestore किसी दस्तावेज़ और इंडेक्स के सेट को इंडेक्स एंट्री में कैसे बदलता है, यह जानने के लिए इंडेक्स एंट्री की संख्या का यह उदाहरण देखें.
कंपोज़िट इंडेक्स में ज़्यादा से ज़्यादा फ़ील्ड	100
इंडेक्स एंट्री का ज़्यादा से ज़्यादा साइज़	7.5 केआईबी Cloud Firestore इंडेक्स एंट्री के साइज़ का हिसाब कैसे लगाता है, यह जानने के लिए इंडेक्स एंट्री का साइज़ लेख पढ़ें.
किसी दस्तावेज़ की इंडेक्स एंट्री के साइज़ का ज़्यादा से ज़्यादा योग	8 एमआईबी किसी दस्तावेज़ का कुल साइज़, इन चीज़ों का योग होता है: किसी दस्तावेज़ की सिंगल-फ़ील्ड इंडेक्स एंट्री के साइज़ का योग किसी दस्तावेज़ के कंपोज़िट इंडेक्स की एंट्री के साइज़ का योग
इंडेक्स किए गए फ़ील्ड की वैल्यू का ज़्यादा से ज़्यादा साइज़	1,500 बाइट 1,500 बाइट से ज़्यादा की फ़ील्ड वैल्यू को छोटा कर दिया जाता है. काटी गई फ़ील्ड वैल्यू वाली क्वेरी से, अलग-अलग नतीजे मिल सकते हैं.

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

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

कारक	ब्यौरा
बड़े स्ट्रिंग फ़ील्ड	अगर आपके पास कोई ऐसा स्ट्रिंग फ़ील्ड है जिसमें अक्सर लंबी स्ट्रिंग वैल्यू होती हैं और जिनका इस्तेमाल क्वेरी करने के लिए नहीं किया जाता है, तो फ़ील्ड को इंडेक्सिंग से बाहर रखकर स्टोरेज की लागत कम की जा सकती है.
ऐसे कलेक्शन में दस्तावेज़ों को लिखने की ज़्यादा दरें जिनमें क्रम से वैल्यू होती हैं	अगर आपने किसी ऐसे फ़ील्ड को इंडेक्स किया है जिसकी वैल्यू, कलेक्शन में मौजूद दस्तावेज़ों के बीच क्रम से बढ़ती या घटती है, तो कलेक्शन में डेटा लिखने की ज़्यादा से ज़्यादा दर 500 बार प्रति सेकंड होती है. जैसे, टाइमस्टैंप. अगर आपने क्रम से दी गई वैल्यू वाले फ़ील्ड के आधार पर क्वेरी नहीं की है, तो इस सीमा को बायपास करने के लिए, फ़ील्ड को इंडेक्सिंग से बाहर रखा जा सकता है. अगर IoT के इस्तेमाल के ऐसे उदाहरण में डेटा को तेज़ी से लिखा जाता है जहां हर सेकंड में कई बार डेटा लिखा जाता है, तो हो सकता है कि टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ों का कलेक्शन, हर सेकंड में 500 बार डेटा लिखे जाने की सीमा के करीब पहुंच जाए.
टीटीएल फ़ील्ड	अगर टीटीएल (टाइम-टू-लिव) नीतियों का इस्तेमाल किया जाता है, तो ध्यान दें कि टीटीएल फ़ील्ड में टाइमस्टैंप होना चाहिए. टीटीएल फ़ील्ड पर इंडेक्सिंग की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इससे ज़्यादा ट्रैफ़िक रेट पर परफ़ॉर्मेंस पर असर पड़ सकता है. सबसे सही तरीका यह है कि टीटीएल फ़ील्ड के लिए, अपने-आप इंडेक्स होने से जुड़ी छूट जोड़ें.
बड़ी कैटगरी या मैप फ़ील्ड	बड़े ऐरे या मैप फ़ील्ड, हर दस्तावेज़ के लिए इंडेक्स की 40,000 एंट्री की सीमा के करीब पहुंच सकते हैं. अगर आपको किसी बड़े ऐरे या मैप फ़ील्ड के आधार पर क्वेरी नहीं करनी है, तो आपको उसे इंडेक्स करने से रोकना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

इंडेक्स मोड

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

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

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

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

वेब

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

वेब

वेब

वेब

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

वेब

वेब

वेब

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

वेब

वेब

वेब

वेब

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

दस्तावेज़

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

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

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

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

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

वेब

वेब

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

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

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