Dividir estatísticas

Nesta página, descrevemos como detectar e depurar hotspots no seu banco de dados. É possível acessar estatísticas sobre hotspots em divisões com GoogleSQL e PostgreSQL.

O Spanner armazena seus dados como um espaço de chaves contíguo, ordenado pelas chaves primárias das tabelas e índices. Uma divisão é um intervalo de linhas de um conjunto de tabelas ou um índice. O início da divisão é chamado de início da divisão. O limite de divisão define o fim da divisão. A divisão inclui o início, mas não o limite.

No Spanner, pontos de acesso são situações em que muitas solicitações são enviadas para o mesmo servidor, o que satura os recursos dele e pode causar latências altas. As divisões afetadas por pontos de acesso são conhecidas como divisões ativas ou quentes.

A estatística de hotspot de uma divisão (identificada no sistema como CPU_USAGE_SCORE) é uma medição da carga em uma divisão que é limitada pelos recursos disponíveis no servidor. Essa medição é fornecida como uma porcentagem. Se mais de 50% da carga em uma divisão for limitada pelos recursos disponíveis, ela será considerada ativa. Se 100% da carga em uma divisão for restrita, ela será considerada ativa.

O Spanner usa a divisão baseada em carga para distribuir uniformemente a carga de dados entre os servidores da instância. As divisões quentes e mornas podem ser movidas entre servidores para balanceamento de carga ou divididas em partes menores. No entanto, o Spanner pode não conseguir balancear a carga, mesmo depois de várias tentativas de divisão, devido a antipatterns no aplicativo. Portanto, hotspots persistentes que duram pelo menos 10 minutos podem precisar de mais solução de problemas e possíveis mudanças no aplicativo.

As estatísticas de divisão ativa do Spanner ajudam a identificar as divisões em que ocorrem pontos de acesso. Depois, faça as mudanças necessárias no aplicativo ou esquema. É possível recuperar essas estatísticas das tabelas do sistema SPANNER_SYS.SPLIT_STATS_TOP_MINUTE usando instruções SQL.

Acessar estatísticas de divisão frequente

O Spanner fornece as estatísticas de divisão ativa no esquema SPANNER_SYS. Os dados do SPANNER_SYS estão disponíveis somente por meio das interfaces do GoogleSQL e do PostgreSQL. Você pode acessar esses dados das seguintes maneiras:

• A página do Spanner Studio de um banco de dados no console Google Cloud .
• O comando gcloud spanner databases execute-sql.
• O método executeSql ou executeStreamingSql.

Os seguintes métodos de leitura única fornecidos pelo Spanner não são compatíveis com SPANNER_SYS:

• realizar uma leitura forte de uma única linha ou de várias linhas em uma tabela;
• realizar uma leitura desatualizada de uma única linha ou várias linhas em uma tabela;
• ler uma única linha ou várias linhas em um índice secundário.

Estatísticas de divisões ativas

Use a tabela a seguir para rastrear divisões ativas:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: mostra divisões que estão ativas durante intervalos de um minuto.

Essas tabelas têm as seguintes propriedades:

• Cada uma contém dados para intervalos de tempo não sobrepostos da duração que o nome da tabela especifica.

• Os intervalos são baseados em horários:

  • Os intervalos de um minuto terminam no minuto.

• Após cada intervalo, o Spanner coleta dados de todos os servidores e disponibiliza os dados nas tabelas SPANNER_SYS pouco tempo depois.

  Por exemplo, às 11:59:30, os intervalos mais recentes disponíveis para as consultas SQL são:

  • 1 minuto: das 11h58min00s às 11h58min59s

• O Spanner agrupa as estatísticas por divisões.

• Cada linha contém uma porcentagem que indica o nível de atividade de uma divisão, para cada divisão em que o Spanner captura estatísticas durante o intervalo especificado.

• Se menos de 50% da carga em uma divisão for limitada pelos recursos disponíveis, o Spanner não vai capturar a estatística. Se o Spanner não puder armazenar todas as divisões ativas durante o intervalo, o sistema vai priorizar as divisões com a maior porcentagem de CPU_USAGE_SCORE durante o intervalo especificado. Se não houver divisões retornadas, isso indica a ausência de pontos de acesso.

Esquema de tabela

A tabela a seguir mostra o esquema para estas estatísticas:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Chaves de início e limite de divisão

Uma divisão é um intervalo de linhas contíguas de um banco de dados, definido pelas chaves de início e limite. Uma divisão pode ser uma única linha, um intervalo de linhas estreito ou amplo, e pode incluir várias tabelas ou índices.

As colunas SPLIT_START e SPLIT_LIMIT identificam as chaves primárias de uma divisão quente ou fria.

Esquema de exemplo

O esquema a seguir é uma tabela de exemplo para os tópicos desta página.

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;

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);

Imagine que seu espaço de chaves seja assim:

Exemplo de divisões

Confira a seguir alguns exemplos de divisões para ajudar você a entender como elas são.

Os valores SPLIT_START e SPLIT_LIMIT podem indicar a linha de uma tabela ou índice, ou podem ser <begin> e <end>, representando os limites do espaço de chaves do banco de dados. Os SPLIT_START e SPLIT_LIMIT também podem conter chaves truncadas, que são chaves que precedem qualquer chave completa na tabela. Por exemplo, Threads(10) é um prefixo para qualquer linha Threads intercalada em Users(10).

Exemplos de consultas para encontrar divisões importantes

