Optimización de consultas de CloudTrail Lake

En esta página, se ofrece 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.

Recomendaciones para optimizar las consultas

Siga las recomendaciones que se encuentran en esta sección para optimizar sus consultas.

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, si se obtiene la cantidad de eventos de un tipo en cada Región de AWS, puede mejorarse el rendimiento mediante eventName, el orden de awsRegion en la función GROUP BY en lugar de awsRegion, eventName ya que existen más valores únicos de eventName que de 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 para encontrar los valores más frecuentes. Por ejemplo, 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 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 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 max_by o 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.

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á de manera considerable el tamaño de la respuesta debido a la duplicación de los nombres de los eventos de CloudTrail 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.