Estadísticas de consulta

En este documento, se describen las estadísticas de consultas que Spanner ofrece como tablas integradas. Puedes recuperar estadísticas de las tablas SPANNER_SYS.QUERY_STATS* con sentencias de SQL.

Cuándo usar las estadísticas de consultas

Las estadísticas de consultas son útiles cuando necesitas investigar problemas de rendimiento o optimizar las consultas en tu base de datos de Spanner. Puedes usar las estadísticas de consultas para investigar el uso elevado de CPU, solucionar problemas de latencia de consultas elevada o reducir el uso de memoria.

Cómo acceder a las estadísticas de consultas

Spanner proporciona las estadísticas de consultas en el esquema SPANNER_SYS. Puedes usar las siguientes formas para acceder a los datos de SPANNER_SYS:

Los siguientes métodos de lectura única que proporciona Spanner no admiten SPANNER_SYS:

  • Realizar una lectura sólida desde una o varias filas de una tabla
  • Realizar una lectura inactiva desde una o varias filas en una tabla
  • Leer desde una o varias filas en un índice secundario

Para obtener más información, consulta Métodos de lectura única.

Uso de CPU agrupado por consulta

Con las siguientes tablas, se realiza un seguimiento de las consultas con el uso más alto de CPU durante un período específico:

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE: consultas durante intervalos de 1 minuto
  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE: consultas durante intervalos de 10 minutos
  • SPANNER_SYS.QUERY_STATS_TOP_HOUR: consultas durante intervalos de 1 hora

Estas tablas tienen las siguientes propiedades:

  • Cada tabla contiene datos de intervalos de tiempo que no se superponen de la duración que especifica el nombre de la tabla.

  • Los intervalos se basan en las horas del reloj

    • Los intervalos de 1 minuto finalizan en el minuto.
    • Los intervalos de 10 minutos finalizan cada 10 minutos a partir de la hora.
    • Los intervalos de 1 hora finalizan en punto.

    Por ejemplo, a las 11:59:30 a.m., los intervalos más recientes disponibles para las consultas de SQL son los siguientes:

    • 1 minuto: de 11:58:00 a 11:58:59 a.m.
    • 10 minutos: de 11:40:00 a 11:49:59 a.m.
    • 1 hora: de 10:00:00 a 10:59:59 a.m.

  • Spanner agrupa las estadísticas según el texto de la consulta en SQL. Si una consulta usa parámetros de consulta o si Spanner convierte automáticamente los valores literales en parámetros, Spanner agrupa todas las ejecuciones de esa consulta en una fila. Si la consulta usa literales de cadena que no se pueden convertir automáticamente en parámetros, Spanner solo agrupa las estadísticas si el texto completo de la consulta es idéntico. Cuando un texto difiere, cada consulta aparece como una fila separada. Para la DML por lotes, Spanner normaliza el lote desduplicando las sentencias idénticas consecutivas antes de generar la huella digital.

  • Si hay una etiqueta de solicitud presente, TEXT_FINGERPRINT es el hash de la etiqueta de solicitud. De lo contrario, es el hash del valor TEXT. Para las DML particionadas, TEXT_FINGERPRINT siempre es el hash del valor TEXT.

  • Cada fila contiene estadísticas de todas las ejecuciones de una consulta en SQL en particular para la que Spanner captura estadísticas durante el intervalo especificado.

  • Si Spanner no puede almacenar todas las consultas que se ejecutan durante el intervalo, el sistema prioriza las consultas con el mayor uso de CPU durante el intervalo especificado.

  • Las consultas con seguimiento incluyen las que se completaron, fallaron o canceló el usuario.

  • Un subconjunto de estadísticas es específico de las consultas que se ejecutaron, pero que no se completaron:

    • El recuento de ejecución y la latencia media en segundos en todas las consultas que no tuvieron éxito.

    • Recuento de ejecuciones para las consultas que agotaron el tiempo de espera.

    • Recuento de ejecuciones de las consultas que el usuario canceló o que fallaron debido a problemas de conectividad de red.

  • Todas las columnas de las tablas admiten valores nulos.

Las estadísticas de consultas para las sentencias de DML particionado ejecutadas con anterioridad tienen las siguientes propiedades:

  • Cada declaración DML particionada exitosa cuenta estrictamente como una ejecución. Una declaración DML particionada que falló, se canceló o se está ejecutando tiene un recuento de ejecuciones de cero.

  • No se hace un seguimiento de las estadísticas de ALL_FAILED_EXECUTION_COUNT, ALL_FAILED_AVG_LATENCY_SECONDS, CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT y TIMED_OUT_EXECUTION_COUNT para las DML particionadas.

  • Las estadísticas de cada declaración DML particionada ejecutada con anterioridad pueden aparecer en intervalos diferentes. SPANNER_SYS.QUERY_STATS_TOP_10MINUTE y SPANNER_SYS.QUERY_STATS_TOP_HOUR proporcionan una vista agregada para las sentencias DML particionadas que se completan en un plazo de 10 minutos y 1 hora, respectivamente. Para ver las estadísticas de las declaraciones cuya duración es superior a 1 hora, consulta el ejemplo de consulta.

