Statistiques de fractionnement

Cette page explique comment détecter et déboguer les points chauds dans votre base de données. Vous pouvez accéder aux statistiques sur les points chauds dans les fractionnements avec GoogleSQL et PostgreSQL.

Spanner stocke vos données sous forme d'espace clé contigu, trié par clé primaire de vos tables et index. Une division est une plage de lignes provenant d'un ensemble de tables ou d'un index. Le début de la division est appelé début de la division. La limite de fractionnement définit la fin du fractionnement. La fraction inclut le début de la fraction, mais pas la limite de la fraction.

Dans Spanner, les hotspots sont des situations où trop de requêtes sont envoyées au même serveur, ce qui sature les ressources du serveur et peut entraîner des latences élevées. Les divisions concernées par les hotspots sont appelées divisions actives ou tièdes.

La statistique de point chaud d'une division (identifiée dans le système par CPU_USAGE_SCORE) est une mesure de la charge sur une division limitée par les ressources disponibles sur le serveur. Cette mesure est exprimée en pourcentage. Si plus de 50 % de la charge sur une division est limitée par les ressources disponibles, la division est considérée comme chaude. Si 100 % de la charge d'un fractionnement est contrainte, il est considéré comme chaud.

Spanner utilise la répartition basée sur la charge pour répartir uniformément la charge des données sur les serveurs de l'instance. Les splits "chaud" et "très chaud" peuvent être déplacés sur différents serveurs pour équilibrer la charge ou être divisés en splits plus petits. Toutefois, il est possible que Spanner ne parvienne pas à équilibrer la charge, même après plusieurs tentatives de fractionnement, en raison d'antimotifs dans l'application. Par conséquent, les points d'accès persistants qui durent au moins 10 minutes peuvent nécessiter un dépannage plus approfondi et des modifications potentielles de l'application.

Les statistiques sur les divisions actives de Spanner vous aident à identifier les divisions où se produisent des hotspots. Vous pouvez ensuite apporter les modifications nécessaires à votre application ou à votre schéma. Vous pouvez récupérer ces statistiques à partir des tables système SPANNER_SYS.SPLIT_STATS_TOP_MINUTE à l'aide d'instructions SQL.

Accéder aux statistiques de fractionnement à chaud

Spanner fournit les statistiques de fractionnement actif dans le schéma SPANNER_SYS. Les données SPANNER_SYS ne sont disponibles que via les interfaces GoogleSQL et PostgreSQL. Vous pouvez accéder à ces données de différentes manières :

• Page Spanner Studio d'une base de données dans la console Google Cloud .
• La commande gcloud spanner databases execute-sql
• La méthode executeSql ou executeStreamingSql.

Les méthodes de lecture unique suivantes fournies par Spanner ne sont pas compatibles avec SPANNER_SYS :

• effectuer une lecture forte à partir d'une ou de plusieurs lignes d'une table ;
• effectuer une lecture non actualisée à partir d'une ou de plusieurs lignes d'une table ;
• lire à partir d'une ou de plusieurs lignes d'un index secondaire.

Statistiques sur les divisions les plus populaires

Utilisez le tableau suivant pour suivre les fractionnements actifs :

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE : affiche les fractionnements qui sont actifs pendant des intervalles d'une minute.

Ces tables ont les propriétés suivantes :

• Chaque table contient les données correspondant à des intervalles de temps sans chevauchement de la durée spécifiée par le nom de la table.

• Les intervalles sont définis selon l'heure réelle :

  • Les intervalles d'une minute se terminent toutes les minutes.

• Après chaque intervalle, Spanner collecte les données de tous les serveurs, puis les met à disposition dans les tables SPANNER_SYS peu de temps après.

  Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sont les suivants :

  • 1 minute : de 11h58:00 à 11h58:59

• Spanner regroupe les statistiques par fractionnement.

• Chaque ligne contient un pourcentage qui indique le degré de chaleur d'une division, pour chaque division pour laquelle Spanner enregistre des statistiques pendant l'intervalle spécifié.

