Estadísticas de división

En esta página, se describe cómo detectar y depurar hotspots en tu base de datos. Puedes acceder a las estadísticas sobre los hotspots en las divisiones con GoogleSQL y PostgreSQL.

Spanner almacena tus datos como un espacio de claves contiguo, ordenado por las claves primarias de tus tablas y tus índices. Una división es un rango de filas de un conjunto de tablas o un índice. El inicio de la división se denomina inicio de la división. El límite de división establece el final de la división. La división incluye el inicio de la división, pero no el límite.

En Spanner, los hotspots son situaciones en las que se envían demasiadas solicitudes al mismo servidor, lo que satura los recursos del servidor y puede causar latencias altas. Las divisiones afectadas por hotspots se conocen como divisiones activas o activas.

La estadística de hotspot de una división (identificada en el sistema como CPU_USAGE_SCORE) es una medición de la carga en una división que está restringida por los recursos disponibles en el servidor. Esta medición se proporciona como un porcentaje. Si más del 50% de la carga de una división está restringida por los recursos disponibles, la división se considera caliente. Si el 100% de la carga en una división está restringida, esta se considera caliente.

Spanner usa la división basada en la carga para distribuir de manera uniforme la carga de datos entre los servidores de la instancia. Las divisiones en caliente y en caliente se pueden mover entre servidores para el balanceo de cargas o se pueden dividir en divisiones más pequeñas. Sin embargo, es posible que Spanner no pueda equilibrar la carga, incluso después de varios intentos de división, debido a los antipatrones en la aplicación. Por lo tanto, los hotspots persistentes que duran al menos 10 minutos pueden necesitar más soluciones de problemas y posibles cambios en la aplicación.

Las estadísticas de división caliente de Spanner te ayudan a identificar las divisiones en las que se producen los hotspots. Luego, puedes realizar cambios en tu aplicación o esquema según sea necesario. Puedes recuperar estas estadísticas de las tablas del sistema SPANNER_SYS.SPLIT_STATS_TOP_MINUTE con instrucciones de SQL.

Disponibilidad de las estadísticas de división en caliente

Spanner proporciona las estadísticas de división en caliente en el esquema SPANNER_SYS. Los datos de SPANNER_SYS solo están disponibles a través de las interfaces de Google SQL y PostgreSQL. Puedes usar las siguientes formas para acceder a estos datos:

• Página de Spanner Studio de una base de datos en la consola de Google Cloud
• El comando gcloud spanner databases execute-sql
• La API de executeQuery

Las APIs de lectura única de Spanner no son compatibles con SPANNER_SYS.

Estadísticas de división activa

Usa la siguiente tabla para hacer un seguimiento de las divisiones activas:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Muestra las divisiones que son populares durante intervalos de 1 minuto.

Estas tablas tienen las siguientes propiedades:

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

• Los intervalos se basan en tiempos de reloj:

  • Los intervalos de 1 minuto finalizan en el minuto.

• Después de cada intervalo, Spanner recopila datos de todos los servidores y, luego, los pone a disposición en las tablas SPANNER_SYS poco después.

  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.

• Spanner agrupa las estadísticas por divisiones.

• Cada fila contiene un porcentaje que indica qué tan caliente o templada está una división, para cada división de la que Spanner captura estadísticas durante el intervalo especificado.

• Si menos del 50% de la carga en una división está restringida por los recursos disponibles, Spanner no captura la estadística. Si Spanner no puede almacenar todas las divisiones activas durante el intervalo, el sistema prioriza las divisiones con el porcentaje de CPU_USAGE_SCORE más alto durante el intervalo especificado. Si no se muestran divisiones, significa que no hay hotspots.

Esquema de la tabla

En la siguiente tabla, se muestra el esquema de la tabla para las siguientes estadísticas:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Nombre de la columna	Tipo	Descripción
INTERVAL_END	TIMESTAMP	Final del intervalo de tiempo en el cual la división estaba activa
SPLIT_START	STRING	Clave inicial del rango de filas en la división. El inicio de la división también puede ser <begin>, lo que indica el inicio del espacio de claves.
SPLIT_LIMIT	STRING	Es la clave de límite para el rango de filas en la división. La clave de límite también puede ser <end>, lo que indica el final del espacio de claves|
CPU_USAGE_SCORE	INT64	Es el porcentaje de CPU_USAGE_SCORE de las divisiones. Un porcentaje de CPU_USAGE_SCORE del 50% indica la presencia de divisiones activas o as.
AFFECTED_TABLES	STRING ARRAY	Son las tablas cuyas filas podrían estar en la división.