Esquema de la tabla

Nombre de la columna Tipo Descripción
INTERVAL_END TIMESTAMP Fin del intervalo en el que se produjeron las ejecuciones de consultas incluidas
REQUEST_TAG STRING La etiqueta de solicitud opcional para esta operación de consulta. Para obtener más información sobre el uso de etiquetas, consulta Solución de problemas con etiquetas de solicitud.
QUERY_TYPE STRING Indica si una consulta es PARTITIONED_QUERY o QUERY. Una PARTITIONED_QUERY es una consulta con un partitionToken obtenido de la API de PartitionQuery o una sentencia de DML particionado. Todas las demás consultas y sentencias DML se indican con el tipo de consulta QUERY.
TEXT STRING Texto de consulta en SQL, truncado a aproximadamente 64 KB.

Las estadísticas de varias consultas que tienen la misma string de etiquetas se agrupan en una sola fila con REQUEST_TAG que coincide con esa string. Solo el texto de una de esas consultas se muestra en este campo, truncado a aproximadamente 64 KB. Para el DML por lotes, el conjunto de sentencias de SQL se reduce a una sola fila, concatenada con un delimitador de punto y coma. Los textos de SQL idénticos consecutivos se desduplican antes de truncarse.
TEXT_TRUNCATED BOOL Indica si el texto de la consulta se truncó o no
TEXT_FINGERPRINT INT64 El hash del valor REQUEST_TAG si está presente. De lo contrario, es el hash del valor TEXT. Corresponde al campo query_fingerprint en el registro de auditoría.
EXECUTION_COUNT INT64 Es la cantidad de veces que Spanner vio la consulta durante el intervalo.
AVG_LATENCY_SECONDS FLOAT64 Promedio de tiempo, en segundos, para cada ejecución de consulta dentro de la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga.
AVG_ROWS FLOAT64 Promedio de filas que mostró la consulta.
AVG_BYTES FLOAT64 Promedio de bytes de datos que mostró la consulta, sin incluir la sobrecarga de codificación de transmisión.
AVG_ROWS_SCANNED FLOAT64 Promedio de filas que analizó la consulta, sin incluir los valores borrados.
AVG_CPU_SECONDS FLOAT64 Es la cantidad promedio de segundos de tiempo de CPU que Spanner dedicó a todas las operaciones para ejecutar la consulta.
ALL_FAILED_EXECUTION_COUNT INT64 Cantidad de veces que la consulta falló durante el intervalo.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Promedio de tiempo, en segundos, para cada ejecución de consulta que falló en la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga.
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Cantidad de veces que el usuario canceló la consulta o falló debido a una conexión de red interrumpida durante el intervalo.
TIMED_OUT_EXECUTION_COUNT INT64 Cantidad de veces que se agotó el tiempo de espera de la consulta durante el intervalo.
AVG_BYTES_WRITTEN FLOAT64 Es la cantidad promedio de bytes que escribió la sentencia.
AVG_ROWS_WRITTEN FLOAT64 Es la cantidad promedio de filas que modifica la sentencia.
STATEMENT_COUNT INT64 Es la suma de las declaraciones agregadas en esta entrada. Para las consultas regulares y DML, esto es igual al recuento de ejecuciones. Para DML por lotes, Spanner captura la cantidad de declaraciones en el lote.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Es la cantidad de veces que se ejecutó la consulta como parte de una transacción de lectura y escritura. Esta columna te ayuda a determinar si puedes evitar las contenciones de bloqueo moviendo la consulta a una transacción de solo lectura.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Un histograma del tiempo de ejecución de la consulta. Los valores se miden en segundos.

El array contiene un solo elemento y tiene el siguiente tipo:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Para obtener más información sobre los valores, consulta Distribución y Exponencial.

Para calcular la latencia del percentil a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), que devuelve el percentil n estimado. Para ver un ejemplo relacionado, consulta Busca la latencia del percentil 99 para las consultas.

Para obtener más información, consulta Percentiles y métricas con valor de distribución.

AVG_MEMORY_PEAK_USAGE_BYTES FLOAT64

Durante la ejecución de una consulta distribuida, el uso de memoria máximo promedio (en bytes).

