इंडेक्स, डेटाबेस की परफ़ॉर्मेंस के लिए अहम होते हैं. किसी किताब के विषयों को पेज नंबर पर मैप करने वाले इंडेक्स की तरह ही, डेटाबेस इंडेक्स भी डेटाबेस में मौजूद आइटम को उनकी जगहों पर मैप करता है. किसी डेटाबेस से क्वेरी करने पर, डेटाबेस किसी इंडेक्स का इस्तेमाल करके, आपके अनुरोध किए गए आइटम की जगहों की तुरंत पहचान कर सकता है.
इस पेज पर, उन दो तरह के इंडेक्स के बारे में बताया गया है जिनका इस्तेमाल Cloud Firestore करता है: सिंगल-फ़ील्ड इंडेक्स और कंपोज़िट इंडेक्स.
इंडेक्स की परिभाषा और स्ट्रक्चर
इंडेक्स, किसी दस्तावेज़ के फ़ील्ड की सूची के आधार पर तय किया जाता है. साथ ही, हर फ़ील्ड के लिए एक इंडेक्स मोड तय किया जाता है.
इंडेक्स में, इंडेक्स की परिभाषा में बताए गए हर फ़ील्ड के लिए एक एंट्री होती है. इंडेक्स में वे सभी दस्तावेज़ शामिल होते हैं जो इंडेक्स के आधार पर क्वेरी के संभावित नतीजे होते हैं. किसी दस्तावेज़ को इंडेक्स में सिर्फ़ तब शामिल किया जाता है, जब उसमें इंडेक्स में इस्तेमाल किए गए हर फ़ील्ड के लिए इंडेक्स की गई वैल्यू सेट हो. अगर इंडेक्स की परिभाषा किसी ऐसे फ़ील्ड के बारे में बताती है जिसके लिए दस्तावेज़ में कोई वैल्यू सेट नहीं है, तो वह दस्तावेज़ इंडेक्स में नहीं दिखेगा. इस मामले में, इंडेक्स के आधार पर किसी भी क्वेरी के नतीजे के तौर पर दस्तावेज़ कभी नहीं दिखेगा.
कंपोजिट इंडेक्स को इंडेक्स की परिभाषा में बताए गए क्रम में, फ़ील्ड वैल्यू के हिसाब से क्रम में लगाया जाता है.
हर क्वेरी के पीछे एक इंडेक्स
अगर किसी क्वेरी के लिए कोई इंडेक्स मौजूद नहीं है, तो ज़्यादातर डेटाबेस अपने कॉन्टेंट को आइटम के हिसाब से क्रॉल करते हैं. यह एक धीमी प्रोसेस है, जो डेटाबेस के बढ़ने के साथ और भी धीमी हो जाती है. Cloud Firestore, सभी क्वेरी के लिए इंडेक्स का इस्तेमाल करके, क्वेरी की बेहतर परफ़ॉर्मेंस की गारंटी देता है. इसलिए, क्वेरी की परफ़ॉर्मेंस, नतीजों के सेट के साइज़ पर निर्भर करती है, न कि डेटाबेस में मौजूद आइटम की संख्या पर.
इंडेक्स मैनेज करने में कम समय, ऐप्लिकेशन डेवलप करने में ज़्यादा समय
Cloud Firestore में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, इंडेक्स मैनेजमेंट में लगने वाला समय कम हो जाता है. सबसे बुनियादी क्वेरी के लिए ज़रूरी इंडेक्स, आपके लिए अपने-आप बन जाते हैं. ऐप्लिकेशन का इस्तेमाल और उसकी जांच करने पर, Cloud Firestore आपको उन अतिरिक्त इंडेक्स की पहचान करने और उन्हें बनाने में मदद करता है जिनकी आपके ऐप्लिकेशन को ज़रूरत होती है.
इंडेक्स के टाइप
Cloud Firestore दो तरह के इंडेक्स का इस्तेमाल करता है: सिंगल-फ़ील्ड और कंपोज़िट. इंडेक्स किए गए फ़ील्ड की संख्या के अलावा, एक फ़ील्ड और कॉम्पोनेंट इंडेक्स को मैनेज करने के तरीके भी अलग-अलग होते हैं.
एक फ़ील्ड वाले इंडेक्स
सिंगल-फ़ील्ड इंडेक्स, किसी कलेक्शन में मौजूद उन सभी दस्तावेज़ों की मैपिंग को क्रम से सेव करता है जिनमें कोई खास फ़ील्ड होता है. सिंगल-फ़ील्ड इंडेक्स में मौजूद हर एंट्री, किसी खास फ़ील्ड के लिए दस्तावेज़ की वैल्यू और डेटाबेस में दस्तावेज़ की जगह को रिकॉर्ड करती है. Cloud Firestore कई बुनियादी क्वेरी करने के लिए, इन इंडेक्स का इस्तेमाल करता है. अपने डेटाबेस की ऑटोमैटिक इंडेक्सिंग सेटिंग और इंडेक्स से छूट वाली फ़ील्ड को कॉन्फ़िगर करके, एक फ़ील्ड वाले इंडेक्स को मैनेज किया जा सकता है.
अपने-आप इंडेक्स होना
डिफ़ॉल्ट रूप से, Cloud Firestore किसी दस्तावेज़ के हर फ़ील्ड और मैप के हर सब-फ़ील्ड के लिए, सिंगल-फ़ील्ड इंडेक्स अपने-आप बनाए रखता है. Cloud Firestore एक फ़ील्ड वाले इंडेक्स के लिए, इन डिफ़ॉल्ट सेटिंग का इस्तेमाल करता है:
Cloud Firestore, हर ऐसे फ़ील्ड के लिए दो कलेक्शन-स्कोप सिंगल-फ़ील्ड इंडेक्स तय करता है जो ऐरे और मैप नहीं हैं. इनमें से एक इंडेक्स, बढ़ते क्रम में और दूसरा इंडेक्स, घटते क्रम में होता है.
हर मैप फ़ील्ड के लिए, Cloud Firestore ये बनाता है:
- हर ऐसे सबफ़ील्ड के लिए, कलेक्शन के दायरे में आने वाला एक ऐसा इंडेक्स जो बढ़ते क्रम में हो और न तो ऐरे हो और न ही मैप.
- हर ऐसे सबफ़ील्ड के लिए, कलेक्शन के दायरे में आने वाला एक इंडेक्स, जो ऐरे या मैप नहीं है.
- कलेक्शन के स्कोप वाले अरे में हर अरे सबफ़ील्ड के लिए इंडेक्स शामिल होता है.
- Cloud Firestore हर मैप सबफ़ील्ड को बार-बार इंडेक्स करता है.
किसी दस्तावेज़ में मौजूद हर कलेक्शन के दायरे वाले कलेक्शन के लिए, Cloud Firestore एक कलेक्शन-स्कोप कलेक्शन-कंटेंट इंडेक्स बनाता है और उसे मैनेज करता है.
कलेक्शन ग्रुप के दायरे वाले सिंगल-फ़ील्ड इंडेक्स, डिफ़ॉल्ट रूप से मैनेज नहीं किए जाते.
एक फ़ील्ड वाले इंडेक्स से जुड़ी छूट
किसी फ़ील्ड को अपने-आप इंडेक्स होने की सेटिंग से छूट दी जा सकती है. इसके लिए, एक फ़ील्ड के लिए इंडेक्स करने से छूट देने की सेटिंग बनाएं. इंडेक्स करने से छूट देने की सुविधा, डेटाबेस में इंडेक्स करने की अपने-आप लागू होने वाली सेटिंग को बदल देती है. छूट की वजह से, किसी ऐसे सिंगल-फ़ील्ड इंडेक्स को चालू किया जा सकता है जिसे अपने-आप इंडेक्स करने की सेटिंग बंद कर देती है. इसके अलावा, किसी ऐसे सिंगल-फ़ील्ड इंडेक्स को बंद किया जा सकता है जिसे अपने-आप इंडेक्स करने की सेटिंग चालू कर देती है. जिन मामलों में छूट काम की हो सकती है उनके लिए, इंडेक्स करने के सबसे सही तरीके देखें.
कलेक्शन ग्रुप के सभी फ़ील्ड पर, कलेक्शन-लेवल की इंडेक्स एक्सक्लूज़न जोड़ने के लिए, * फ़ील्ड पाथ वैल्यू का इस्तेमाल करें. उदाहरण के लिए, कलेक्शन ग्रुप comments के लिए, comments कलेक्शन ग्रुप के सभी फ़ील्ड से मैच करने के लिए, फ़ील्ड पाथ को * पर सेट करें और कलेक्शन ग्रुप के तहत सभी फ़ील्ड को इंडेक्स करने की सुविधा बंद करें. इसके बाद, अपनी क्वेरी के लिए ज़रूरी फ़ील्ड को इंडेक्स करने के लिए, छूट जोड़ी जा सकती है. इंडेक्स किए गए फ़ील्ड की संख्या कम करने से, स्टोरेज की लागत कम हो जाती है. साथ ही, डेटा लिखने की परफ़ॉर्मेंस भी बेहतर हो सकती है.
अगर आपने किसी मैप फ़ील्ड के लिए, इंडेक्स में शामिल न किए जाने वाले एक फ़ील्ड की छूट तय की है, तो मैप के सबफ़ील्ड में वे सेटिंग अपने-आप लागू हो जाती हैं. हालांकि, कुछ सब-फ़ील्ड के लिए, एक फ़ील्ड के इंडेक्स से छूट तय की जा सकती है. अगर किसी सबफ़ील्ड के लिए छूट की सेटिंग मिटाई जाती है, तो सबफ़ील्ड को अपने पैरंट की छूट की सेटिंग इनहेरिट हो जाएंगी. अगर पैरंट की छूट की सेटिंग मौजूद नहीं हैं, तो सबफ़ील्ड को डेटाबेस की सभी सेटिंग इनहेरिट हो जाएंगी.
किसी एक फ़ील्ड के लिए इंडेक्स में शामिल न करने की छूट बनाने और उसे मैनेज करने के लिए, इंडेक्स मैनेज करना लेख पढ़ें.
कंपोज़िट इंडेक्स
कंपोजिट इंडेक्स, किसी कलेक्शन में मौजूद सभी दस्तावेज़ों की क्रम से लगाई गई मैपिंग को सेव करता है. यह इंडेक्स करने के लिए, फ़ील्ड की क्रम से लगाई गई सूची के आधार पर ऐसा करता है.
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__ |
कलेक्शन |
| शहर | 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"] });
ऑटोमैटिक इंडेक्स करने की डिफ़ॉल्ट सेटिंग के हिसाब से, Cloud Firestore हर नॉन-ऐरे फ़ील्ड के लिए एक ऐस्कंडिंग सिंगल-फ़ील्ड इंडेक्स, हर नॉन-ऐरे फ़ील्ड के लिए एक डिसऐस्कंडिंग सिंगल-फ़ील्ड इंडेक्स, और ऐरे फ़ील्ड के लिए एक ऐरे-कंटेनिंग सिंगल-फ़ील्ड इंडेक्स अपडेट करता है. नीचे दी गई टेबल की हर लाइन, एक फ़ील्ड वाले इंडेक्स में मौजूद किसी एंट्री को दिखाती है:
| कलेक्शन | फ़ील्ड को इंडेक्स किया गया | क्वेरी का स्कोप |
|---|---|---|
| शहर | नाम | कलेक्शन |
| शहर | स्थिति | कलेक्शन |
| शहर | देश | कलेक्शन |
| शहर | कैपिटल | कलेक्शन |
| शहर | जनसंख्या | कलेक्शन |
| शहर | नाम | कलेक्शन |
| शहर | स्थिति | कलेक्शन |
| शहर | देश | कलेक्शन |
| शहर | कैपिटल | कलेक्शन |
| शहर | जनसंख्या | कलेक्शन |
| शहर | 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"])
कॉम्पोज़िट इंडेक्स के साथ काम करने वाली क्वेरी
Cloud Firestore, कंपोज़िट इंडेक्स का इस्तेमाल करके, ऐसी कंपोज़िट क्वेरी को सपोर्ट करता है जो पहले से सिंगल-फ़ील्ड इंडेक्स के साथ काम नहीं करतीं. उदाहरण के लिए, आपको इन क्वेरी के लिए कॉम्पोज़िट इंडेक्स की ज़रूरत होगी:
वेब
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")
| कलेक्शन | इंडेक्स किए गए फ़ील्ड | क्वेरी का स्कोप |
|---|---|---|
| शहर | देश, जनसंख्या | कलेक्शन |
| शहर | देश, जनसंख्या | कलेक्शन |
इंडेक्स मर्ज करने से परफ़ॉर्मेंस में होने वाली गिरावट से बचने के लिए, हमारा सुझाव है कि आप 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
- temperatures.summer ASC
- temperatures.summer DESC
- temperatures.winter ASC
- temperatures.winter DESC
- neighborhoods कलेक्शन में ये शामिल हैं (ASC और 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" |
| temperatures.summer के लिए, बढ़ते क्रम में | temperatures.summer: 67 |
| temperatures.summer DESC | temperatures.summer: 67 |
| temperatures.winter ASC | temperatures.winter: 55 |
| temperatures.winter DESC | temperatures.winter: 55 |
| neighborhoods कलेक्शन में ASC शामिल है | इलाके: "मिशन" |
| neighborhoods कलेक्शन में DESC शामिल है | इलाके: "मिशन" |
| neighborhoods कलेक्शन में ASC शामिल है | आस-पड़ोस: "डाउनटाउन" |
| neighborhoods कलेक्शन में DESC शामिल है | आस-पड़ोस: "डाउनटाउन" |
| neighborhoods कलेक्शन में ASC शामिल है | आस-पास के इलाके: "मरीना" |
| neighborhoods कलेक्शन में DESC शामिल है | आस-पास के इलाके: "मरीना" |
| कंपोज़िट इंडेक्स एंट्री | |
| 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 | कलेक्शन |
| रेस्टोरेंट | category, city, editors_pick, star_rating | कलेक्शन |
बेहतर समाधान के तौर पर, Cloud Firestore के 'बराबरी वाले क्लॉज़ के लिए इंडेक्स मर्ज करने की सुविधा' का फ़ायदा उठाकर, इंडेक्स की संख्या कम की जा सकती है:
| कलेक्शन | इंडेक्स किए गए फ़ील्ड | क्वेरी का स्कोप |
|---|---|---|
| रेस्टोरेंट | category, star_rating | कलेक्शन |
| रेस्टोरेंट | city, 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 एमआईबी किसी दस्तावेज़ का कुल साइज़, इन चीज़ों का कुल योग होता है: |
| इंडेक्स किए गए फ़ील्ड की वैल्यू का ज़्यादा से ज़्यादा साइज़ |
1500 बाइट 1,500 बाइट से ज़्यादा की फ़ील्ड वैल्यू काट दी जाती हैं. जिन क्वेरी में काटी गई फ़ील्ड वैल्यू शामिल होती हैं उनसे अलग-अलग नतीजे मिल सकते हैं. |
इंडेक्स करने के सबसे सही तरीके
ज़्यादातर ऐप्लिकेशन के लिए, अपने इंडेक्स मैनेज करने के लिए, अपने-आप इंडेक्स होने की सुविधा और गड़बड़ी के मैसेज के लिंक का इस्तेमाल किया जा सकता है. हालांकि, इन मामलों में एक फ़ील्ड के लिए छूट जोड़ी जा सकती है:
| कारक | ब्यौरा |
|---|---|
| बड़े स्ट्रिंग फ़ील्ड | अगर आपके पास कोई स्ट्रिंग फ़ील्ड है, जिसमें अक्सर लंबी स्ट्रिंग वैल्यू होती हैं और जिनका इस्तेमाल आपने क्वेरी करने के लिए नहीं किया है, तो फ़ील्ड को इंडेक्स करने से छूट देकर, स्टोरेज के खर्च को कम किया जा सकता है. |
| क्रम से वैल्यू वाले दस्तावेज़ों वाले कलेक्शन में, डेटा लिखने की दर ज़्यादा होना | अगर आपने किसी ऐसे फ़ील्ड को इंडेक्स किया है जो किसी कलेक्शन में मौजूद दस्तावेज़ों के बीच क्रम से बढ़ता या घटता है, जैसे कि टाइमस्टैंप, तो कलेक्शन में डेटा लिखने की दर ज़्यादा से ज़्यादा 500 बार प्रति सेकंड हो सकती है. अगर क्रम से लगाई गई वैल्यू वाले फ़ील्ड के आधार पर क्वेरी नहीं की जाती है, तो इस सीमा को बायपास करने के लिए, फ़ील्ड को इंडेक्स करने से छूट दी जा सकती है. उदाहरण के लिए, ज़्यादा डेटा लिखने की दर वाले किसी IoT इस्तेमाल के उदाहरण में, टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ों वाले कलेक्शन में, हर सेकंड 500 डेटा लिखने की सीमा तक पहुंचा जा सकता है. |
| TTL फ़ील्ड |
अगर टीटीएल (टाइम-टू-लिव) नीतियों का इस्तेमाल किया जाता है, तो ध्यान दें कि टीटीएल फ़ील्ड में टाइमस्टैंप होना चाहिए. टीटीएल फ़ील्ड पर इंडेक्स करने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इससे ज़्यादा ट्रैफ़िक रेट पर परफ़ॉर्मेंस पर असर पड़ सकता है. सबसे सही तरीका यह है कि अपने टीटीएल फ़ील्ड के लिए, एक फ़ील्ड के लिए छूट जोड़ें. |
| बड़े ऐरे या मैप फ़ील्ड | बड़े कलेक्शन या मैप फ़ील्ड में, हर दस्तावेज़ में 40,000 इंडेक्स एंट्री हो सकती हैं. अगर बड़ी कैटगरी या मैप फ़ील्ड के आधार पर क्वेरी नहीं की जा रही है, तो आपको उसे इंडेक्स करने से छूट देनी चाहिए. |
अगर एक से ज़्यादा फ़ील्ड पर रेंज और असमानता ऑपरेटर वाली क्वेरी का इस्तेमाल किया जा रहा है, तो इंडेक्स करने से जुड़ी बातें देखें. इन बातों को ध्यान में रखकर, Cloud Firestore क्वेरी की परफ़ॉर्मेंस और लागत को ऑप्टिमाइज़ किया जा सकता है
इंडेक्स करने से जुड़ी समस्याओं (इंडेक्स फ़ैनआउट, INVALID_ARGUMENT गड़बड़ियां) को हल करने के बारे में ज़्यादा जानकारी के लिए, समस्या हल करने की जानकारी देने वाला पेज देखें.