O exemplo a seguir mostra uma instrução SQL que pode ser usada para recuperar as estatísticas de divisão dinâmica. É possível executar essas instruções SQL usando as bibliotecas de cliente, a gcloud ou o console Google Cloud .

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;

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;

A saída da consulta é semelhante a esta:

Retenção de dados para as estatísticas de divisão frequente

O Spanner mantém dados para cada tabela, no mínimo, pelos períodos a seguir:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: intervalos que abrangem as seis horas anteriores.

Resolver problemas de pontos de acesso usando estatísticas de divisão ativa

Esta seção descreve como detectar e solucionar problemas de hotspots.

Selecionar um período para investigar

Verifique as métricas de latência do banco de dados do Spanner para encontrar o período em que o aplicativo apresentou alta latência e uso da CPU. Por exemplo, ele pode mostrar que um problema começou por volta das 22h50 de 18 de maio de 2024.

Encontrar pontos de acesso persistentes

Como o Spanner equilibra sua carga com a divisão baseada em carga, recomendamos que você investigue se o hotspotting continua por mais de 10 minutos. Para isso, consulte a tabela SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, conforme mostrado no exemplo a seguir:

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

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

Se o resultado da consulta anterior for igual a 10, isso significa que seu banco de dados está passando por hotspotting, o que pode exigir mais depuração.

Encontre as divisões com o maior nível de CPU_USAGE_SCORE

Neste exemplo, executamos o seguinte SQL para encontrar os intervalos de linhas com o nível mais alto de CPU_USAGE_SCORE:

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";

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;

O SQL anterior gera o seguinte:

Nessa tabela de resultados, podemos ver que os pontos de concentração ocorreram em duas divisões. A divisão baseada em carga do Spanner pode tentar resolver pontos de acesso nessas divisões. No entanto, isso não será possível se houver padrões problemáticos no esquema ou na carga de trabalho. Para detectar se há divisões que precisam da sua intervenção, recomendamos acompanhar as divisões por pelo menos 10 minutos. Por exemplo, o SQL a seguir rastreia a primeira divisão nos últimos 10 minutos.

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";

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;

O SQL anterior gera o seguinte:

A divisão parece ter sido disputada nos últimos minutos. Você pode observar a divisão por mais tempo para determinar que a divisão baseada em carga do Spanner reduz o hotspot. Em alguns casos, o Spanner não consegue fazer mais balanceamento de carga.

Por exemplo, consulte a tabela SPANNER_SYS.SPLIT_STATS_TOP_MINUTE. Confira os exemplos de cenários a seguir.

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";

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;

Linha quente única

No exemplo a seguir, parece que Threads(10,"spanner") está em uma divisão de linha única que permaneceu ativa por mais de 10 minutos. Isso pode acontecer quando há uma carga persistente em uma linha popular.

O Spanner não pode balancear a carga dessa chave única porque ela não pode ser dividida mais.

Ponto de acesso móvel

No exemplo a seguir, a carga se move por divisões contíguas ao longo do tempo, passando para uma nova divisão em intervalos de tempo.

Isso pode ocorrer, por exemplo, devido a uma carga de trabalho que lê ou grava chaves em ordem monotonicamente crescente. O Spanner não consegue balancear a carga para reduzir os efeitos desse comportamento do aplicativo.

Balanceamento de carga normal

O Spanner tenta equilibrar a carga adicionando mais divisões ou movendo-as. O exemplo a seguir mostra como isso pode ser feito.

Aqui, a divisão maior em 16/05/2024 às 17h40 (UTC) foi dividida ainda mais em uma divisão menor e, como resultado, a estatística CPU_USAGE_SCORE diminuiu. O Spanner pode não criar divisões em linhas individuais. As divisões refletem a carga de trabalho que causa a estatística CPU_USAGE_SCORE alta.

Se você observar uma divisão quente persistente por mais de 10 minutos, consulte Práticas recomendadas para reduzir pontos de acesso.

Práticas recomendadas para reduzir pontos de acesso

Se o balanceamento de carga não diminuir a latência, a próxima etapa será identificar a causa dos hotspots. Depois disso, as opções são reduzir a carga de trabalho de hotspotting ou otimizar o esquema e a lógica do aplicativo para evitar hotspots.

Identificar a causa

• Use os insights de bloqueio e transação para procurar transações com alto tempo de espera de bloqueio em que a chave inicial do intervalo de linhas está dentro da divisão ativa.

• Use os Insights de consulta para procurar consultas que leem da tabela que contém a divisão ativa e que aumentaram a latência recentemente ou têm uma proporção maior de latência para CPU.

• Use Consultas ativas mais antigas para procurar consultas que leem da tabela que contém a divisão dinâmica e que têm latência maior do que o esperado.

Alguns casos especiais a serem observados:

• Verifique se o tempo de vida útil (TTL) foi ativado recentemente. Se houver muitas divisões de dados antigos, o TTL poderá aumentar os níveis de CPU_USAGE_SCORE durante exclusões em massa. Nesse caso, o problema será resolvido automaticamente quando as exclusões iniciais forem concluídas.

Otimizar a carga de trabalho

• Siga as práticas recomendadas de SQL. Considere leituras desatualizadas, gravações que não realizam leituras primeiro ou a adição de índices.
• Siga as práticas recomendadas de esquema. Verifique se o esquema foi projetado para processar o balanceamento de carga e evitar pontos de acesso.

A seguir

• Saiba mais sobre as práticas recomendadas de design de esquema.
• Saiba mais sobre o Key Visualizer.
• Confira exemplos de designs de esquemas.
• Saiba como usar o painel de insights de divisão para detectar pontos de acesso.