• Si moins de 50 % de la charge sur une division est limitée par les ressources disponibles, Spanner ne capture pas la statistique. Si Spanner ne parvient pas à stocker toutes les divisions actives pendant l'intervalle, le système donne la priorité aux divisions ayant le pourcentage CPU_USAGE_SCORE le plus élevé durant l'intervalle spécifié. Si aucun fractionnement n'est renvoyé, cela indique l'absence de points chauds.

Schéma de la table

Le tableau suivant présente le schéma de table pour les statistiques suivantes :

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Clés de début et de limite de fractionnement

Une division est une plage de lignes contiguës d'une base de données. Elle est définie par ses clés de début et de limite. Une division peut être une ligne unique, une plage de lignes étroite ou une plage de lignes large, et elle peut inclure plusieurs tables ou index.

Les colonnes SPLIT_START et SPLIT_LIMIT identifient les clés primaires d'une division chaude ou tiède.

Exemple de schéma

Le schéma suivant est un exemple de tableau pour les thèmes abordés sur cette page.

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

Imaginez que votre espace de clés ressemble à ceci :

Exemple de fractionnement

Vous trouverez ci-dessous quelques exemples de fractionnement pour vous aider à comprendre à quoi ils ressemblent.

SPLIT_START et SPLIT_LIMIT peuvent indiquer la ligne d'un tableau ou d'un index, ou peuvent être <begin> et <end>, représentant les limites de l'espace de clés de la base de données. SPLIT_START et SPLIT_LIMIT peuvent également contenir des clés tronquées, qui sont des clés précédant toute clé complète dans le tableau. Par exemple, Threads(10) est un préfixe pour toute ligne Threads insérée dans Users(10).

Exemples de requêtes pour trouver les divisions les plus populaires

L'exemple suivant montre une instruction SQL que vous pouvez utiliser pour récupérer les statistiques de fractionnement à chaud. Vous pouvez exécuter ces instructions SQL à l'aide des bibliothèques clientes, de gcloud ou de la 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;

Le résultat de la requête se présente comme suit :

Conservation des données pour les statistiques de répartition des données "chaudes"

Spanner conserve les données de chaque table pendant une durée minimale variable selon le type de table :

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE : intervalles couvrant les six heures précédentes.

Résoudre les problèmes de points sensibles à l'aide des statistiques de division active

Cette section explique comment détecter et résoudre les problèmes liés aux points d'accès.

Sélectionner une période à examiner

Consultez les métriques de latence de votre base de données Spanner pour trouver la période pendant laquelle votre application a rencontré une latence et une utilisation du processeur élevées. Par exemple, il peut vous indiquer qu'un problème a commencé vers 22h50 le 18 mai 2024.

Identifier les points d'accès persistants

Étant donné que Spanner équilibre votre charge avec la répartition basée sur la charge, nous vous recommandons de vérifier si les points d'accès persistent pendant plus de 10 minutes. Pour ce faire, interrogez la table SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, comme indiqué dans l'exemple suivant :

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;

Si le résultat de la requête précédente est égal à 10, cela signifie que votre base de données présente un problème de hotspotting qui peut nécessiter un débogage plus approfondi.

Trouvez les fractionnés avec le niveau CPU_USAGE_SCORE le plus élevé.

Pour cet exemple, nous exécutons la requête SQL suivante afin de trouver les plages de lignes avec le niveau CPU_USAGE_SCORE le plus élevé :

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;

Le code SQL précédent génère les résultats suivants :

À partir de ce tableau de résultats, nous pouvons constater que des points chauds se sont produits sur deux fractionnements. La répartition basée sur la charge de Spanner peut essayer de résoudre les points chauds sur ces divisions. Toutefois, il est possible qu'il ne puisse pas le faire si le schéma ou la charge de travail contiennent des schémas problématiques. Pour détecter s'il existe des divisions qui nécessitent votre intervention, nous vous recommandons de suivre les divisions pendant au moins 10 minutes. Par exemple, la requête SQL suivante suit le premier fractionnement au cours des dix dernières minutes.

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;

