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 divisions avec GoogleSQL et PostgreSQL.

Spanner stocke vos données sous la forme d'un espace de clés contigu, ordonné par les clés primaires de vos tables et index. Une division est une plage de lignes d'un ensemble de tables ou d'un index. Le début de la division est appelé split start (début de la division). La limite de fractionnement définit la fin du fractionnement. La division inclut le début de la division, mais pas la limite de division.

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

La statistique de point d'accès d'une division (identifiée dans le système sous le nom 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 d'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, le fractionnement est considéré comme chaud.

Spanner utilise la répartition basée sur la charge pour répartir uniformément la charge de données sur les serveurs de l'instance. Les divisions chaudes et chaudes peuvent être déplacées entre les serveurs pour l'équilibrage de la charge ou peuvent être divisées en divisions plus petites. Toutefois, Spanner peut ne pas être en mesure d'équilibrer la charge, même après plusieurs tentatives de fractionnement, en raison d'anti-modèles dans l'application. Par conséquent, les points d'accès persistants qui durent au moins 10 minutes peuvent nécessiter un dépannage supplémentaire et des modifications d'application potentielles.

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

Disponibilité des statistiques de fractionnement en temps réel

Spanner fournit les statistiques de division chaude dans le schéma SPANNER_SYS. Les données SPANNER_SYS ne sont disponibles que via les interfaces Google SQL 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
• L'API executeQuery

Les API de lecture unique Spanner ne sont pas compatibles avec SPANNER_SYS.

Statistiques sur les divisions populaires

Vous pouvez utiliser le tableau suivant pour suivre les divisions chaudes:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: affiche les fractionnements 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 à la minute.

• 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: 11:58:00-11:58:59

• Spanner regroupe les statistiques par divisions.

• Chaque ligne contient un pourcentage qui indique l'état chaud ou tiède d'une division, pour chaque division pour laquelle Spanner enregistre des statistiques pendant l'intervalle spécifié.

• Si moins de 50% de la charge d'une division est limitée par les ressources disponibles, Spanner ne capture pas la statistique. Si Spanner ne parvient pas à stocker toutes les divisions chaudes pendant l'intervalle, le système donne la priorité aux divisions ayant le pourcentage CPU_USAGE_SCORE le plus élevé pendant l'intervalle spécifié. Si aucune division n'est renvoyée, cela signifie qu'il n'y a pas de points chauds.

Schéma de la table

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

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Nom de la colonne	Type	Description
INTERVAL_END	TIMESTAMP	Fin de l'intervalle de temps pendant lequel la division était active
SPLIT_START	STRING	Clé de début de la plage de lignes dans la division. Le début de la division peut également être <begin>, ce qui indique le début de l'espace de clés.
SPLIT_LIMIT	STRING	Clé de limite pour la plage de lignes dans la division. La clé limit: peut également être <end>, ce qui indique la fin de l'espace de clés.|
CPU_USAGE_SCORE	INT64	Pourcentage CPU_USAGE_SCORE des répartitions. Un pourcentage de CPU_USAGE_SCORE de 50% indique la présence de divisions chaudes ou actives.
AFFECTED_TABLES	STRING ARRAY	Tables dont les lignes peuvent être dans la division

Remarque :Les répartitions avec des pourcentages CPU_USAGE_SCORE inférieurs à 100 % peuvent être utilisées pour suivre les tendances au fil du temps. Spanner utilise la répartition basée sur la charge pour équilibrer la charge entre les serveurs. Vous pouvez donc constater que les divisions changent ou diminuent au fil du temps. Toutefois, Spanner ne pourra peut-être pas équilibrer la charge en raison de modèles problématiques dans l'application, et des divisions actives peuvent persister après plusieurs itérations de la division basée sur la charge de Spanner. Par conséquent, la présence de splits chauds pendant plus de 10 minutes indique que vous devrez peut-être examiner plus en détail.

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, et est définie par ses clés start (début) et limit (limite). Une division peut être une seule ligne, une plage de lignes étroite ou une plage de lignes large, et peut inclure plusieurs tables ou index.

Les colonnes SPLIT_START et SPLIT_LIMIT identifient les clés primaires d'une division à chaud ou à chaud.

Exemple de schéma

Le schéma suivant est un exemple de tableau pour les sujets de cette page.

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

Imaginons que votre espace de clés se présente comme suit:

PRIMARY KEY
<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>

Exemples de fractionnements

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

SPLIT_START et SPLIT_LIMIT peuvent indiquer la ligne d'une table ou d'un indice, ou <begin> et <end>, qui représentent les limites de l'espace de clés de la base de données. Les 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 la table. Par exemple, Threads(10) est un préfixe pour toute ligne Threads entrelacée dans Users(10).

SPLIT_START	SPLIT_LIMIT	AFFECTED_TABLES	EXPLICATION
Users(3)	Users(10)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à la ligne avec UserId=3 et se termine à la ligne précédant celle avec UserId = 10. La division contient les lignes de la table Users et toutes les lignes de ses tables entrelacées pour UserId=3 à 10.
Messages(3,"a",1)	Threads(3,"aa")	Threads, Messages, MessagesIdx	La division commence à la ligne avec UserId=3, ThreadId="a" et MessageId=1, et se termine à la ligne précédant celle avec la clé UserId=3 et ThreadsId = "aa". La répartition contient toutes les tables entre Messages(3,"a",1) et Threads(3,"aa"). Comme split_start et split_limit sont entrelacés dans la même ligne de table de niveau supérieur, la division contient les lignes de table entrelacées entre le début et la limite. Consultez schemas-overview pour comprendre comment les tables entrelacées sont colocalisées.
Messages(3,"a",1)	<end>	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence dans la table des messages à la ligne avec la clé UserId=3, ThreadId="a" et MessageId=1. La division héberge toutes les lignes de split_start à <end>, soit la fin de l'espace de clés de la base de données. Toutes les lignes des tables qui suivent split_start, comme Users(4), sont incluses dans la division.
<begin>	Users(9)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à <begin>, au début de l'espace de clés de la base de données, et se termine à la ligne précédant la ligne Users avec UserId=9. La division comprend donc toutes les lignes de la table précédant Users, ainsi que toutes les lignes de la table Users précédant UserId=9 et les lignes de ses tables entrelacées.
Messages(3,"a",1)	Threads(10)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à Messages(3,"a", 1) entrelacé dans Users(3) et se termine à la ligne précédant Threads(10). Threads(10) est une clé de fractionnement tronquée qui est un préfixe de n'importe quelle clé du tableau "Threads" entrelacée dans Users(10).
Users()	<end>	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à la clé de division tronquée Users(), qui précède toute clé complète de la table Users. La division s'étend jusqu'à la fin de l'espace de clés possible dans la base de données. Les tables affected_tables couvrent donc la table Users, ses tables et index entrelacés, ainsi que toutes les tables susceptibles d'apparaître après les utilisateurs.
Threads(10)	UsersByFirstName("abc")	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à la ligne Threads avec UserId = 10 et se termine à l'index UsersByFirstName à la clé précédant "abc".

Remarque :SPLIT_LIMIT est supérieur à SPLIT_START. Toutefois, les comparaisons lexicographiques du début et de la limite de fractionnement peuvent ne pas fonctionner entre les fractionnements.

Exemples de requêtes pour trouver des divisions 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.

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;

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

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

Conservation des données pour les statistiques de répartition en chaud

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

Remarque :Vous ne pouvez pas empêcher Spanner de collecter les statistiques de fractionnement chaud. Pour supprimer les données de ces tables, vous devez supprimer la base de données associée ou attendre que Spanner supprime les données de manière automatique. La durée de conservation de ces tables est fixe. Si vous souhaitez conserver les statistiques sur de plus longues durées, nous vous recommandons de copier régulièrement les données de ces tables.

Résoudre les problèmes liés aux 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 chauds.

Sélectionner la période à examiner

Vérifiez les métriques de latence de votre base de données Spanner pour identifier la période pendant laquelle votre application a enregistré 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.

Détecter le hotspotting persistant

Comme Spanner équilibre votre charge à l'aide de la répartition basée sur la charge, nous vous recommandons de vérifier si le hotspotting a continué pendant plus de 10 minutes. Pour ce faire, interrogez la table SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, comme illustré dans l'exemple suivant:

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

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 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;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

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 point chaud qui peut nécessiter un débogage supplémentaire.

Rechercher les divisions avec le niveau CPU_USAGE_SCORE le plus élevé

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

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

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 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;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

L'instruction SQL précédente génère les résultats suivants:

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

Ce tableau de résultats indique 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 se peut qu'il ne puisse pas le faire s'il existe des schémas problématiques dans le schéma ou la charge de travail. Pour détecter si des fractionnements nécessitent votre intervention, nous vous recommandons de les suivre pendant au moins 10 minutes. Par exemple, la requête SQL suivante suit la première division au cours des dix dernières minutes.

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

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 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;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

L'instruction SQL précédente génère les résultats suivants:

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

La scission semble avoir été chaude ces dernières minutes. Vous pouvez observer la division plus longtemps pour déterminer que la division 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.

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

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 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;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

Ligne chaude unique

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

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 ne peut pas équilibrer la charge pour cette seule clé, car elle ne peut pas être divisée davantage.

Point d'accès mobile

Dans l'exemple suivant, la charge passe par des divisions contiguës au fil du temps, et passe à une nouvelle division à des intervalles de temps.

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

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

Équilibrage de charge normal

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

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

Ici, la division la plus importante du 16/05/2024 17:40:00Z a été divisée en une division plus petite. Par conséquent, la statistique CPU_USAGE_SCORE a diminué. Spanner peut ne pas créer de divisions en lignes individuelles. Les fractionnements reflètent la charge de travail à l'origine de la statistique CPU_USAGE_SCORE élevée.

Si vous avez observé une division chaude persistante pendant plus de 10 minutes, consultez les bonnes pratiques pour atténuer les hotspots.

Bonnes pratiques pour atténuer les points chauds

Remarque :Si votre charge a augmenté et que vous avez récemment mis à l'échelle votre instance, Spanner peut mettre quelques minutes à effectuer ses opérations d'équilibrage de charge avant que votre latence ne diminue.

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 de point chaud ou optimiser le schéma et la logique de l'application pour éviter les points chauds.

Identifier la cause

• Utilisez les insights sur les verrouillages et les transactions pour rechercher les transactions dont le temps d'attente de verrouillage est élevé, où la clé de début de la plage de lignes se trouve dans la division active.

• Utilisez les insights sur les requêtes pour rechercher les requêtes qui lisent à partir de la table contenant la division chaude et qui ont récemment augmenté la latence ou un ratio de latence par rapport au processeur plus élevé.

• Utilisez Requêtes actives les plus anciennes pour rechercher les requêtes qui lisent à partir du tableau contenant la division chaude et qui ont une latence supérieure à celle attendue.

Voici quelques cas particuliers à prendre en compte:

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

Optimiser la charge de travail

• Suivez les bonnes pratiques SQL. Envisagez des lectures obsolètes, des é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.

Étape suivante

• Découvrez les bonnes pratiques de conception de schémas.
• Découvrez Key Visualizer.
• Consultez des exemples de conception de schémas.
• Découvrez comment utiliser le tableau de bord "Insights sur les segments" pour détecter les points chauds.