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.

Recomendaciones para optimizar las consultas

Siga las recomendaciones de esta sección para optimizar sus consultas.

Recomendaciones:

• Optimización de las agregaciones

• Utilice técnicas de aproximación

• Limite los resultados de las consultas

• Optimice las consultas LIKE

• Use UNION ALL en lugar de UNION

• Inclusión de las columnas necesarias únicamente

• Reduce el alcance de las funciones de la ventana

Optimización de las agregaciones

La exclusión de las columnas redundantes en GROUP BY las cláusulas puede mejorar el rendimiento, ya que menos columnas requieren menos memoria. Por ejemplo, en la siguiente consulta, podemos usar la arbitrary función en una columna redundante eventType para mejorar el rendimiento. La arbitrary función on eventType se utiliza para seleccionar el valor del campo de forma aleatoria del grupo, ya que el valor es el mismo y no es necesario incluirlo en la GROUP BY cláusula.

SELECT eventName, eventSource, arbitrary(eventType), count(*) 
FROM $EDS_ID 
GROUP BY eventName, eventSource

Es posible mejorar el rendimiento de la GROUP BY función ordenando la lista de campos GROUP BY en orden decreciente según su recuento de valores únicos (cardinalidad). Por ejemplo, si se obtiene el número de eventos de un tipo en cada uno Región de AWS, se puede mejorar el rendimiento utilizando el awsRegion ordeneventName, en lugar deawsRegion, en la GROUP BY función, eventName ya que hay más valores únicos de eventName que deawsRegion.

SELECT eventName, awsRegion, count(*) 
FROM $EDS_ID 
GROUP BY eventName, awsRegion

Utilice técnicas de aproximación

Siempre que 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_distinctutiliza mucha menos memoria y se ejecuta más rápido que la COUNT(DISTINCT fieldName) operación.

Limite los resultados de las consultas

Si solo se necesita una respuesta de muestra para una consulta, restrinja los resultados a un número reducido de filas mediante la LIMIT condición. 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 se pueden obtener resultados más rápidos para los N registros 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;

Optimice las consultas LIKE

Puede usar LIKE para encontrar cadenas coincidentes, pero con cadenas largas, esto requiere un uso intensivo de cómputos. En la mayoría de los casos, la regexp_likefunción es una alternativa más rápida.

A menudo, puedes optimizar una búsqueda anclando la subcadena que estás buscando. Por ejemplo, si buscas un prefijo, es mejor usar «%» en lugar de «% substrsubstr%» con el LIKE operador y «^» con la función. substr regexp_like

Use UNION ALL en lugar de UNION

UNION ALLy UNION son dos formas de combinar los resultados de dos consultas en un solo resultado, pero eliminan los duplicados. UNION UNIONnecesita procesar todos los registros y encontrar los duplicados, lo que supone un uso intensivo de 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 lo hacen SELECT * en la consulta más externa, debe cambiarla por una lista de columnas que necesite. *

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 forma 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 ORDER BY agregarlos a consultas internas si no es estrictamente necesario.

Reduce el alcance de las funciones de la ventana

Las funciones de ventana guardan en la memoria todos los registros sobre 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 ejecutan dentro de los límites de memoria disponibles, añada una PARTITION BY cláusula para reducir el tamaño de las ventanas sobre las que funcionan las funciones de ventana.

A veces, las consultas con funciones de ventana se pueden reescribir sin funciones de ventana. Por ejemplo, en lugar de usar row_number orank, puede usar funciones agregadas como max_byo min_by.

La siguiente consulta busca el alias asignado más recientemente a cada clave de KMS mediantemax_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 max_by función devuelve el alias del registro con la última hora del 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 consulta

En esta sección se proporcionan soluciones para los errores de consulta más comunes.

Fallos en las consultas:

• La consulta falla porque la respuesta es demasiado grande

• La consulta falla debido al agotamiento de los recursos

La consulta falla porque la respuesta es demasiado grande

Una consulta puede fallar si la respuesta es demasiado grande y da como resultado el mensajeQuery response is too large. Si esto ocurre, puede reducir el alcance de la agregación.

Las funciones de agregación, por ejemplo, array_agg pueden hacer que al menos una fila de la respuesta a la consulta sea muy grande y provocar 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 operaciones que consumen mucha memoria, como las uniones, las agregaciones y las funciones de ventana, los resultados intermedios se filtran en el disco, pero la pérdida de memoria ralentiza la ejecución de la consulta y puede ser insuficiente para evitar que la consulta falle. Query exhausted resources at this scale factor Esto se puede solucionar reintentando la consulta.

Si los errores anteriores persisten incluso después de optimizar la consulta, puede reducir el alcance eventTime de la consulta utilizando los eventos y ejecutar la consulta varias veces en intervalos más pequeños del intervalo de tiempo de la consulta original.