As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Otimize as consultas CloudTrail do Lake
Esta página fornece orientação sobre como otimizar as consultas do CloudTrail Lake para melhorar o desempenho e a confiabilidade. Aborda técnicas de otimização específicas, bem como soluções alternativas para falhas comuns em consultas.
**Topics**
+ [Recomendações para otimizar consultas](#lake-queries-tuning)
+ [Soluções alternativas para falhas de consulta](#lake-queries-troubleshooting)
## Recomendações para otimizar consultas
Siga as recomendações nesta seção para otimizar suas consultas.
**Topics**
+ [Otimizar agregações](#query-optimization-aggregation)
+ [Usar técnicas de aproximação](#query-optimization-approximation)
+ [Limitar resultados de consultas](#query-optimization-limit)
+ [Otimizar consultas LIKE](#query-optimization-like)
+ [Use `UNION ALL` em vez de `UNION`](#query-optimization-union)
+ [Incluir somente as colunas obrigatórias](#query-optimization-reqcolumns)
+ [Reduzir o escopo da função de janela](#query-optimization-windows)
### Otimizar agregações
A exclusão de colunas redundantes nas cláusulas `GROUP BY` pode melhorar a performance, pois um número menor de colunas requer menos memória. Por exemplo, na consulta a seguir, podemos usar a função `arbitrary`em uma coluna redundante, como `eventType` para melhorar a performance. A função `arbitrary` em `eventType` é usada para escolher aleatoriamente o valor do campo no grupo, pois o valor é o mesmo e não precisa ser incluído na cláusula `GROUP BY`.
```
SELECT eventName, eventSource, arbitrary(eventType), count(*)
FROM $EDS_ID
GROUP BY eventName, eventSource
```
É possível melhorar a performance da função `GROUP BY` ordenando a lista dos campos em `GROUP BY` em ordem decrescente da contagem dos seus valores específicos (cardinalidade). Por exemplo, ao obter o número de eventos de um tipo em cada um Região da AWS, o desempenho pode ser aprimorado usando a `awsRegion` ordem`eventName`, na `GROUP BY` função em vez de`awsRegion`, `eventName` pois há mais valores exclusivos de `eventName` do que de`awsRegion`.
```
SELECT eventName, awsRegion, count(*)
FROM $EDS_ID
GROUP BY eventName, awsRegion
```
### Usar técnicas de aproximação
Sempre que valores exatos não forem necessários para contar valores distintos, use [funções agregadas aproximadas](https://trino.io/docs/current/functions/aggregate.html#approximate-aggregate-functions) para encontrar os valores mais frequentes. Por exemplo, [https://trino.io/docs/current/functions/aggregate.html#approx_distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) usa muito menos memória e é executado mais rapidamente que a operação `COUNT(DISTINCT fieldName)`.
### Limitar resultados de consultas
Se apenas um exemplo de resposta for necessário para uma consulta, restrinja os resultados a um pequeno número de linhas usando a condição `LIMIT`. Caso contrário, a consulta retornará resultados grandes e levará mais tempo para ser executada.
O uso de `LIMIT` junto com `ORDER BY` pode fornecer resultados para os N primeiros ou últimos registros com mais rapidez, pois reduz a quantidade de memória necessária e o tempo gasto para classificar.
```
SELECT * FROM $EDS_ID
ORDER BY eventTime
LIMIT 100;
```
### Otimizar consultas LIKE
É possível usar `LIKE` para encontrar strings correspondentes, mas com strings longas, demanda uso intensivo de computação. Na maioria dos casos, a função [https://trino.io/docs/current/functions/regexp.html#regexp_like](https://trino.io/docs/current/functions/regexp.html#regexp_like) é uma alternativa mais rápida.
Muitas vezes, é possível otimizar uma pesquisa ancorando a substring que você está procurando. Por exemplo, se estiver procurando por um prefixo, é melhor usar '`substr`%' em vez de '% `substr` %' com o operador `LIKE` e '^`substr`' com a função. `regexp_like`.
### Use `UNION ALL` em vez de `UNION`
`UNION ALL` e `UNION` são duas maneiras de combinar os resultados de duas consultas em um único resultado, mas `UNION` remove as duplicatas. `UNION` precisa processar todos os registros e encontrar as duplicatas, o que requer uso intensivo de memória e computação, mas `UNION ALL` é uma operação relativamente rápida. A menos que você precise desduplicar registros, use `UNION ALL` para obter a melhor performance.
### Incluir somente as colunas obrigatórias
Se não precisar de uma coluna, não a inclua na consulta. Quanto menos dados a consulta precisar processar, mais rápido ela será executada. Se você tiver consultas que executam `SELECT *` na consulta mais externa, deverá alterar `*` para uma lista das colunas necessárias.
A cláusula `ORDER BY` retorna os resultados de uma consulta em ordem de classificação. Ao classificar uma grande quantidade de dados, se a memória necessária não estiver disponível, os resultados intermediários da classificação serão gravados no disco, o que pode retardar a execução da consulta. Se você não precisar estritamente que seu resultado seja classificado, evite adicionar uma cláusula `ORDER BY`. Além disso, evite adicionar `ORDER BY` a consultas internas se não for estritamente necessário.
### Reduzir o escopo da função de janela
As [funções de janela](https://trino.io/docs/current/functions/window.html) mantêm todos os registros em que operam na memória para calcular seu resultado. Quando a janela é muito grande, a função de janela pode ficar sem memória. Para garantir que suas consultas sejam executadas dentro dos limites de memória disponíveis, reduza o tamanho das janelas durante as quais as funções de janela operam, adicionando a cláusula `PARTITION BY`.
Às vezes, consultas com funções de janela podem ser gravadas sem funções de janela. Por exemplo, em vez de usar `row_number` ou `rank`, você pode usar funções agregadas como [https://trino.io/docs/current/functions/aggregate.html#max_by](https://trino.io/docs/current/functions/aggregate.html#max_by) ou [https://trino.io/docs/current/functions/aggregate.html#min_by](https://trino.io/docs/current/functions/aggregate.html#min_by).
A consulta a seguir encontra o alias atribuído mais recentemente a cada chave do KMS usando `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')
```
Nesse caso, a função `max_by` retorna o alias do registro com a hora de evento mais recente do grupo. Essa consulta é executada mais rapidamente e usa menos memória do que uma consulta equivalente com função de janela.
## Soluções alternativas para falhas de consulta
Esta seção fornece soluções alternativas para falhas comuns de consulta.
**Topics**
+ [Ocorre uma falha na consulta porque a resposta é muito grande](#large-responses)
+ [Ocorre falha na consulta devido à exaustão de recursos](#exhausted-resources)
### Ocorre uma falha na consulta porque a resposta é muito grande
Poderá ocorrer falha em uma consulta se a resposta for muito grande, resultando na mensagem `Query response is too large`. Se isso ocorrer, você poderá reduzir o escopo da agregação.
Funções de agregação como `array_agg` podem gerar pelo menos uma linha na resposta da consulta muito grande, causando a falha da consulta. Por exemplo, usar `array_agg(eventName)` em vez de `array_agg(DISTINCT eventName)` aumentará muito o tamanho da resposta devido aos nomes de eventos duplicados dos CloudTrail eventos selecionados.
### Ocorre falha na consulta devido à exaustão de recursos
Se não houver memória suficiente disponível durante a execução de operações que consomem muita memória, como junções, agregações e funções de janela, os resultados intermediários o excesso vai para o disco, mas isso retarda a execução da consulta e pode ser insuficiente para evitar que ocorra falha na consulta com `Query exhausted resources at this scale factor`. Isso pode ser corrigido ao tentar novamente a consulta.
Se os erros acima persistirem mesmo após a otimização da consulta, você poderá definir o escopo da consulta usando o `eventTime` dos eventos e executar a consulta várias vezes em intervalos menores do intervalo de tempo da consulta original.