Nota: Las divisiones con porcentajes de CPU_USAGE_SCORE inferiores al 100% se pueden usar para hacer un seguimiento de las tendencias a lo largo del tiempo. Spanner usa la división basada en la carga para equilibrar la carga entre los servidores y, por lo tanto, es posible que veas que las divisiones cambian o se reducen con el tiempo. Sin embargo, es posible que Spanner no pueda equilibrar la carga debido a patrones problemáticos en la aplicación, y es posible que las divisiones activas permanezcan después de varias iteraciones de la división basada en la carga de Spanner. Por lo tanto, la presencia de divisiones activas durante más de 10 minutos es un indicador de que es posible que debas investigar más a fondo.

Claves de inicio y límite de división

Una división es un rango de filas contiguas de una base de datos y se define por sus claves inicio y límite. Una división puede ser una sola fila, un rango de filas estrecho o un rango de filas amplio, y la división puede incluir varias tablas o índices.

Las columnas SPLIT_START y SPLIT_LIMIT identifican las claves primarias de una división activa o en caché.

Esquema de ejemplo

El siguiente esquema es una tabla de ejemplo para los temas de esta página.

GoogleSQL

CREATE TABLE Users (
  UserId INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName STRING(MAX),
) PRIMARY KEY(UserId);

CREATE INDEX UsersByFirstName ON Users(FirstName DESC);

CREATE TABLE Threads (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  Starred BOOL,
) PRIMARY KEY(UserId, ThreadId),
  INTERLEAVE IN PARENT Users ON DELETE CASCADE;

CREATE TABLE Messages (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  MessageId INT64 NOT NULL,
  Subject STRING(MAX),
  Body STRING(MAX),
) PRIMARY KEY(UserId, ThreadId, MessageId),
  INTERLEAVE IN PARENT Threads ON DELETE CASCADE;

CREATE INDEX MessagesIdx ON Messages(UserId, ThreadId, Subject),
INTERLEAVE IN Threads;

PostgreSQL

CREATE TABLE users
(
   userid    BIGINT NOT NULL PRIMARY KEY,-- INT64 to BIGINT
   firstname VARCHAR(max),-- STRING(MAX) to VARCHAR(MAX)
   lastname  VARCHAR(max)
);

CREATE INDEX usersbyfirstname
  ON users(firstname DESC);

CREATE TABLE threads
  (
    userid   BIGINT NOT NULL,
    threadid BIGINT NOT NULL,
    starred  BOOLEAN, -- BOOL to BOOLEAN
    PRIMARY KEY (userid, threadid),
    CONSTRAINT fk_threads_user FOREIGN KEY (userid) REFERENCES users(userid) ON
    DELETE CASCADE -- Interleave to Foreign Key constraint
  );

CREATE TABLE messages
  (
    userid    BIGINT NOT NULL,
    threadid  BIGINT NOT NULL,
    messageid BIGINT NOT NULL PRIMARY KEY,
    subject   VARCHAR(max),
    body      VARCHAR(max),
    CONSTRAINT fk_messages_thread FOREIGN KEY (userid, threadid) REFERENCES
    threads(userid, threadid) ON DELETE CASCADE
  -- Interleave to Foreign Key constraint
  );

CREATE INDEX messagesidx ON messages(userid, threadid, subject), REFERENCES
threads(userid, threadid);

Imagina que tu espacio de claves se ve de la siguiente manera:

CLAVE PRIMARIA
<begin>
Users()
Threads()
Users(2)
Users(3)
Threads(3)
Threads(3,"a")
Messages(3,"a",1)
Messages(3,"a",2)
Threads(3, "aa")
Users(9)
Users(10)
Threads(10)
UsersByFirstName("abc")
UsersByFirstName("abcd")
<end>

Ejemplo de divisiones

A continuación, se muestran algunos ejemplos de divisiones para ayudarte a comprender cómo se ven.

