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 índices y tablas. 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 de división.

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 da como porcentaje. Si más del 50% de la carga en una división está restringida por recursos disponibles, la división se considera templada. 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 tibias y calientes 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 la solución de problemas y los 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 desde Tablas del sistema SPANNER_SYS.SPLIT_STATS_TOP_MINUTE con instrucciones de SQL.

Disponibilidad de 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. Tú puedes usar las siguientes formas para acceder a estos datos:

• La 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 sobre las divisiones activas

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

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Muestra las divisiones que están activas. en intervalos de 1 minuto.

Estas tablas tienen las siguientes propiedades:

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

• Los intervalos se basan en la hora del 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 caliente es una división, por para cada división para la que Spanner captura estadísticas durante en un intervalo especificado.

• Si menos del 50% de la carga en una división está limitada por la política recursos, Spanner no captura las estadísticas. 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 hay no se muestran divisiones, es una indicación de la ausencia de 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. El límite: también puede ser <end>, lo que indica el final del espacio de claves|
CPU_USAGE_SCORE	INT64	El porcentaje de CPU_USAGE_SCORE de las divisiones. R El porcentaje de CPU_USAGE_SCORE del 50% indica la presencia de calor o calor. | divisiones |
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 modelos basados en y dividir la carga entre los servidores, por lo que podrías ver 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.

Divide las claves de inicio y límite de división

Una división es un rango de filas contiguo de una base de datos y se define por su valor de inicio y limit. 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 tibia o en caliente.

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 las claves truncadas, que son las que preceden a cualquier clave completa de la tabla. Por ejemplo: Threads(10) es un prefijo para cualquier fila de 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 las filas de sus 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 finaliza en la fila que precede 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 se intercalan 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 las claves UserId=3, ThreadId="a" y MessageId=1. La división aloja todas las filas desde split_start hasta <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 y 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) intercalado en Users(3) y finaliza en la fila que antecede 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 espacio de claves posible 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 sentencia 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 de cada tabla para lo siguiente: período:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: Intervalos que cubren en las últimas 6 horas.

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 a las tablas o esperar hasta Spanner quita los datos automáticamente. El período de retención de estas tablas es fijo. Si quieres conservar estadísticas durante períodos más largos de con el tiempo, te recomendamos que copies los datos de estas tablas de forma periódica.

Soluciona problemas de hotspots con estadísticas de división en caliente

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, podría mostrarte que un comenzó alrededor de las 10:50 p.m. del 18 de mayo de 2024.

Cómo encontrar hotspots persistentes

A medida que Spanner balancea la carga con la división basada en la carga, te recomendamos que investigues si la generación de hotspots 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 de la de servicio 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 de la de servicio 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á la generación de hotspots que podría necesitar más depuración.

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

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

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 de la de servicio 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 de la de servicio 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 ocurrieron 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 sentencia 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 de la de servicio 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 de la de servicio 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. Podrías observar la dividir por más tiempo para determinar que el servidor basado en cargas de Spanner dividir, 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 de la de servicio 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 de la de servicio 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 con el tiempo. se mueve 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 ser.

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 en 2024-05-16T17:40:00Z se dividió aún más en una dividida y, como resultado, la estadística CPU_USAGE_SCORE disminuyó. Es posible que Spanner no cree divisiones en filas individuales. Los splits duplicar la carga de trabajo que causa la estadística alta de CPU_USAGE_SCORE.

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 principal 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 Bloquear y Estadísticas de transacciones para buscar transacciones con un alto rendimiento tiempo de espera de bloqueo en el que la clave de inicio del rango de filas se encuentra dentro de la división en caliente.

• 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.

• Utiliza las Consultas activas más antiguas para buscar las consultas que se leen de la tabla. que contenga la división en caliente y que tengan una latencia más alta de la esperada.

Estos son algunos casos especiales a los que debes prestar atención:

• 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 por cuenta propia una vez se completen las eliminaciones iniciales.

Optimiza la carga de trabajo

• Sigue las prácticas recomendadas sobre SQL. Considera las lecturas inactivas, escrituras que no realizar lecturas primero o agregar índices.
• Sigue las prácticas recomendadas de Schema. Asegúrate de que tu esquema esté diseñado para manejar 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