Usa esta estadística para identificar qué consultas o tamaños de datos de tablas tienen más probabilidades de alcanzar los límites de memoria.
AVG_MEMORY_USAGE_PERCENTAGE FLOAT64

Durante la ejecución de una consulta distribuida, el uso de memoria promedio requerido (como un porcentaje del límite de memoria permitido para esta consulta).

Esta estadística solo hace un seguimiento de la memoria que se requiere para que se ejecute la consulta. Algunos operadores usan memoria de almacenamiento en búfer adicional para mejorar el rendimiento. La memoria de almacenamiento en búfer adicional que se usa se puede ver en el plan de consulta, pero no se usa para calcular AVG_MEMORY_USAGE_PERCENTAGE, ya que la memoria de almacenamiento en búfer se usa para la optimización y no es obligatoria.

Usa esta estadística para identificar las consultas que se acercan al límite de uso de memoria y que corren el riesgo de fallar si aumenta el tamaño de los datos. Para mitigar el riesgo de que falle la consulta, consulta Prácticas recomendadas de SQL para optimizar estas consultas o dividirlas en partes que lean menos datos.
AVG_QUERY_PLAN_CREATION_TIME_SECS FLOAT64

Es el tiempo de CPU promedio en segundos que se dedica a la compilación de consultas, incluida la creación del entorno de ejecución de consultas.

Si el valor de esta columna es alto, usa consultas con parámetros.
AVG_FILESYSTEM_DELAY_SECS FLOAT64

Es el tiempo promedio que la consulta dedica a leer desde el sistema de archivos o a estar bloqueada en la entrada o salida (E/S).

Usa esta estadística para identificar la posible latencia alta que causa la E/S del sistema de archivos. Para mitigar este problema, agrega un índice o una cláusula STORING (GoogleSQL) o INCLUDE (PostgreSQL) a un índice existente.
AVG_REMOTE_SERVER_CALLS FLOAT64

Es la cantidad promedio de llamadas al servidor remoto (RPC) que completó la consulta.

Usa esta estadística para identificar si las diferentes consultas que analizan la misma cantidad de filas tienen una cantidad muy diferente de RPC. La consulta con un valor de RPC más alto podría beneficiarse si se agrega un índice o una cláusula STORING (GoogleSQL) o INCLUDE (PostgreSQL) a un índice existente.
AVG_ROWS_SPOOLED FLOAT64

Es la cantidad promedio de filas que la sentencia de consulta escribe en un disco temporal (no en la memoria).

Usa esta estadística para identificar consultas de latencia potencialmente alta que consumen mucha memoria y no se pueden ejecutar en la memoria. Para mitigar, cambia el orden de JOIN o agrega un índice que proporcione un SORT obligatorio.
AVG_DISK_IO_COST FLOAT64

Es el costo promedio de esta consulta en términos de la carga de disco del HDD de Spanner.

Usa este valor para realizar comparaciones de costos de E/S de HDD relativas entre las lecturas que ejecutas en la base de datos. La consulta de datos en el almacenamiento en HDD genera un cargo en la capacidad de carga del disco HDD de la instancia. Un valor más alto indica que estás usando más carga de disco HDD y que tu consulta podría ser más lenta que si se ejecutara en SSD. Además, si la carga del disco HDD está al máximo, el rendimiento de las consultas podría verse aún más afectado. Puedes supervisar la capacidad total de la carga del disco HDD de la instancia como un porcentaje. Para agregar más capacidad de carga de disco HDD, puedes agregar más unidades de procesamiento o nodos a tu instancia. Para obtener más información, consulta Cambia la capacidad de procesamiento. Para mejorar el rendimiento de las consultas, también considera mover algunos datos a SSD.

Para las cargas de trabajo que consumen mucha E/S de disco, te recomendamos que almacenes los datos a los que se accede con frecuencia en el almacenamiento SSD. Los datos a los que se accede desde SSD no consumen capacidad de carga de disco HDD. Puedes almacenar tablas, columnas o índices secundarios selectivos en el almacenamiento SSD según sea necesario, mientras mantienes los datos a los que se accede con poca frecuencia en el almacenamiento HDD. Para obtener más información, consulta Descripción general del almacenamiento por niveles.
LATENCY_DISTRIBUTION_JSON_STRING STRING

Un histograma del tiempo de ejecución de la consulta. Los valores se miden en segundos.

Es una representación de cadena compatible con JSON de la estadística LATENCY_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna LATENCY_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL. Esta columna contiene la distribución.

Para calcular la latencia del percentil a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), que devuelve el percentil n estimado. Para ver un ejemplo relacionado, consulta Busca la latencia del percentil 99 para las consultas con la columna LATENCY_DISTRIBUTION_JSON_STRING.

