Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Optimiza las consultas de CloudTrail Lake
Esta página proporciona orientación sobre cómo optimizar las consultas de CloudTrail Lake para mejorar el rendimiento y la fiabilidad. Abarca técnicas de optimización específicas, así como soluciones alternativas para los errores de consulta más comunes.
**Topics**
+ [Recomendaciones para optimizar las consultas](#lake-queries-tuning)
+ [Soluciones alternativas para los errores de la consulta](#lake-queries-troubleshooting)
## Recomendaciones para optimizar las consultas
Siga las recomendaciones que se encuentran en esta sección para optimizar sus consultas.
**Topics**
+ [Optimización de las agregaciones](#query-optimization-aggregation)
+ [Uso de técnicas de aproximación](#query-optimization-approximation)
+ [Limitar los resultados de la consulta](#query-optimization-limit)
+ [Optimización de consultas LIKE](#query-optimization-like)
+ [Use `UNION ALL` en lugar de `UNION`](#query-optimization-union)
+ [Inclusión de las columnas necesarias únicamente](#query-optimization-reqcolumns)
+ [Reducción del alcance de la función de ventana](#query-optimization-windows)
### Optimización de las agregaciones
La exclusión de las columnas redundantes en las cláusulas `GROUP BY` puede mejorar el rendimiento, debido a que menos columnas requieren menos memoria. Por ejemplo, en la siguiente consulta, podemos usar la función `arbitrary` en una columna redundante como `eventType` para mejorar el rendimiento. La función `arbitrary` en `eventType` se utiliza para seleccionar el valor del campo de manera aleatoria del grupo, ya que el valor es el mismo y no es necesario incluirlo en la cláusula `GROUP BY`.
```
SELECT eventName, eventSource, arbitrary(eventType), count(*)
FROM $EDS_ID
GROUP BY eventName, eventSource
```
Es posible mejorar el rendimiento de la función `GROUP BY` ordenando la lista de campos dentro de `GROUP BY` en orden decreciente según su recuento de valores únicos (cardinalidad). Por ejemplo, al obtener el número de eventos de un tipo en cada uno Región de AWS, se puede mejorar el rendimiento utilizando el `eventName` `awsRegion` orden de la `GROUP BY` función en lugar de`awsRegion`, `eventName` ya que hay más valores únicos de los `eventName` que hay`awsRegion`.
```
SELECT eventName, awsRegion, count(*)
FROM $EDS_ID
GROUP BY eventName, awsRegion
```
### Uso de técnicas de aproximación
Cuando no se necesiten valores exactos para contar valores distintos, utilice [funciones de agregación aproximada](https://trino.io/docs/current/functions/aggregate.html#approximate-aggregate-functions) para encontrar los valores más frecuentes. Por ejemplo, [https://trino.io/docs/current/functions/aggregate.html#approx_distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) utiliza mucha menos memoria y se ejecuta más rápido que la operación `COUNT(DISTINCT fieldName)`.
### Limitar los resultados de la consulta
Si solo se necesita una respuesta de muestra para una consulta, restrinja los resultados a una cantidad reducida de filas mediante la condición `LIMIT`. De lo contrario, la consulta arrojará resultados de gran tamaño y tardará más tiempo en ejecutarse.
Si se utiliza `LIMIT` junto con `ORDER BY`, pueden obtenerse resultados más rápidos para los registros N superiores o inferiores, ya que reduce la cantidad de memoria necesaria y el tiempo necesario para ordenarlos.
```
SELECT * FROM $EDS_ID
ORDER BY eventTime
LIMIT 100;
```
### Optimización de consultas LIKE
Puede usar `LIKE` para encontrar cadenas coincidentes, pero con cadenas largas, esto requiere un uso intensivo de cómputos. La funcion [https://trino.io/docs/current/functions/regexp.html#regexp_like](https://trino.io/docs/current/functions/regexp.html#regexp_like) es, en la mayoría de los casos, una alternativa más rápida.
A menudo, puede optimizar una búsqueda anclando la subcadena que está buscando. Por ejemplo, si busca un prefijo, es mejor usar “`substr`%” en lugar de “`substr`%” con el operador `LIKE` y “^`substr`” con la función `regexp_like`.
### Use `UNION ALL` en lugar de `UNION`
`UNION ALL` y `UNION` son dos formas de combinar los resultados de dos consultas en un solo resultado, pero `UNION` elimina los duplicados. `UNION` necesita procesar todos los registros y encontrar los duplicados, lo que requiere mucha memoria y procesamiento, pero `UNION ALL` es una operación relativamente rápida. A menos que necesite desduplicar registros, use `UNION ALL` para obtener el mejor rendimiento.
### Inclusión de las columnas necesarias únicamente
Si no necesita una columna, no la incluya en la consulta. Cuantos menos datos tenga que procesar una consulta, más rápido se ejecutará. Si tiene consultas que aplican `SELECT *` en la consulta más externa, debe cambiar `*` a una lista de columnas que necesita.
La cláusula `ORDER BY` devuelve los resultados de una consulta ordenados. Al ordenar una gran cantidad de datos, si no se dispone de la memoria necesaria, los resultados ordenados de manera intermedia se graban en el disco, lo que puede ralentizar la ejecución de la consulta. Si no necesita estrictamente ordenar el resultado, evite agregar una cláusula `ORDER BY`. Además, evite agregar `ORDER BY` a las consultas internas si no son estrictamente necesarias.
### Reducción del alcance de la función de ventana
Las [funciones de ventana](https://trino.io/docs/current/functions/window.html) guardan en la memoria todos los registros en los que operan para calcular su resultado. Cuando la ventana es muy grande, la función de ventana puede quedarse sin memoria. Para asegurarse de que las consultas se ejecuten dentro de los límites de memoria disponibles, reduzca el tamaño de las ventanas sobre las que trabajan las funciones de ventana al agregar la cláusula `PARTITION BY`.
A veces, las consultas con funciones de ventana se pueden reescribir sin funciones de ventana. Por ejemplo, en lugar de usar `row_number` o `rank`, puede usar funciones agregadas como [https://trino.io/docs/current/functions/aggregate.html#max_by](https://trino.io/docs/current/functions/aggregate.html#max_by) o [https://trino.io/docs/current/functions/aggregate.html#min_by](https://trino.io/docs/current/functions/aggregate.html#min_by).
La siguiente consulta busca el alias asignado más recientemente a cada clave de KMS mediante `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')
```
En este caso, la función `max_by` devuelve el alias del registro con la hora del último evento del grupo. Esta consulta se ejecuta más rápido y utiliza menos memoria que una consulta equivalente con una función de ventana.
## Soluciones alternativas para los errores de la consulta
En esta sección se ofrecen las soluciones para los errores de consulta más comunes.
**Topics**
+ [La consulta falla porque la respuesta es demasiado grande](#large-responses)
+ [La consulta falla debido al agotamiento de los recursos](#exhausted-resources)
### La consulta falla porque la respuesta es demasiado grande
Una consulta puede fallar si la respuesta es demasiado grande y da como resultado el mensaje `Query response is too large`. Si esto sucede, puede reducir el alcance de la agregación.
Las funciones de agregación, como `array_agg`, pueden hacer que al menos una fila de la respuesta a la consulta sea muy grande y ocasionar un error en la consulta. Por ejemplo, usar `array_agg(eventName)` en lugar de `array_agg(DISTINCT eventName)` aumentará considerablemente el tamaño de la respuesta debido a la duplicación de los nombres de los CloudTrail eventos seleccionados.
### La consulta falla debido al agotamiento de los recursos
Si no hay suficiente memoria disponible durante la ejecución de las operaciones que consumen mucha memoria, como uniones, agregaciones y funciones de ventana, los resultados intermedios se filtran en el disco, pero esto ralentiza la ejecución de la consulta y puede que no sea suficiente para evitar que la consulta falle con `Query exhausted resources at this scale factor`. Esto se puede solucionar si vuelve a intentar la consulta.
Si los errores anteriores persisten incluso después de optimizar la consulta, puede reducir el alcance de la consulta con `eventTime` de los eventos y ejecutar la consulta varias veces en intervalos más pequeños del rango de tiempo de la consulta original.