धीमी क्वेरी की समस्या हल करने के लिए, क्वेरी की जानकारी का इस्तेमाल करें. इससे आपको क्वेरी को लागू करने का प्लान और रनटाइम एक्ज़ीक्यूशन प्रोफ़ाइल मिलेगी. यहां दिए गए सेक्शन में, एक्ज़ीक्यूशन प्रोफ़ाइल के आधार पर क्वेरी की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने का तरीका बताया गया है:
नतीजों की संख्या सीमित करना
एक्ज़ीक्यूशन ट्री में, 'दिखाए गए रिकॉर्ड' फ़ील्ड का इस्तेमाल करके यह पता लगाएं कि क्वेरी से कई दस्तावेज़ दिखाए जा रहे हैं या नहीं. limit(...) स्टेज का इस्तेमाल करके,
दस्तावेज़ों की संख्या को सीमित करें. इससे, नेटवर्क पर क्लाइंट को नतीजे वापस भेजते समय, नतीजों का सीरियलाइज़ किया गया बाइट साइज़ कम हो जाता है. कुछ मामलों में, जहां Limit नोड से पहले MajorSort नोड होता है, वहां क्वेरी इंजन Limit और MajorSort नोड को जोड़ सकता है. साथ ही, इन-मेमोरी मटीरियलाइज़ेशन और सॉर्ट को TopN सॉर्ट से बदल सकता है. इससे क्वेरी के लिए मेमोरी की ज़रूरत कम हो जाती है.
नतीजे के तौर पर मिलने वाले दस्तावेज़ का साइज़ सीमित करना
दस्तावेज़ के साइज़ को सीमित करने के लिए, select(...) का इस्तेमाल करें. इससे सिर्फ़ ज़रूरी फ़ील्ड दिखेंगे. इसके अलावा, remove_fields(...) का इस्तेमाल करके, बहुत बड़े फ़ील्ड को हटाया जा सकता है. इससे, इंटरमीडिएट नतीजों को प्रोसेस करने के लिए कंप्यूट और मेमोरी की लागत कम होती है. साथ ही, नेटवर्क पर क्लाइंट को नतीजे वापस भेजते समय, नतीजों का सीरियलाइज़ किया गया बाइट साइज़ भी कम होता है. अगर क्वेरी में रेफ़रंस के तौर पर दिए गए सभी फ़ील्ड, रेगुलर इंडेक्स में शामिल हैं, तो क्वेरी को इंडेक्स स्कैन में पूरी तरह से शामिल किया जा सकता है. इससे, प्राइमरी स्टोरेज से दस्तावेज़ फ़ेच करने की ज़रूरत नहीं पड़ती.
इंडेक्स का इस्तेमाल करना
इंडेक्स सेट अप और ऑप्टिमाइज़ करने के लिए, यहां दिए गए निर्देशों का पालन करें.
यह पता लगाना कि क्वेरी में इंडेक्स का इस्तेमाल किया जा रहा है या नहीं
एक्ज़ीक्यूशन ट्री में लीफ़ नोड देखकर, यह पता लगाया जा सकता है कि क्वेरी में इंडेक्स का इस्तेमाल किया जा रहा है या नहीं. अगर एक्ज़ीक्यूशन ट्री का लीफ़ नोड, TableScan नोड है, तो इसका मतलब है कि क्वेरी किसी इंडेक्स का इस्तेमाल नहीं कर रही है और प्राइमरी स्टोरेज से दस्तावेज़ों को स्कैन कर रही है. अगर किसी इंडेक्स का इस्तेमाल किया जा रहा है, तो एक्ज़ीक्यूशन ट्री का लीफ़ नोड, इंडेक्स का इंडेक्स आईडी और इंडेक्स फ़ील्ड दिखाएगा.
बेहतर इंडेक्स की पहचान करना
इंडेक्स किसी क्वेरी के लिए तब काम का होता है, जब वह उन दस्तावेज़ों की संख्या को कम कर सके जिन्हें क्वेरी इंजन को प्राइमरी स्टोरेज से फ़ेच करना होता है. इसके अलावा, अगर फ़ील्ड का क्रम, क्वेरी की क्रम से लगाने की ज़रूरी शर्त को पूरा कर सकता है, तो भी इंडेक्स काम का होता है.
अगर किसी क्वेरी के लिए इंडेक्स का इस्तेमाल किया जाता है, लेकिन क्वेरी इंजन अब भी कई दस्तावेज़ों को फ़ेच और खारिज कर रहा है, तो इसका मतलब है कि इंडेक्स का इस्तेमाल करके क्वेरी के लिए तय की गई शर्त को पूरा नहीं किया जा सकता. इसकी पहचान, स्कैन नोड से की जाती है. यह नोड कई रिकॉर्ड दिखाता है. इसके बाद, फ़िल्टर नोड कुछ रिकॉर्ड दिखाता है. ज़्यादा सही इंडेक्स बनाने के लिए, इंडेक्स बनाना देखें.
अगर किसी क्वेरी के लिए इंडेक्स का इस्तेमाल किया जाता है, लेकिन क्वेरी इंजन अब भी नतीजों के सेट को इन-मेमोरी रीऑर्डर कर रहा है, तो इसका मतलब है कि इस्तेमाल किया गया इंडेक्स, क्वेरी की क्रम से लगाने की ज़रूरी शर्त को पूरा करने के लिए इस्तेमाल नहीं किया जा सकता. इसकी पहचान, क्वेरी एक्ज़ीक्यूशन ट्री में MajorSort नोड से की जाती है. ज़्यादा सही इंडेक्स बनाने के लिए, अगला सेक्शन देखें.
इंडेक्स बनाना
इंडेक्स बनाने के लिए, इंडेक्स मैनेजमेंट से जुड़ा दस्तावेज़ पढ़ें. यह पक्का करने के लिए कि आपकी क्वेरी इंडेक्स का इस्तेमाल कर सके, यहां दिए गए क्रम में फ़ील्ड के साथ रेगुलर (मल्टीकी नहीं) इंडेक्स बनाएं:
- वे सभी फ़ील्ड जिनका इस्तेमाल, इक्वालिटी ऑपरेटर में किया जाएगा. क्वेरी में फिर से इस्तेमाल किए जाने की संभावना को बढ़ाने के लिए, फ़ील्ड को क्वेरी के बीच समानता ऑपरेटर में फ़ील्ड के होने के घटते क्रम में ऑर्डर करें.
- वे सभी फ़ील्ड जिनके हिसाब से डेटा को क्रम से लगाया जाएगा. इन्हें उसी क्रम में लगाया जाएगा जिस क्रम में फ़ील्ड मौजूद हैं.
- ऐसे फ़ील्ड जिनका इस्तेमाल, रेंज या असमानता ऑपरेटर में किया जाएगा. इन्हें क्वेरी की शर्त के हिसाब से, घटते क्रम में लगाया जाएगा.
- ऐसे फ़ील्ड जो इंडेक्स में क्वेरी के हिस्से के तौर पर दिखाए जाएंगे: इंडेक्स में ऐसे फ़ील्ड शामिल करने से, इंडेक्स में क्वेरी को कवर किया जा सकता है. साथ ही, प्राइमरी स्टोरेज से दस्तावेज़ फ़ेच करने की ज़रूरत नहीं पड़ती.
इंडेक्स या टेबल स्कैन को फ़ोर्स करना
Cloud Firestore से क्वेरी करने पर, यह अपने-आप ऐसे इंडेक्स का इस्तेमाल करता है जिनसे क्वेरी को ज़्यादा बेहतर बनाया जा सकता है. इसलिए, आपको अपनी क्वेरी के लिए इंडेक्स तय करने की ज़रूरत नहीं है. हालांकि, आपके वर्कलोड के लिए ज़रूरी क्वेरी के लिए, हमारा सुझाव है कि आप forceIndex विकल्प का इस्तेमाल करें. इससे आपको बेहतर परफ़ॉर्मेंस मिलेगी.
कुछ मामलों में, Cloud Firestore ऐसा इंडेक्स चुन सकता है जिससे क्वेरी के इंतज़ार का समय बढ़ जाए. अगर आपने परफ़ॉर्मेंस में गिरावट की समस्या को हल करने के लिए, समस्या हल करने के तरीके अपनाए हैं और आपको लगता है कि क्वेरी के लिए कोई दूसरा इंडेक्स आज़माना सही रहेगा, तो forceIndex विकल्प का इस्तेमाल करके इंडेक्स तय किया जा सकता है.
पाइपलाइन ऑपरेशन में किसी भी इनपुट स्टेज पर forceIndex विकल्प का इस्तेमाल किया जा सकता है. इससे Cloud Firestore के डिफ़ॉल्ट क्वेरी प्लान को बदला जा सकता है. साथ ही, इस्तेमाल करने के लिए कोई इंडेक्स तय किया जा सकता है या टेबल स्कैन को लागू किया जा सकता है.
किसी इंडेक्स को ज़बरदस्ती लागू करना
क्वेरी को किसी खास इंडेक्स का इस्तेमाल करने के लिए मजबूर करने के लिए, forceIndex विकल्प में इंडेक्स आईडी को स्ट्रिंग के तौर पर दें. इंडेक्स आईडी को कंसोल या गड़बड़ी के मैसेज से ढूंढा जा सकता है.
यहां दिए गए उदाहरण में, प्लानर को आईडी CICAgOi36pgK वाले इंडेक्स का इस्तेमाल करने के लिए मजबूर किया गया है:
Node.js
// Force Planner to use Index ID CICAgOi36pgK await db.pipeline() .collectionGroup({ collectionId: "customers", forceIndex: "CICAgOi36pgK" }) .limit(100) .execute();
Java
// Force Planner to use Index ID CICAgOi36pgK Pipeline.Snapshot results1 = firestore.pipeline() .collectionGroup("customers", new CollectionGroupOptions() .withHints(new CollectionHints().withForceIndex("CICAgOi36pgK"))) .limit(100) .execute().get();
जाएं
// Force Planner to use Index ID CICAgOi36pgK snapshot1 := client.Pipeline(). CollectionGroup("customers", firestore.WithForceIndex("CICAgOi36pgK")). Limit(100). Execute(ctx)
किसी खास इंडेक्स को लागू करने के कुछ उदाहरण यहां दिए गए हैं:
- अलग-अलग इंडेक्स की परफ़ॉर्मेंस की जांच करना.
- यह पक्का करना कि क्वेरी के लिए, किसी खास और सबसे सही इंडेक्स का इस्तेमाल किया जाए.
- जब किसी क्वेरी के लिए ऑप्टिमाइज़र का डिफ़ॉल्ट विकल्प सही न हो, तो उसे बदलना.
अगर तय किया गया इंडेक्स नहीं मिलता है, तो क्वेरी पूरी नहीं हो पाती है.
टेबल को स्कैन करने के लिए मजबूर करना
टेबल स्कैन, किसी भी सेकंडरी इंडेक्स का इस्तेमाल किए बिना, कलेक्शन या कलेक्शन ग्रुप में मौजूद दस्तावेज़ों को पढ़ता है. टेबल स्कैन को ज़बरदस्ती लागू करने के लिए, forceIndex को primary पर सेट करें.
यहां दिए गए उदाहरण में, टेबल स्कैन को लागू करने का तरीका बताया गया है:
// Force Planner to only do a Full-Table Scan
db.pipeline()
.collectionGroup({ collectionId: "customers", forceIndex: "primary" })
.limit(100)
इन मामलों में, टेबल स्कैन का इस्तेमाल किया जा सकता है:
- बहुत छोटे कलेक्शन के लिए, जहां इंडेक्स ओवरहेड सही नहीं है.
- ऐसी क्वेरी के लिए जो किसी कलेक्शन में मौजूद ज़्यादातर दस्तावेज़ों को ऐक्सेस करती हैं.
- डीबग करने और परफ़ॉर्मेंस की तुलना करने के लिए.
क्वेरी की जानकारी के साथ forceIndex का इस्तेमाल करना
forceIndex के असर को देखने के लिए, explain या analyze मोड में Query Explain का इस्तेमाल किया जा सकता है:
- पुष्टि करें कि Cloud Firestore ने
forceIndexमें बताए गए इंडेक्स का इस्तेमाल किया है. इसके लिए, इंडेक्स आईडी के लिए एक्ज़ीक्यूशन ट्री के लीफ़ नोड देखें. - पुष्टि करें कि
forceIndex: "primary"का इस्तेमाल करने पर, प्लान मेंTableScanनोड दिखता है. analyzeमोड की मदद से, परफ़ॉर्मेंस मेट्रिक की तुलना करें. जैसे, इंतज़ार का समय, स्कैन किए गए दस्तावेज़, और स्कैन की गई इंडेक्स एंट्री. क्वेरी की परफ़ॉर्मेंस को बेहतर बनाने के लिए,forceIndexके साथ और इसके बिना तुलना करें.
forceIndex के लिए सबसे सही तरीके
forceIndex, क्वेरी को लागू करने पर ज़्यादा कंट्रोल देता है. हालांकि, Cloud Firestore का क्वेरी ऑप्टिमाइज़र, आम तौर पर ज़्यादातर मामलों में बेहतर तरीके से काम करता है.
forceIndex का इस्तेमाल करते समय, इन सबसे सही तरीकों को अपनाएं:
forceIndexका इस्तेमाल सोच-समझकर करें. अगर आपको डिफ़ॉल्ट क्वेरी प्लान के साथ खराब परफ़ॉर्मेंस दिखती है, तो इंडेक्स को लागू करने से पहले समस्या का पता लगाने के लिए, क्वेरी की जानकारी का इस्तेमाल करें.forceIndexका इस्तेमाल करते समय, अपनी क्वेरी को असल डेटा वॉल्यूम के साथ टेस्ट करें, ताकि उनकी परफ़ॉर्मेंस और लागत की विशेषताओं को समझा जा सके.- प्रोडक्शन एनवायरमेंट में बड़े कलेक्शन पर
forceIndex: "primary"का इस्तेमाल करने से बचें.
Query Explain की मदद से लागू की गई क्वेरी के आउटपुट के बारे में ज़्यादा जानने के लिए, क्वेरी लागू करने का रेफ़रंस देखें.