Para obtener más información, consulta Percentiles y métricas con valor de distribución.

AVG_COLUMNAR_READ_SHARE FLOAT64

Es el porcentaje promedio de bytes leídos del almacenamiento en columnas del total de bytes leídos del almacenamiento basado en filas y en columnas, expresado como una fracción entre 0 y 1.

Usa esta estadística para supervisar el uso del motor de columnas en las consultas. Para obtener más información, consulta Supervisa el rendimiento del motor en columnas.

QUERY_OPTIMIZER_VERSIONS ARRAY<INT64>

Son las versiones del optimizador de consultas que se usaron para las consultas en este período.
STATISTICS_PACKAGE_NAMES ARRAY<STRING>

Son los nombres de los paquetes de estadísticas que se usaron para las consultas en este período.
CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Es un histograma del tiempo de CPU que Spanner dedicó a todas las operaciones para ejecutar la consulta. Los valores se miden en segundos.

El array tiene la siguiente estructura:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Para obtener más información sobre los tipos de valores, consulta Distribución y Exponencial.

Para calcular los percentiles de segundos de CPU a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Es una representación de cadena compatible con JSON de la estadística CPU_SECONDS_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna CPU_SECONDS_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL.

Para calcular los percentiles de segundos de CPU a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Es un histograma de la cantidad de filas que analizó la consulta, sin incluir los valores borrados.

El array tiene la siguiente estructura:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Para obtener más información sobre los tipos de valores, consulta Distribución y Exponencial.

Para calcular los percentiles de las filas analizadas de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Es una representación de cadena compatible con JSON de la estadística ROW_SCANNED_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna ROW_SCANNED_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL.

Para calcular los percentiles de las filas analizadas de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

EXECUTION_COUNT, AVG_LATENCY_SECONDS, LATENCY_DISTRIBUTION y LATENCY_DISTRIBUTION_JSON_STRING para las consultas con errores incluyen las consultas que fallaron debido a una sintaxis incorrecta o que encontraron un error transitorio, pero que se realizaron correctamente cuando se volvieron a intentar. Estas estadísticas no hacen un seguimiento de las sentencias DML particionadas con errores ni canceladas.

Estadísticas agregadas

También hay tablas que hacen un seguimiento de los datos agregados de todas las consultas para las que Spanner capturó estadísticas en un período específico:

  • SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Consultas en intervalos de 1 minuto
  • SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Consultas en intervalos de 10 minutos
  • SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Consultas en intervalos de 1 hora

Estas tablas tienen las siguientes propiedades:

  • Cada tabla contiene datos de intervalos de tiempo que no se superponen y que tienen la duración que especifica el nombre de la tabla.

  • Los intervalos se basan en tiempos de reloj. Los intervalos de 1 minuto finalizan en el minuto, los intervalos de 10 minutos finalizan cada 10 minutos a partir de la hora y los intervalos de 1 hora finalizan en la hora.

    Por ejemplo, a las 11:59:30 a.m., los intervalos más recientes disponibles para las consultas de SQL son los siguientes:

    • 1 minuto: de 11:58:00 a 11:58:59 a.m.
    • 10 minutos: de 11:40:00 a 11:49:59 a.m.
    • 1 hora: de 10:00:00 a 10:59:59 a.m.

  • Cada fila contiene estadísticas de todas las consultas que se ejecutaron en la base de datos durante el intervalo especificado, combinadas. Solo hay una fila por intervalo de tiempo y, además, incluye consultas completadas, consultas con errores y consultas que canceló el usuario.

  • Las estadísticas capturadas en las tablas TOTAL pueden incluir consultas que Spanner no capturó en las tablas TOP.

  • Algunas columnas de estas tablas se exponen como métricas en Cloud Monitoring. Las métricas expuestas son las siguientes:

    • Recuento de ejecución de consultas
    • Errores de consulta
    • Latencias de las consultas
    • Recuento de filas devueltas
    • Recuento de filas analizadas
    • Recuento de bytes devueltos
    • Tiempo de CPU de la consulta

    Para obtener más información, consulta Métricas de Spanner.

Esquema de la tabla

