Query Explain की मदद से, क्वेरी के एक्ज़ीक्यूशन का विश्लेषण करना

इस पेज पर, क्वेरी को एक्ज़ीक्यूट करते समय, क्वेरी के एक्ज़ीक्यूशन की जानकारी पाने का तरीका बताया गया है.

क्वेरी की व्याख्या करने वाली सुविधा का इस्तेमाल करना

क्वेरी एक्सप्लेन का इस्तेमाल करके, यह समझा जा सकता है कि आपकी क्वेरी कैसे एक्ज़ीक्यूट की जा रही हैं. इससे आपको ऐसी जानकारी मिलती है जिसका इस्तेमाल करके, अपनी क्वेरी को ऑप्टिमाइज़ किया जा सकता है.

Google Cloud Console या explain कमांड का इस्तेमाल करके, क्वेरी की व्याख्या की जा सकती है.

कंसोल

क्वेरी एडिटर में कोई क्वेरी चलाएं और एक्सप्लेनेशन टैब खोलें:

  1. Google Cloud Console में, डेटाबेस पेज पर जाएं.

    डेटाबेस पर जाएं

  2. डेटाबेस की सूची में से, कोई Cloud Firestore डेटाबेस चुनें. Google Cloud Console, उस डेटाबेस के लिए Firestore एक्सप्लोरर खोलता है.
  3. क्वेरी एडिटर में कोई क्वेरी डालें और चलाएं पर क्लिक करें.
  4. क्वेरी के विश्लेषण का आउटपुट देखने के लिए, एक्सप्लेनेशन टैब पर क्लिक करें.

    कंसोल में क्वेरी के बारे में जानकारी देने वाला टैब
MongoDB API

MongoDB API में Query Explain सुविधा, explain कमांड के ज़रिए काम करती है. इस कमांड का इस्तेमाल Mongo Shell और Compass जैसे टूल में किया जा सकता है.

explain कमांड को aggregate, find, distinct, और count कमांड के साथ इस्तेमाल किया जा सकता है. उदाहरण के लिए:

db.collection.explain('executionStats').find(...)

explain() तरीके का भी इस्तेमाल किया जा सकता है. उदाहरण के लिए:

db.collection.find({QUERY}).explain('executionStats')
सीमाएं
इन बातों का ध्यान रखें:
  • क्वेरी के बारे में जानकारी देने वाली सुविधा, कर्सर दिखाने वाले निर्देशों के साथ काम नहीं करती. उदाहरण के लिए, सीधे तौर पर यह कमांड कॉल करके, 'जवाब के बारे में जानकारी दें' सुविधा को चालू करना मौजूद नहीं है:

    db.collection.aggregate(..., explain: true)
  • क्वेरी की व्याख्या करने की सुविधा, सिर्फ़ find, aggregate, count, distinct, update, delete, और findAndModify कमांड के साथ काम करती है.

  • क्वेरी के बारे में जानकारी देने वाली सुविधा, executionStats, allPlansExecution, और queryPlanner वर्बोसिटी मोड के साथ काम करती है.

    • queryPlanner: इससे सिर्फ़ एक्ज़ीक्यूशन प्लान मिलता है. क्वेरी को एक्ज़ीक्यूट नहीं किया जाता,
    • executionStats और allPlansExecution: इससे बिलिंग, मेमोरी, और एक्ज़ीक्यूशन के आंकड़ों के साथ-साथ एक्ज़ीक्यूशन प्लान भी मिलता है.

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

विश्लेषण

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

db.orders.aggregate(
 [
   { "$match": { "user_id": 1234 } },
   { "$sort": { "date_placed": 1 } }
 ]
)

खास जानकारी वाले आंकड़े

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

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

प्रोग्राम चलाने का ट्री

एक्ज़ीक्यूशन ट्री में, क्वेरी को नोड की सीरीज़ के तौर पर एक्ज़ीक्यूट करने के बारे में बताया जाता है. सबसे नीचे मौजूद नोड (लीफ़ नोड), स्टोरेज लेयर से डेटा वापस पाते हैं. यह डेटा, क्वेरी का जवाब जनरेट करने के लिए ट्री में ऊपर की ओर जाता है.

हर एक्ज़ीक्यूशन नोड के बारे में जानकारी के लिए, एक्ज़ीक्यूशन रेफ़रंस देखें.

क्वेरी को ऑप्टिमाइज़ करने के लिए इस जानकारी का इस्तेमाल करने के तरीके के बारे में जानने के लिए, क्वेरी को ऑप्टिमाइज़ करना लेख पढ़ें.

यहाँ एक्ज़ीक्यूशन ट्री का एक उदाहरण दिया गया है:

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

Tree:
• Compute
|  $out_1: map_set($record_1, "__id__", $__id___1, "__key__", unset)
|  is query result: true
|
|  Execution:
|   records returned: 35
|   latency: 204.87 ms (local 7.64 ms)
|
└── • Compute
    |  $__id___1: _id($__key___2)
    |
    |  Execution:
    |   records returned: 35
    |   latency: 197.23 ms (local 2.04 ms)
    |
    └── • MajorSort
        |  fields: [$v_5 ASC]
        |  output: [$__key___2, $record_1]
        |
        |  Execution:
        |   records returned: 35
        |   latency: 195.20 ms (local 28.42 ms)
        |   peak memory usage: 45.56 KiB (46,656 B)
        |
        └── • Compute
            |  $v_5: offset($v_4, 0L)
            |
            |  Execution:
            |   records returned: 35
            |   latency: 166.78 ms (local 14.84 ms)
            |
            └── • Compute
                |  $v_4: sortPaths(array($date_placed_1), [date_placed ASC])
                |
                |  Execution:
                |   records returned: 35
                |   latency: 151.94 ms (local 5.43 ms)
                |
                └── • TableScan
                       source: **/orders
                       order: STABLE
                       filter: $eq($user_id_1, 1,234)
                       output bindings: {$__key___2=row().__key__, $date_placed_1=row().date_placed, $record_1=row[* - { __create_time__, __update_time__ }](), $user_id_1=row().user_id}
                       output: [$__key___2, $date_placed_1, $record_1]

                       Execution:
                        records returned: 35
                        latency: 146.50 ms
                        data bytes returned: 3.25 KiB (3,325 B)
                        post-filtered rows: 230
                        records scanned: 265
                        data bytes read: 24.58 KiB (25,175 B)

आगे क्या करना है