SPLIT_START y SPLIT_LIMIT pueden indicar la fila de una tabla o un índice, o pueden ser <begin> y <end>, que representan los límites del espacio de claves de la base de datos. SPLIT_START y SPLIT_LIMIT también pueden contener claves truncadas, que son claves que preceden a cualquier clave completa en la tabla. Por ejemplo, Threads(10) es un prefijo para cualquier fila Threads intercalada en Users(10).

SPLIT_START	SPLIT_LIMIT	AFFECTED_TABLES	EXPLICACIÓN
Users(3)	Users(10)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en la fila con UserId=3 y termina en la fila anterior a la fila con UserId = 10. La división contiene las filas de la tabla Users y todas sus filas de tablas intercaladas de UserId=3 a 10.
Messages(3,"a",1)	Threads(3,"aa")	Threads, Messages, MessagesIdx	La división comienza en la fila con UserId=3, ThreadId="a" y MessageId=1 y termina en la fila anterior a la fila con la clave de UserId=3 y ThreadsId = "aa". La división contiene todas las tablas entre Messages(3,"a",1) y Threads(3,"aa"). Como split_start y split_limit están intercalados en la misma fila de la tabla de nivel superior, la división contiene las filas de las tablas intercaladas entre el inicio y el límite. Consulta schemas-overview para comprender cómo se ubican las tablas intercaladas.
Messages(3,"a",1)	<end>	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en la tabla de mensajes en la fila con la clave UserId=3, ThreadId="a" y MessageId=1. La división aloja todas las filas de split_start a <end>, el final del espacio de claves de la base de datos. Todas las filas de las tablas que siguen a split_start, como Users(4), se incluyen en la división.
<begin>	Users(9)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en <begin>, el inicio del espacio de claves de la base de datos, y finaliza en la fila anterior a la fila Users con UserId=9. Por lo tanto, la división tiene todas las filas de la tabla que preceden a Users y todas las filas de la tabla Users que preceden a UserId=9, además de las filas de sus tablas intercaladas.
Messages(3,"a",1)	Threads(10)	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en Messages(3,"a", 1) intercalada en Users(3) y termina en la fila anterior a Threads(10). Threads(10) es una clave de división truncada que es un prefijo de cualquier clave de la tabla Threads intercalada en Users(10).
Users()	<end>	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en la clave de división truncada de Users(), que precede a cualquier clave completa de la tabla Users. La división se extiende hasta el final del posible espacio de claves en la base de datos. Por lo tanto, affected_tables abarca la tabla Users, sus tablas y índices intercalados, y todas las tablas que puedan aparecer después de los usuarios.
Threads(10)	UsersByFirstName("abc")	UsersByFirstName, Users, Threads, Messages, MessagesIdx	La división comienza en la fila Threads con UserId = 10 y termina en el índice, UsersByFirstName, en la clave que precede a "abc".

Nota: SPLIT_LIMIT es mayor que SPLIT_START. Sin embargo, es posible que las comparaciones léxicas del inicio y el límite de la división no funcionen en todas las divisiones.

Consultas de ejemplo para encontrar divisiones populares

En el siguiente ejemplo, se muestra una instrucción de SQL que puedes usar para recuperar las estadísticas de división en caliente. Puedes ejecutar estas instrucciones de SQL con las bibliotecas cliente, gcloud o la consola de Google Cloud .

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables,
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end =
  (SELECT MAX(interval_end)
  FROM    SPANNER_SYS.SPLIT_STATS_TOP_MINUTE)
ORDER BY  t.cpu_usage_score DESC;

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end = (
  SELECT MAX(interval_end)
  FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE
)
ORDER BY t.cpu_usage_score DESC;

El resultado de la consulta se ve de la siguiente manera:

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(13)	Users(76)	82	Messages,Users,Threads
Users(101)	Users(102)	90	Messages,Users,Threads
Threads(10, "a")	Threads(10, "aa")	100	Messages,Threads
Messages(631, "abc", 1)	Messages(631, "abc", 3)	100	Messages
Threads(12, "zebra")	Users(14)	76	Messages,Users,Threads
Users(620)	<end>	100	Messages,Users,Threads

Retención de datos para las estadísticas de división en caliente

Como mínimo, Spanner conserva los datos para cada tabla durante el siguiente período:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Intervalos que abarcan las 6 horas anteriores.