Nombre de la columna Tipo Descripción
INTERVAL_END TIMESTAMP Fin del intervalo en el que se produjeron las ejecuciones de consultas incluidas
EXECUTION_COUNT INT64 Es la cantidad de veces que Spanner vio la consulta durante el intervalo de tiempo.
AVG_LATENCY_SECONDS FLOAT64 Promedio de tiempo, en segundos, para cada ejecución de consulta dentro de la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga.
AVG_ROWS FLOAT64 Promedio de filas que mostró la consulta.
AVG_BYTES FLOAT64 Promedio de bytes de datos que mostró la consulta, sin incluir la sobrecarga de codificación de transmisión.
AVG_ROWS_SCANNED FLOAT64 Promedio de filas que analizó la consulta, sin incluir los valores borrados.
AVG_CPU_SECONDS FLOAT64 Es la cantidad promedio de segundos de tiempo de CPU que Spanner dedicó a todas las operaciones para ejecutar la consulta.
ALL_FAILED_EXECUTION_COUNT INT64 Cantidad de veces que la consulta falló durante el intervalo.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Promedio de tiempo, en segundos, para cada ejecución de consulta que falló en la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga.
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Cantidad de veces que el usuario canceló la consulta o falló debido a una conexión de red interrumpida durante el intervalo.
TIMED_OUT_EXECUTION_COUNT INT64 Cantidad de veces que se agotó el tiempo de espera de la consulta durante el intervalo.
AVG_BYTES_WRITTEN FLOAT64 Es la cantidad promedio de bytes que escribió la sentencia.
AVG_ROWS_WRITTEN FLOAT64 Es la cantidad promedio de filas que modifica la sentencia.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Es la cantidad de veces que se ejecutaron consultas como parte de transacciones de lectura y escritura. Esta columna te ayuda a determinar si puedes evitar las contenciones de bloqueo moviendo algunas consultas a transacciones de solo lectura.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Un histograma del tiempo de ejecución de las consultas. Los valores se miden en segundos.

Especifica el array de la siguiente manera:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Para obtener más información sobre los valores, consulta Distribución y Exponencial.

Para calcular la latencia del percentil a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), que devuelve el percentil n estimado. Para ver un ejemplo relacionado, consulta Busca la latencia del percentil 99 para las consultas.

Para obtener más información, consulta Percentiles y métricas con valor de distribución.

LATENCY_DISTRIBUTION_JSON_STRING STRING

Un histograma del tiempo de ejecución de la consulta. Los valores se miden en segundos.

Es una representación de cadena compatible con JSON de la estadística LATENCY_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna LATENCY_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL. Esta columna contiene la Distribución.

Para calcular la latencia del percentil a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), que devuelve el percentil n estimado. Para ver un ejemplo relacionado, consulta Busca la latencia del percentil 99 para las consultas con la columna LATENCY_DISTRIBUTION_JSON_STRING.

Para obtener más información, consulta Percentiles y métricas con valor de distribución.

AVG_COLUMNAR_READ_SHARE FLOAT64

Es el porcentaje promedio de bytes leídos del almacenamiento en columnas del total de bytes leídos del almacenamiento basado en filas y en columnas, expresado como una fracción entre 0 y 1.

Usa esta estadística para supervisar el uso del motor de columnas en las consultas. Para obtener más información, consulta Supervisa el rendimiento del motor en columnas.

CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Es un histograma del tiempo de CPU que Spanner dedicó a todas las operaciones para ejecutar la consulta. Los valores se miden en segundos.

El array tiene la siguiente estructura:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Para obtener más información sobre los tipos de valores, consulta Distribución y Exponencial.

Para calcular los percentiles de segundos de CPU a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Es una representación de cadena compatible con JSON de la estadística CPU_SECONDS_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna CPU_SECONDS_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL.

Para calcular los percentiles de segundos de CPU a partir de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Es un histograma de la cantidad de filas que analizó la consulta, sin incluir los valores borrados.

El array tiene la siguiente estructura:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Para obtener más información sobre los tipos de valores, consulta Distribución y Exponencial.

Para calcular los percentiles de las filas analizadas de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Es una representación de cadena compatible con JSON de la estadística ROW_SCANNED_DISTRIBUTION. La cadena JSON es un objeto JSON con la misma estructura que el STRUCT definido en la columna ROW_SCANNED_DISTRIBUTION.

Esta columna es compatible con las bases de datos de dialecto de GoogleSQL y PostgreSQL.

Para calcular los percentiles de las filas analizadas de la distribución, usa la función SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Retención de datos

Como mínimo, Spanner conserva los datos de cada tabla durante los siguientes períodos:

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE y SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Intervalos que abarcan las 6 horas anteriores.

  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE y SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Intervalos que abarcan los 4 días anteriores.

  • SPANNER_SYS.QUERY_STATS_TOP_HOUR y SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Son intervalos que abarcan los 30 días anteriores.

Consultas de ejemplo

En esta sección, se incluyen varias sentencias de SQL de ejemplo que recuperan estadísticas de consultas. Puedes ejecutar estas sentencias de SQL con las bibliotecas cliente, Google Cloud CLI o la consola de Google Cloud .

Enumera las estadísticas básicas de cada consulta en un período determinado

