क्वेरी की परफ़ॉर्मेंस ऑप्टिमाइज़ करना

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

नतीजों की संख्या सीमित करना

यह पता करने के लिए कि क्वेरी से कई दस्तावेज़ मिल रहे हैं या नहीं, एक्ज़ीक्यूशन ट्री में, वापस लाए गए रिकॉर्ड वाला फ़ील्ड देखें. limit(...) स्टेज का इस्तेमाल करके, वापस लाए गए दस्तावेज़ों की संख्या सीमित करने पर विचार करें. ऐसा करने से, नेटवर्क पर क्लाइंट को वापस भेजे गए नतीजों के सीरियल किए गए बाइट का साइज़ कम हो जाता है. अगर Limit नोड से पहले MajorSort नोड आता है, तो क्वेरी इंजन, Limit और MajorSort नोड को एक साथ जोड़ सकता है. साथ ही, इन-मेमोरी मटीरियलाइज़ेशन और सॉर्ट को TopN सॉर्ट से बदल सकता है. इससे क्वेरी के लिए मेमोरी की ज़रूरत कम हो जाती है.

नतीजे के तौर पर मिले दस्तावेज़ का साइज़ सीमित करना

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

इंडेक्स का इस्तेमाल करना

इंडेक्स सेट अप और ऑप्टिमाइज़ करने के लिए, यहां दिए गए निर्देशों का पालन करें.

यह पता करना कि क्वेरी किसी इंडेक्स का इस्तेमाल कर रही है या नहीं

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

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

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

अगर किसी क्वेरी के लिए इंडेक्स का इस्तेमाल किया जाता है, लेकिन क्वेरी इंजन अब भी कई दस्तावेज़ फ़ेच और खारिज कर रहा है, तो यह इस बात का संकेत है कि इंडेक्स का इस्तेमाल करके, क्वेरी प्रेडिकेट को पूरा नहीं किया जा रहा है. इसकी पहचान, Scan नोड से की जा सकती है. यह नोड कई रिकॉर्ड दिखाता है. इसके बाद, Filter नोड कुछ रिकॉर्ड दिखाता है. ज़्यादा काम का इंडेक्स बनाने के लिए, इंडेक्स बनाना लेख पढ़ें.

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

इंडेक्स बनाना

इंडेक्स बनाने के लिए, इंडेक्स मैनेजमेंट से जुड़ा दस्तावेज़ पढ़ें . यह पक्का करने के लिए कि आपकी क्वेरी, इंडेक्स का इस्तेमाल कर सकती है, सामान्य (मल्टीकी नहीं) इंडेक्स बनाएं. इनमें फ़ील्ड इस क्रम में होने चाहिए:

1. वे सभी फ़ील्ड जिनका इस्तेमाल, इक्वॉलिटी ऑपरेटर में किया जाएगा. क्वेरी में फिर से इस्तेमाल करने की संभावना को ज़्यादा से ज़्यादा करने के लिए, फ़ील्ड को इस क्रम में लगाएं, ताकि क्वेरी में इक्वॉलिटी ऑपरेटर में फ़ील्ड की संख्या घटते क्रम में हो.
2. वे सभी फ़ील्ड जिन्हें एक ही क्रम में सॉर्ट किया जाएगा.
3. वे फ़ील्ड जिनका इस्तेमाल, क्वेरी की कंस्ट्रेंट सेलेक्टिविटी के घटते क्रम में, रेंज या इनइक्वॉलिटी ऑपरेटर में किया जाएगा.
4. वे फ़ील्ड जो इंडेक्स में क्वेरी के हिस्से के तौर पर वापस लाए जाएंगे. इंडेक्स में ऐसे फ़ील्ड शामिल करने से, इंडेक्स क्वेरी को कवर कर सकता है. साथ ही, प्राइमरी स्टोरेज से दस्तावेज़ फ़ेच करने की ज़रूरत नहीं पड़ती.

किसी इंडेक्स या टेबल स्कैन को फ़ोर्स करना

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

कुछ मामलों में, Cloud Firestore ऐसा इंडेक्स चुन सकता है जिससे क्वेरी की लेटेन्सी बढ़ जाती है. अगर आपने परफ़ॉर्मेंस में गिरावट की समस्या को हल करने के लिए दिए गए चरणों को फ़ॉलो किया है और पुष्टि की है कि क्वेरी के लिए किसी दूसरे इंडेक्स का इस्तेमाल करना सही है, तो forceIndex विकल्प का इस्तेमाल करके, इंडेक्स तय किया जा सकता है.

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