Nota: No puedes evitar que Spanner recopile las estadísticas de división en caliente. Para borrar los datos de estas tablas, debes borrar la base de datos asociada con las tablas o esperar hasta que Spanner quite los datos de manera automática. El período de retención de estas tablas es fijo. Si deseas conservar las estadísticas durante períodos más largos, te recomendamos que copies los datos de estas tablas de forma periódica.

Cómo solucionar problemas de hotspots con estadísticas de división activa

En esta sección, se describe cómo detectar hotspots y solucionar problemas relacionados.

Selecciona un período para investigar

Verifica las métricas de latencia de tu base de datos de Spanner para encontrar el período en el que tu aplicación experimentó una latencia alta y un uso alto de CPU. Por ejemplo, es posible que se muestre que un problema comenzó alrededor de las 10:50 p.m. del 18 de mayo de 2024.

Cómo encontrar hotspots persistentes

Como Spanner equilibra tu carga con la división basada en la carga, te recomendamos que investigues si el hotspotting continuó durante más de 10 minutos. Para ello, consulta la tabla SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, como se muestra en el siguiente ejemplo:

GoogleSQL

SELECT Count(DISTINCT t.interval_end)
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

PostgreSQL

SELECT COUNT(DISTINCT t.interval_end)
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

Si el resultado de la consulta anterior es igual a 10, significa que tu base de datos está experimentando un hotspot que podría necesitar más depuración.

Busca las divisiones con el nivel de CPU_USAGE_SCORE más alto

En este ejemplo, ejecutamos la siguiente sentencia SQL para encontrar los rangos de filas con el nivel de CPU_USAGE_SCORE más alto:

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score >= 50
  AND  t.interval_end = "interval_end_date_time";

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score = 100
  AND  t.interval_end = 'interval_end_date_time'::timestamptz;

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

La sentencia SQL anterior muestra lo siguiente:

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(180)	<end>	85	Messages,Users,Threads
Users(24)	Users(76)	76	Messages,Users,Threads

En esta tabla de resultados, podemos ver que los hotspots se produjeron en dos divisiones. La división basada en la carga de Spanner podría intentar resolver los hotspots en estas divisiones. Sin embargo, es posible que no pueda hacerlo si hay patrones problemáticos en el esquema o la carga de trabajo. Para detectar si hay divisiones que necesitan tu intervención, te recomendamos hacer un seguimiento de las divisiones durante al menos 10 minutos. Por ejemplo, la siguiente SQL realiza un seguimiento de la primera división en los últimos diez minutos.

GoogleSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = "users(180)"
  AND  t.split_limit = "<end>"
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = 'users(180)'
  AND  t.split_limit = ''
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

La sentencia SQL anterior muestra lo siguiente:

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-18T17:46:00Z	Users(180)	<end>	85
2024-05-18T17:47:00Z	Users(180)	<end>	85
2024-05-18T17:48:00Z	Users(180)	<end>	85
2024-05-18T17:49:00Z	Users(180)	<end>	85
2024-05-18T17:50:00Z	Users(180)	<end>	85

Parece que la división estuvo caliente durante los últimos minutos. Puedes observar la división durante más tiempo para determinar que la división basada en la carga de Spanner mitiga el hotspot. Puede haber casos en los que Spanner no pueda realizar más balanceo de cargas.

Por ejemplo, consulta la tabla SPANNER_SYS.SPLIT_STATS_TOP_MINUTE. Consulta las siguientes situaciones de ejemplo.

GoogleSQL

SELECT t.interval_end,
      t.split_start,
      t.split_limit,
      t.cpu_usage_score
FROM  SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end >= "interval_end_date_time"
      AND t.interval_end <= "interval_end_date_time";

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t._cpu_usage
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Reemplaza interval_end_date_time por la fecha y hora del intervalo con el formato 2024-05-18T17:40:00Z.

Fila activa única

En el siguiente ejemplo, parece que Threads(10,"spanner") está en una división de fila única que permaneció activa durante más de 10 minutos. Esto puede suceder cuando hay una carga persistente en una fila popular.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:41:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:42:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:43:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:44:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:45:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:46:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:47:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:48:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:49:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100
2024-05-16T20:50:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100

Spanner no puede equilibrar la carga de esta clave única, ya que no se puede dividir más.

