Analizzare l'esecuzione delle query con Spiegazione query

Questa pagina descrive come recuperare le informazioni sull'esecuzione delle query quando esegui una query.

Utilizzare Spiegazione query

Puoi utilizzare Spiegazione query per capire come vengono eseguite le tue query. Fornisce dettagli che puoi utilizzare per ottimizzare le query.

Puoi utilizzare Spiegazione query tramite la Google Cloud console o il explain comando.

Console

Esegui una query nell'editor di query e apri la scheda Spiegazione:

  1. Nella Google Cloud console, vai alla pagina Database.

    Vai a Database

  2. Seleziona un database Firestore con compatibilità MongoDB dall'elenco dei database. La Google Cloud console apre Firestore Explorer per quel database.
  3. Inserisci una query nell'editor di query e fai clic su Esegui.

  4. Fai clic sulla scheda Spiegazione per visualizzare l'output dell'analisi della query.

    Scheda Spiega query nella console
API MongoDB

Spiegazione query nell'API MongoDB è supportata tramite il explain comando, che puoi utilizzare in strumenti come Mongo Shell e Compass.

Il comando explain è supportato con i comandi aggregate, find, distinct e count, ad esempio:

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

Puoi anche utilizzare il metodo explain(), ad esempio:

db.collection.find({QUERY}).explain('executionStats')
Limitazioni
Tieni presenti le seguenti limitazioni e differenze:

  • Spiegazione query non supporta i comandi che restituiscono un cursore. Ad esempio, non è supportato il richiamo di explain chiamando direttamente il seguente comando:

    db.collection.aggregate(..., explain: true)

  • Spiegazione query è supportata solo sui find, aggregate, count, distinct, update, delete, e findAndModify comandi.

  • Spiegazione query supporta le modalità di verbosità executionStats, allPlansExecution e queryPlanner.

    • queryPlanner: restituisce solo il piano di esecuzione, senza eseguire la query,
    • executionStats e allPlansExecution: restituisce il piano di esecuzione insieme alle statistiche di fatturazione, memoria ed esecuzione.

    Se non viene specificata alcuna modalità di verbosità, la shell utilizza per impostazione predefinita queryPlanner. Per visualizzare le statistiche di esecuzione complete, devi specificare la modalità di verbosità executionStats o allPlansExecution.

Analisi

L'output di Spiegazione query contiene due componenti principali: le statistiche di riepilogo e l'albero di esecuzione. Considera questa query come esempio:

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

Statistiche di riepilogo

La parte superiore dell'output spiegato contiene un riepilogo delle statistiche di esecuzione. Utilizza queste statistiche per determinare se una query ha una latenza o un costo elevati. Contiene anche statistiche sulla memoria che ti consentono di sapere quanto la query è vicina ai limiti di memoria.

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

Albero di esecuzione

L'albero di esecuzione descrive l'esecuzione della query come una serie di nodi. I nodi inferiori (nodi foglia) recuperano i dati dal livello di archiviazione che attraversa l'albero per generare una risposta alla query.

Per informazioni dettagliate su ogni nodo di esecuzione, consulta le informazioni di riferimento sull'esecuzione.

Per informazioni dettagliate su come utilizzare queste informazioni per ottimizzare le query, consulta Ottimizzare l'esecuzione delle query.

Di seguito è riportato un esempio di albero di esecuzione:

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)

Passaggi successivi