किसी खास इंडेक्स को फ़ोर्स करना

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

यहां दिए गए उदाहरण में, प्लानर को CICAgOi36pgK आईडी वाले इंडेक्स का इस्तेमाल करने के लिए फ़ोर्स किया गया है:

// Force Planner to use Index ID CICAgOi36pgK
await db.pipeline()
  .collectionGroup({ collectionId: "customers", forceIndex: "CICAgOi36pgK" })
  .limit(100)
  .execute();
test.firestore.js

// 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();
PipelineSnippets.java

// Force Planner to use Index ID CICAgOi36pgK
snapshot1 := client.Pipeline().
	CollectionGroup("customers", firestore.WithForceIndex("CICAgOi36pgK")).
	Limit(100).
	Execute(ctx)
pipeline_snippets_general.go

किसी खास इंडेक्स को फ़ोर्स करने के कुछ उदाहरण यहां दिए गए हैं:

• अलग-अलग इंडेक्स की परफ़ॉर्मेंस की जांच करना.
• यह पक्का करना कि किसी क्वेरी के लिए, किसी खास और बेहतर इंडेक्स का इस्तेमाल किया जाए.
• ऑप्टिमाइज़र के डिफ़ॉल्ट विकल्प के किसी खास क्वेरी के लिए सही न होने पर, उसे बदलना.

अगर तय किया गया इंडेक्स नहीं मिलता है, तो क्वेरी फ़ेल हो जाती है.

टेबल स्कैन को फ़ोर्स करना

टेबल स्कैन, कलेक्शन या कलेक्शन ग्रुप में मौजूद दस्तावेज़ों को किसी भी सेकंडरी इंडेक्स का इस्तेमाल किए बिना पढ़ता है. टेबल स्कैन को फ़ोर्स करने के लिए, forceIndex को primary पर सेट करें.

यहां दिए गए उदाहरण में, टेबल स्कैन को फ़ोर्स किया गया है:

// Force Planner to only do a Full-Table Scan
db.pipeline()
  .collectionGroup({ collectionId: "customers", forceIndex: "primary" })
  .limit(100)

इन मामलों में, टेबल स्कैन का इस्तेमाल किया जा सकता है:

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

क्वेरी की पूरी जानकारी दिखाने वाले टूल के साथ forceIndex का इस्तेमाल करना

क्वेरी की पूरी जानकारी दिखाने वाले टूल का इस्तेमाल किया जा सकता है. खास तौर पर, analyze विकल्प के साथ, forceIndex के असर को देखने के लिए:

• यह पुष्टि करें कि Cloud Firestore ने forceIndex में तय किए गए इंडेक्स का इस्तेमाल किया है. इसके लिए, इंडेक्स आईडी के लिए एक्ज़ीक्यूशन ट्री के लीफ़ नोड देखें.
• पुष्टि करें कि TableScan नोड का इस्तेमाल करने पर forceIndex: "primary", प्लान में दिखता है.
• क्वेरी की परफ़ॉर्मेंस को बेहतर बनाने के लिए, forceIndex के साथ और इसके बिना, परफ़ॉर्मेंस मेट्रिक की तुलना करें. जैसे, लेटेन्सी, स्कैन किए गए दस्तावेज़, और स्कैन की गई इंडेक्स एंट्री.

forceIndex के लिए सबसे सही तरीके

forceIndex से क्वेरी के एक्ज़ीक्यूशन पर ज़्यादा कंट्रोल मिलता है. Cloud Firestore का क्वेरी ऑप्टिमाइज़र, ज़्यादातर मामलों में आम तौर पर कारगर होता है. forceIndex का इस्तेमाल करते समय, इन सबसे सही तरीकों को ध्यान में रखें:

• forceIndex का इस्तेमाल सोच-समझकर करें. अगर आपको डिफ़ॉल्ट क्वेरी प्लान के साथ परफ़ॉर्मेंस सही नहीं मिलती है, तो क्वेरी की पूरी जानकारी दिखाने वाले टूल का इस्तेमाल करके समस्या का पता लगाएं इंडेक्स को फ़ोर्स करने से पहले.
• forceIndex का इस्तेमाल करते समय, पक्का करें कि आपने अपनी क्वेरी की जांच, असली डेटा वॉल्यूम के साथ की हो. इससे आपको उनकी परफ़ॉर्मेंस और लागत की विशेषताओं के बारे में पता चलेगा.
• प्रोडक्शन एनवायरमेंट में, बड़े कलेक्शन पर forceIndex: "primary" का इस्तेमाल न करें.