تحليل تنفيذ طلب البحث باستخدام Query Explain

توضّح هذه الصفحة كيفية استرداد معلومات تنفيذ طلب البحث عند تنفيذ طلب بحث.

استخدام ميزة "تفسير طلب البحث"

يمكنك استخدام ميزة "تفسير طلب البحث" لفهم كيفية تنفيذ طلبات البحث. يوفّر ذلك تفاصيل يمكنك استخدامها لتحسين طلبات البحث.

يمكنك استخدام ميزة Query Explain من خلال وحدة تحكّم Google Cloud أو الأمر explain.

وحدة التحكم

نفِّذ طلب بحث في "محرِّر طلبات البحث" وافتح علامة التبويب التفسير:

  1. في وحدة تحكّم Google Cloud، انتقِل إلى صفحة قواعد البيانات.

    الانتقال إلى "قواعد البيانات"

  2. من قائمة قواعد البيانات، اختَر قاعدة بيانات Cloud Firestore. تفتح وحدة تحكّم Google Cloud صفحة Firestore Explorer لقاعدة البيانات هذه.
  3. أدخِل طلب بحث في محرِّر الطلبات وانقر على تنفيذ.
  4. انقر على علامة التبويب التفسير لعرض نتائج تحليل طلب البحث.

    علامة التبويب "شرح طلب البحث" في وحدة التحكّم
MongoDB API

تتوفّر ميزة Query Explain في واجهة برمجة التطبيقات MongoDB API من خلال الأمر explain الذي يمكنك استخدامه في أدوات مثل Mongo Shell وCompass.

يمكن استخدام الأمر explain مع الأوامر aggregate وfind وdistinct وcount، على سبيل المثال:

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

يمكنك أيضًا استخدام طريقة explain()، على سبيل المثال:

db.collection.find({QUERY}).explain('executionStats')
القيود
يُرجى مراعاة القيود والاختلافات التالية:
  • لا تتيح ميزة Query Explain استخدام الأوامر التي تعرض مؤشرًا. على سبيل المثال، لا يمكن استدعاء explain من خلال تنفيذ الأمر التالي مباشرةً:

    db.collection.aggregate(..., explain: true)
  • لا تتوفّر ميزة "تفسير طلب البحث" إلا في الأوامر find وaggregate وcount وdistinct وupdate وdelete وfindAndModify.

  • تتيح ميزة Query Explain استخدام أوضاع الإسهاب executionStats وallPlansExecution وqueryPlanner.

    • ‫queryPlanner: تعرض خطة التنفيذ فقط، بدون تنفيذ طلب البحث.
    • ‫executionStats وallPlansExecution: تعرض هذه الدالة خطة التنفيذ بالإضافة إلى إحصاءات الفوترة والذاكرة والتنفيذ.

    إذا لم يتم تحديد وضع الإسهاب، يتم ضبط واجهة الأوامر تلقائيًا على queryPlanner. للاطّلاع على إحصاءات التنفيذ الكاملة، عليك تحديد وضع الإسهاب executionStats أو allPlansExecution.

التحليل

يتضمّن ناتج Query Explain مكوّنَين رئيسيَّين، هما "الإحصاءات التلخيصية" و"شجرة التنفيذ". لنفترض أنّ طلب البحث هو:

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)

الخطوات التالية