Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Ottimizza le query su CloudTrail Lake
Questa pagina fornisce indicazioni su come ottimizzare le query CloudTrail Lake per migliorare le prestazioni e l'affidabilità. Descrive tecniche di ottimizzazione specifiche e soluzioni alternative per gli errori di query più comuni.
**Topics**
+ [Consigli per l'ottimizzazione delle interrogazioni](#lake-queries-tuning)
+ [Soluzioni alternative per gli errori di interrogazione](#lake-queries-troubleshooting)
## Consigli per l'ottimizzazione delle interrogazioni
Segui i consigli in questa sezione per ottimizzare le tue query.
**Topics**
+ [Ottimizzazione delle aggregazioni](#query-optimization-aggregation)
+ [Utilizzate tecniche di approssimazione](#query-optimization-approximation)
+ [Limita i risultati delle interrogazioni](#query-optimization-limit)
+ [Ottimizza le query LIKE](#query-optimization-like)
+ [Utilizza `UNION ALL` al posto di `UNION`](#query-optimization-union)
+ [Come includere solo le colonne obbligatorie](#query-optimization-reqcolumns)
+ [Riduci l'ambito della funzione della finestra](#query-optimization-windows)
### Ottimizzazione delle aggregazioni
L'esclusione di colonne ridondanti nelle `GROUP BY` clausole può migliorare le prestazioni poiché un numero inferiore di colonne richiede meno memoria. Ad esempio, nella seguente query, possiamo usare la `arbitrary` funzione su una colonna ridondante per migliorare le prestazioni. `eventType` La `arbitrary` funzione on `eventType` viene utilizzata per selezionare il valore del campo in modo casuale dal gruppo poiché il valore è lo stesso e non deve essere incluso nella clausola. `GROUP BY`
```
SELECT eventName, eventSource, arbitrary(eventType), count(*)
FROM $EDS_ID
GROUP BY eventName, eventSource
```
È possibile migliorare le prestazioni della `GROUP BY` funzione ordinando l'elenco dei campi all'interno dell'ordine decrescente del loro numero di valori univoci (cardinalità). `GROUP BY` Ad esempio, pur ottenendo il numero di eventi di un tipo in ciascuno Regione AWS, è possibile migliorare le prestazioni utilizzando`eventName`, `awsRegion` order in the `GROUP BY` function anziché`awsRegion`, `eventName` poiché i valori univoci di sono più numerosi di `eventName` quelli esistenti. `awsRegion`
```
SELECT eventName, awsRegion, count(*)
FROM $EDS_ID
GROUP BY eventName, awsRegion
```
### Utilizzate tecniche di approssimazione
Ogni volta che non sono necessari valori esatti per contare valori distinti, utilizza [funzioni di aggregazione approssimative](https://trino.io/docs/current/functions/aggregate.html#approximate-aggregate-functions) per trovare i valori più frequenti. Ad esempio, [https://trino.io/docs/current/functions/aggregate.html#approx_distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct)utilizza molta meno memoria ed è più veloce dell'operazione. `COUNT(DISTINCT fieldName)`
### Limita i risultati delle interrogazioni
Se è necessaria solo una risposta di esempio per una query, limita i risultati a un numero limitato di righe utilizzando la `LIMIT` condizione. In caso contrario, la query restituirà risultati di grandi dimensioni e richiederà più tempo per l'esecuzione della query.
L'utilizzo di `LIMIT` along with `ORDER BY` consente di ottenere risultati più rapidamente per i primi o gli ultimi N record, in quanto riduce la quantità di memoria necessaria e il tempo necessario per l'ordinamento.
```
SELECT * FROM $EDS_ID
ORDER BY eventTime
LIMIT 100;
```
### Ottimizza le query LIKE
Puoi usare `LIKE` per trovare stringhe corrispondenti, ma per le stringhe lunghe richiede molto calcolo. La [https://trino.io/docs/current/functions/regexp.html#regexp_like](https://trino.io/docs/current/functions/regexp.html#regexp_like)funzione è nella maggior parte dei casi un'alternativa più veloce.
Spesso è possibile ottimizzare una ricerca ancorando la sottostringa che si sta cercando. Ad esempio, se stai cercando un prefisso, è meglio usare '`substr`%' invece di '% `substr` %' con l'`LIKE`operatore e '^' con la funzione. `substr` `regexp_like`
### Utilizza `UNION ALL` al posto di `UNION`
`UNION ALL`e `UNION` sono due modi per combinare i risultati di due interrogazioni in un unico risultato, ma rimuovono i duplicati. `UNION` `UNION`deve elaborare tutti i record e trovare i duplicati, operazione che richiede molta memoria e calcolo, ma `UNION ALL` è un'operazione relativamente rapida. A meno che non sia necessario deduplicare i record, utilizza `UNION ALL` per ottenere prestazioni ottimali.
### Come includere solo le colonne obbligatorie
Se non hai bisogno di una colonna, non includerla nella query. Minore è la quantità di dati che una query deve elaborare, maggiore sarà la velocità di esecuzione. Se hai interrogazioni che riguardano la query più esterna, dovresti modificarla `SELECT *` in un elenco di colonne di cui hai bisogno. `*`
La clausola `ORDER BY` restituisce i risultati di una query disponendoli in ordine. Quando si ordinano grandi quantità di dati, se la memoria richiesta non è disponibile, i risultati ordinati intermedi vengono scritti su disco, il che può rallentare l'esecuzione delle query. Se non è strettamente necessario ordinare i risultati, evita di aggiungere una clausola `ORDER BY`. Inoltre, evitate di aggiungere `ORDER BY` elementi alle interrogazioni interne se non sono strettamente necessari.
### Riduci l'ambito della funzione della finestra
[Le funzioni della finestra](https://trino.io/docs/current/functions/window.html) mantengono in memoria tutti i record su cui operano per calcolarne il risultato. Quando la finestra è di dimensioni molto grandi, la funzione finestra può esaurire la memoria. Per assicurarvi che le interrogazioni vengano eseguite entro i limiti di memoria disponibili, riducete le dimensioni delle finestre su cui operano le funzioni della finestra aggiungendo una `PARTITION BY` clausola.
A volte le query con le funzioni finestra possono essere riscritte senza funzioni finestra. Ad esempio, invece di utilizzare `row_number` or`rank`, puoi utilizzare funzioni aggregate come o. [https://trino.io/docs/current/functions/aggregate.html#max_by](https://trino.io/docs/current/functions/aggregate.html#max_by)
La seguente query trova l'alias assegnato più di recente a ciascuna chiave KMS utilizzando. `max_by`
```
SELECT element_at(requestParameters, 'targetKeyId') as keyId,
max_by(element_at(requestParameters, 'aliasName'), eventTime) as mostRecentAlias
FROM $EDS_ID
WHERE eventsource = 'kms.amazonaws.com'
AND eventName in ('CreateAlias', 'UpdateAlias')
AND eventTime > DATE_ADD('week', -1, CURRENT_TIMESTAMP)
GROUP BY element_at(requestParameters, 'targetKeyId')
```
In questo caso, la `max_by` funzione restituisce l'alias per il record con l'ora dell'ultimo evento all'interno del gruppo. Questa query viene eseguita più velocemente e utilizza meno memoria rispetto a una query equivalente con una funzione finestra.
## Soluzioni alternative per gli errori di interrogazione
Questa sezione fornisce soluzioni alternative per gli errori di query più comuni.
**Topics**
+ [La query fallisce perché la risposta è troppo grande](#large-responses)
+ [La query ha esito negativo a causa dell'esaurimento delle risorse](#exhausted-resources)
### La query fallisce perché la risposta è troppo grande
Una query può avere esito negativo se la risposta risultante nel messaggio è troppo grande`Query response is too large`. In tal caso, è possibile ridurre l'ambito di aggregazione.
Funzioni di aggregazione come quelle che `array_agg` possono far sì che almeno una riga nella risposta alla query sia molto grande, causando l'esito negativo della query. Ad esempio, l'utilizzo di `array_agg(eventName)` instead of `array_agg(DISTINCT eventName)` aumenterà notevolmente la dimensione della risposta a causa della duplicazione dei nomi degli eventi selezionati CloudTrail .
### La query ha esito negativo a causa dell'esaurimento delle risorse
Se non è disponibile memoria sufficiente durante l'esecuzione di operazioni a uso intensivo di memoria come join, aggregazioni e funzioni delle finestre, i risultati intermedi vengono trasferiti su disco, ma la fuoriuscita rallenta l'esecuzione delle query e può essere insufficiente per evitare che la query abbia esito negativo. `Query exhausted resources at this scale factor` Questo problema può essere risolto riprovando l'interrogazione.
Se gli errori precedenti persistono anche dopo l'ottimizzazione della query, è possibile definire l'ambito `eventTime` della query utilizzando gli eventi ed eseguirla più volte a intervalli più piccoli dell'intervallo di tempo della query originale.