La siguiente consulta muestra los datos sin procesar de las consultas principales en el minuto anterior:

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;

Enumera las estadísticas de las sentencias DML particionadas que se ejecutan durante más de una hora

La siguiente consulta devuelve el recuento de ejecuciones y el promedio de filas escritas por las consultas de DML particionadas principales en las horas anteriores:

SELECT text,
       request_tag,
       interval_end,
       sum(execution_count) as execution_count,
       sum(avg_rows_written*execution_count)/sum(execution_count) as avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE starts_with(text, "UPDATE") AND query_type = "PARTITIONED_QUERY"
group by text, request_tag, interval_end
ORDER BY interval_end DESC;

Enumera las consultas con el uso de CPU más alto

La siguiente consulta muestra las consultas con el uso de CPU más alto en la hora anterior:

SELECT text,
       request_tag,
       execution_count AS count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;

Conoce el recuento total de ejecuciones en un período determinado

La siguiente consulta muestra la cantidad total de consultas ejecutadas en el intervalo completo de 1 minuto más reciente:

SELECT interval_end,
       execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_minute);

Encuentra la latencia promedio de una consulta

La siguiente consulta muestra la información de latencia promedio de una consulta específica:

SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";

Busca la latencia del percentil 99 para las consultas

Comparar la latencia promedio con la latencia del percentil 99 ayuda a identificar posibles consultas atípicas con tiempos de ejecución altos.

Las siguientes consultas devuelven el percentil 99 del tiempo de ejecución en las consultas ejecutadas en los 10 minutos anteriores.

Para las bases de datos de dialecto de GoogleSQL, puedes usar la columna LATENCY_DISTRIBUTION:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

En el caso de las bases de datos con dialecto de PostgreSQL, usa la columna LATENCY_DISTRIBUTION_JSON_STRING en su lugar:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Encuentra las consultas que analizan la mayor cantidad de datos

Puedes usar la cantidad de filas analizadas por una consulta como una medida de la cantidad de datos que analizó la consulta. La siguiente consulta muestra el número de filas analizadas por consultas ejecutadas en la hora anterior:

SELECT text,
       execution_count,
       avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;

Busca las sentencias que escribieron la mayor cantidad de datos

Puedes usar la cantidad de filas escritas (o bytes escritos) por DML como una medida de la cantidad de datos que modificó la consulta. La siguiente consulta devuelve la cantidad de filas escritas por las sentencias DML ejecutadas en la hora anterior:

SELECT text,
       execution_count,
       avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;

Suma el uso de CPU de todas las consultas

La siguiente consulta muestra el número de horas de CPU usadas en la hora anterior:

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_hour);

Enumera las consultas que fallaron en un período determinado

La siguiente consulta muestra los datos sin procesar, incluidos el recuento de ejecuciones y la latencia promedio de las consultas con errores para las consultas principales del minuto anterior. Estas estadísticas no hacen un seguimiento de las sentencias DML particionadas con errores y canceladas.

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       all_failed_execution_count,
       all_failed_avg_latency_seconds,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

Cómo encontrar el recuento total de errores en un período determinado

La siguiente consulta devuelve la cantidad total de consultas que no se pudieron ejecutar en el intervalo de 1 minuto completo más reciente. Estas estadísticas no hacen un seguimiento de las sentencias DML particionadas con errores y canceladas.

SELECT interval_end,
       all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;

Enumera las consultas que más tiempo de espera agotan

La siguiente consulta muestra las consultas con el recuento de tiempo de espera más alto en la hora anterior.

SELECT text,
       execution_count AS count,
       timed_out_execution_count AS timeout_count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;

Encuentra la latencia promedio de las ejecuciones exitosas y fallidas de una consulta

La siguiente consulta muestra la latencia promedio combinada, la latencia promedio de las ejecuciones exitosas y la latencia promedio de las ejecuciones fallidas de una consulta específica. Estas estadísticas no hacen un seguimiento de las sentencias DML particionadas con errores y canceladas.

SELECT avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text LIKE "select x from table where x=@foo;";

Soluciona problemas de uso elevado de CPU o latencia de consultas elevada con las estadísticas de consultas

Las estadísticas de consultas son útiles cuando necesitas investigar el uso alto de CPU en tu base de datos de Spanner o cuando solo intentas comprender las formas de consulta con uso intensivo de CPU en tu base de datos. Inspeccionar las consultas que usan cantidades significativas de recursos de la base de datos les brinda a los usuarios de Spanner una forma potencial de reducir los costos operativos y, posiblemente, mejorar las latencias generales del sistema.