Hotspot móvil

En el siguiente ejemplo, la carga se mueve a través de divisiones contiguas a lo largo del tiempo y pasa a una nueva división en intervalos de tiempo.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1,"a")	Threads(1,"aa")	100
2024-05-16T20:41:00Z	Threads(1,"aa")	Threads(1,"ab")	100
2024-05-16T20:42:00Z	Threads(1,"ab")	Threads(1,"c")	100
2024-05-16T20:43:00Z	Threads(1,"c")	Threads(1,"ca")	100

Esto podría ocurrir, por ejemplo, debido a una carga de trabajo que lee o escribe claves en orden monótonamente creciente. Spanner no puede equilibrar la carga para mitigar los efectos de este comportamiento de la aplicación.

Balanceo de cargas normal

Spanner intenta equilibrar la carga agregando más divisiones o moviéndolas. En el siguiente ejemplo, se muestra cómo podría verse.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1000,"zebra")	<end>	82
2024-05-16T20:41:00Z	Threads(1000,"zebra")	<end>	90
2024-05-16T20:42:00Z	Threads(1000,"zebra")	<end>	100
2024-05-16T20:43:00Z	Threads(1000,"zebra")	Threads(2000,"spanner")	100
2024-05-16T20:44:00Z	Threads(1200,"c")	Threads(2000)	92
2024-05-16T20:45:00Z	Threads(1500,"c")	Threads(1700,"zach")	76
2024-05-16T20:46:00Z	Threads(1700)	Threads(1700,"c")	76
2024-05-16T20:47:00Z	Threads(1700)	Threads(1700,"c")	50
2024-05-16T20:48:00Z	Threads(1700)	Threads(1700,"c")	39

Aquí, la división más grande del 16/05/2024 a las 17:40:00 Z se dividió en una más pequeña y, como resultado, disminuyó la estadística CPU_USAGE_SCORE. Es posible que Spanner no cree divisiones en filas individuales. Las divisiones reflejan la carga de trabajo que causa la estadística CPU_USAGE_SCORE alta.

Si observaste una división caliente persistente durante más de 10 minutos, consulta Prácticas recomendadas para mitigar los hotspots.

Prácticas recomendadas para mitigar los hotspots

Nota: Si tu carga aumentó y recientemente aumentaste la escala de tu instancia, Spanner puede tardar unos minutos en realizar sus operaciones de balanceo de cargas antes de que disminuya la latencia.

Si el balanceo de cargas no disminuye la latencia, el siguiente paso es identificar la causa de los hotspots. Después de eso, las opciones son reducir la carga de trabajo de los hotspots o optimizar el esquema y la lógica de la aplicación para evitarlos.

Identifica la causa

• Usa las estadísticas de bloqueo y transacciones para buscar transacciones que tengan un tiempo de espera de bloqueo alto en el que la clave de inicio del rango de filas esté dentro de la división activa.

• Usa las estadísticas de consultas para buscar consultas que lean de la tabla que contiene la división activa y que hayan aumentado recientemente la latencia o tengan una proporción más alta de latencia a la CPU.

• Usa las consultas activas más antiguas para buscar consultas que lean de la tabla que contiene la división activa y que tengan una latencia más alta de lo esperado.

Estos son algunos casos especiales que debes tener en cuenta:

• Verifica si el tiempo de actividad (TTL) se habilitó recientemente. Si hay muchas divisiones de datos antiguos, el TTL puede aumentar los niveles de CPU_USAGE_SCORE durante las eliminaciones masivas. En este caso, el problema debería resolverse automáticamente una vez que se completen las eliminaciones iniciales.

Optimiza la carga de trabajo

• Sigue las prácticas recomendadas de SQL. Considera las lecturas inactivas, las operaciones de escritura que no realizan lecturas primero o la adición de índices.
• Sigue las prácticas recomendadas de Schema. Asegúrate de que tu esquema esté diseñado para controlar el balanceo de cargas y evitar los hotspots.

¿Qué sigue?

• Obtén información sobre las prácticas recomendadas para el diseño de esquemas.
• Obtén información sobre Key Visualizer.
• Consulta los ejemplos de diseños de esquema.
• Aprende a usar el panel de estadísticas de divisiones para detectar hotspots14