Le code SQL précédent génère les résultats suivants :

Le split semble avoir été chaud ces dernières minutes. Vous pouvez observer la division plus longtemps pour déterminer que la répartition basée sur la charge de Spanner atténue le point chaud. Il peut arriver que Spanner ne puisse plus équilibrer la charge.

Par exemple, interrogez la table SPANNER_SYS.SPLIT_STATS_TOP_MINUTE. Consultez les exemples de scénarios suivants.

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;

Ligne en zone chaude unique

Dans l'exemple suivant, il semble que Threads(10,"spanner") se trouve dans une seule ligne fractionnée qui est restée active pendant plus de 10 minutes. Cela peut se produire lorsqu'une ligne populaire est soumise à une charge persistante.

Spanner ne peut pas équilibrer la charge pour cette clé unique, car elle ne peut pas être fractionnée davantage.

Point d'accès mobile

Dans l'exemple suivant, la charge se déplace dans des fractions contiguës au fil du temps, en passant à une nouvelle fraction à chaque intervalle de temps.

Cela peut se produire, par exemple, en raison d'une charge de travail qui lit ou écrit des clés dans un ordre croissant monotone. Spanner ne peut pas équilibrer la charge pour atténuer les effets de ce comportement d'application.

Équilibrage de charge normal

Spanner essaie d'équilibrer la charge en ajoutant des divisions ou en les déplaçant. L'exemple suivant montre à quoi cela peut ressembler.

Ici, la division plus importante à 2024-05-16T17:40:00Z a été divisée en une division plus petite, ce qui a entraîné une diminution de la statistique CPU_USAGE_SCORE. Il est possible que Spanner ne crée pas de fractionnement en lignes individuelles. Les fractionnements reflètent la charge de travail à l'origine de la statistique CPU_USAGE_SCORE élevée.

Si vous constatez une répartition inégale persistante pendant plus de 10 minutes, consultez Bonnes pratiques pour atténuer les hotspots.

Bonnes pratiques pour limiter les points chauds

Si l'équilibrage de charge ne réduit pas la latence, l'étape suivante consiste à identifier la cause des points chauds. Ensuite, vous pouvez réduire la charge de travail des points chauds ou optimiser le schéma et la logique de l'application pour éviter les points chauds.

Identifier la cause

• Utilisez Insights sur les verrouillages et les transactions pour rechercher les transactions dont le temps d'attente de verrouillage est élevé et dont la clé de début de plage de lignes se trouve dans la répartition active.

• Utilisez Insights sur les requêtes pour rechercher les requêtes qui lisent des données à partir de la table contenant la répartition chaude et qui ont récemment augmenté la latence ou le ratio de latence/CPU.

• Utilisez Requêtes actives les plus anciennes pour rechercher les requêtes qui lisent à partir de la table contenant la répartition populaire et qui présentent une latence plus élevée que prévu.

Voici quelques cas particuliers à surveiller :

• Vérifiez si la valeur TTL (Time To Live) a été activée récemment. Si de nombreuses divisions proviennent d'anciennes données, la valeur TTL peut augmenter les niveaux CPU_USAGE_SCORE lors des suppressions massives. Dans ce cas, le problème devrait se résoudre automatiquement une fois les suppressions initiales effectuées.

Optimiser la charge de travail

• Suivez les bonnes pratiques SQL. Envisagez les lectures obsolètes, les écritures qui n'effectuent pas de lectures en premier ou l'ajout d'index.
• Suivez les bonnes pratiques concernant les schémas. Assurez-vous que votre schéma est conçu pour gérer l'équilibrage de charge et éviter les points chauds.

Étapes suivantes

• Découvrez les bonnes pratiques de conception de schémas.
• En savoir plus sur Key Visualizer
• Consultez des exemples de conception de schémas.
• Découvrez comment utiliser le tableau de bord des insights fractionnés pour détecter les zones chaudes.