Puedes usar código SQL o el panel de Estadísticas de consultas para investigar consultas problemáticas en tu base de datos. En los siguientes temas, se muestra cómo puedes investigar esas consultas con código SQL.

Si bien el siguiente ejemplo se enfoca en el uso de CPU, se pueden seguir pasos similares para solucionar problemas de latencia de consultas elevada y encontrar las consultas con las latencias más altas. Selecciona intervalos de tiempo y consultas por latencia en lugar de uso de CPU.

Selecciona un período para investigar

Para comenzar la investigación, busca un momento en el que la aplicación comience a experimentar un uso alto de CPU. Por ejemplo, si el problema comenzó a ocurrir alrededor de las 5:00 p.m. del 24 de julio de 2020 UTC.

Recopila estadísticas de consultas para el período seleccionado

Después de seleccionar un período para comenzar tu investigación, consulta las estadísticas recopiladas en la tabla QUERY_STATS_TOTAL_10MINUTE en ese momento. Los resultados de esta consulta podrían indicar cómo cambiaron la CPU y otras estadísticas de consulta durante ese período.

La siguiente consulta muestra las estadísticas de consultas agregadas de 16:30 a 17:30 UTC inclusive. La consulta usa ROUND para restringir la cantidad de decimales con fines de visualización.

SELECT interval_end,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_rows,2) AS rows_returned,
       ROUND(avg_bytes,2) AS bytes,
       ROUND(avg_rows_scanned,2) AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
  interval_end >= "2020-07-24T16:30:00Z"
  AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;

La ejecución de la consulta arrojó los siguientes resultados.

interval_end count Latencia Filas mostradas bytes Filas analizadas CPU promedio
2020-07-24T16:30:00Z 6 0.06 5.00 536.00 16.67 0.035
2020-07-24T16:40:00Z 55 0.02 0.22 25.29 0.22 0.004
2020-07-24T16:50:00Z 102 0.02 0.30 33.35 0.30 0.004
2020-07-24T17:00:00Z 154 1.06 4.42 486.33 7792208.12 4.633
2020-07-24T17:10:00Z 94 0.02 1.68 106.84 1.68 0.006
2020-07-24T17:20:00Z 110 0.02 0.38 34.60 0.38 0.005
2020-07-24T17:30:00Z 47 0.02 0.23 24.96 0.23 0.004

En la tabla anterior, observa que el tiempo de CPU promedio, la columna avg_cpu en la tabla de resultados, es más alto en los intervalos destacados que terminan a las 17:00. Además, observa que la cantidad promedio de filas analizadas es mucho mayor. Esto indica que las consultas más demandantes se ejecutaron entre las 16:50 y las 17:00. Elige ese intervalo para investigar más en el siguiente paso.

Encuentra las consultas que causan un uso alto de CPU

Con un intervalo de tiempo para investigar seleccionado, consulta la tabla QUERY_STATS_TOP_10MINUTE. Los resultados de esta consulta pueden ayudar a indicar qué consultas causan un uso de CPU elevado.

SELECT text_fingerprint AS fingerprint,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_cpu_seconds,3) AS cpu,
       ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10minute
WHERE
  interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;

Cuando se ejecuta esta consulta, se obtienen los siguientes resultados.

Fingerprint count Latencia cpu total_cpu
5505124206529314852 30 3.88 17.635 529.039
1697951036096498470 10 4.49 18.388 183.882
2295109096748351518 1 0.33 0.048 0.048
11618299167612903606 1 0.25 0.021 0.021
10302798842433860499 1 0.04 0.006 0.006
123771704548746223 1 0.04 0.006 0.006
4216063638051261350 1 0.04 0.006 0.006
3654744714919476398 1 0.04 0.006 0.006
2999453161628434990 1 0.04 0.006 0.006
823179738756093706 1 0.02 0.005 0.0056

Las 2 consultas principales, destacadas en la tabla de resultados, son valores atípicos en términos de CPU y latencia promedio, así como la cantidad de ejecuciones y la CPU total. Investiga la primera consulta que aparece en estos resultados.

Compara las ejecuciones de consultas a lo largo del tiempo

Después de acotar la investigación, verifica la tabla QUERY_STATS_TOP_MINUTE. Si comparas las ejecuciones a lo largo del tiempo para una consulta en particular, puedes buscar correlaciones entre la cantidad de filas o bytes devueltos, o la cantidad de filas analizadas y el uso elevado de CPU o la latencia. Una desviación puede indicar que no hay uniformidad en los datos. La cantidad constante de filas analizadas puede indicar la falta de índices adecuados o un orden de unión subóptimo.

Investiga la consulta que muestra el uso de CPU promedio más alto y la latencia más alta ejecutando la siguiente sentencia que filtra por el text_fingerprint de esa consulta.

