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

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

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

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

يمكنك استخدام ميزة "تفسير طلب البحث" من خلال Google Cloud Console أو الأمر explain.

وحدة التحكم

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

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

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

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

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

تتوفّر ميزة "تفسير طلب البحث" في واجهة برمجة تطبيقات MongoDB من خلال الـ 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)

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