SELECT interval_end,
       ROUND(avg_latency_seconds,2) AS latency,
       avg_rows AS rows_returned,
       avg_bytes AS bytes_returned,
       avg_rows_scanned AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;

Cuando se ejecuta esta consulta, se muestran los siguientes resultados.

interval_end Latencia Filas mostradas bytes_devueltos Filas analizadas cpu
2020-07-24T17:00:00Z 4.55 21 2365 30000000 19.255
2020-07-24T16:00:00Z 3.62 21 2365 30000000 17.255
2020-07-24T15:00:00Z 4.37 21 2365 30000000 18.350
2020-07-24T14:00:00Z 4.02 21 2365 30000000 17.748
2020-07-24T13:00:00Z 3.12 21 2365 30000000 16.380
2020-07-24T12:00:00Z 3.45 21 2365 30000000 15.476
2020-07-24T11:00:00Z 4.94 21 2365 30000000 22.611
2020-07-24T10:00:00Z 6.48 21 2365 30000000 21.265
2020-07-24T09:00:00Z 0.23 21 2365 5 0.040
2020-07-24T08:00:00Z 0.04 21 2365 5 0.021
2020-07-24T07:00:00Z 0.09 21 2365 5 0.030

Si examinas los resultados anteriores, observa que la cantidad de filas analizadas, la CPU utilizada y la latencia cambiaron de forma significativa alrededor de las 9:00 a.m. Para comprender por qué estos números aumentaron de forma tan drástica, examina el texto de la consulta y observa si algún cambio en el esquema podría haber afectado la consulta.

Usa la siguiente consulta para recuperar el texto de la consulta que estás investigando.

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

Esta acción devuelve el siguiente resultado.

text text_truncated
selecciona * en los pedidos en los que o_custkey = 36901; falso

Si examinas el texto de la consulta que se muestra, notarás que la consulta filtra un campo llamado o_custkey. Esta es una columna sin clave en la tabla orders. Como suele suceder, hubo un índice en esa columna que se descartó cerca de las 9 a.m. Esto explica el cambio en el costo de esta consulta. Puedes volver a agregar el índice o, si la consulta se ejecuta con poca frecuencia, decidir no tener el índice y aceptar el costo de lectura más alto.

Hasta ahora, la investigación se enfocó en las consultas que se completaron correctamente y se identificó un motivo por el que la base de datos experimentaba una degradación del rendimiento. En el siguiente paso, enfócate en las consultas con errores o canceladas, y examina esos datos para obtener más información.

Investiga las consultas con errores

Las consultas que no se completan correctamente siguen consumiendo recursos antes de que se agote el tiempo de espera, se cancelen o fallen de alguna otra manera. Spanner hace un seguimiento del recuento de ejecuciones y los recursos que consumen las consultas con errores junto con las correctas. Estas estadísticas no hacen un seguimiento de las sentencias DML particionadas con errores y canceladas.

Para verificar si las consultas con errores contribuyen de forma significativa al uso del sistema, primero verifica cuántas consultas fallaron en el intervalo de tiempo de interés.

SELECT interval_end,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
  interval_end >= "2020-07-24T16:50:00Z"
  AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;
interval_end Cantidad de consultas fallidas Latencia
2020-07-24T16:52:00Z 1 15.211391
2020-07-24T16:53:00Z 3 58.312232

Para investigar más, busca las consultas que tienen más probabilidades de fallar con la siguiente consulta.

SELECT interval_end,
       text_fingerprint,
       execution_count,
       avg_latency_seconds AS avg_latency,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS failed_latency,
       cancelled_or_disconnected_execution_count AS cancel_count,
       timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
interval_end text_fingerprint execution_count Cantidad de consultas fallidas cancelar_recuento para_recuento
2020-07-24T16:52:00Z 5505124206529314852 3 1 1 0
2020-07-24T16:53:00Z 1697951036096498470 2 1 1 0
2020-07-24T16:53:00Z 5505124206529314852 5 2 1 1

Como se muestra en la tabla anterior, la consulta con la huella digital 5505124206529314852 falló varias veces durante diferentes intervalos de tiempo. Dado un patrón de fallas como este, es interesante comparar la latencia de las ejecuciones correctas con las fallidas.

SELECT interval_end,
       avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text_fingerprint = 5505124206529314852;
interval_end latencia_promedio_combinada latencia_ejecución_fallida latencia_ejecución_exitosa
2020-07-24T17:00:00Z 3.880420 13.830709 2.774832

Aplicar prácticas recomendadas

Después de identificar una consulta candidata para la optimización, observa el perfil de consulta y trata de optimizarla con las prácticas recomendadas de SQL.

¿Qué sigue?