Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Modèles de cartes de densité
Cette page présente des exemples de modèles que vous pourriez voir dans la carte de densité d'une analyse Key Visualizer et en explique la signification. Ces informations vous aideront à diagnostiquer les problèmes de performances avec Bigtable.
Si une carte de densité affiche un mélange finement granuleux de couleurs sombres et lumineuses, les lectures et les écritures sont réparties de manière homogène dans la table. Cette carte de densité représente un modèle d'utilisation efficace de Bigtable. Vous n'avez donc pas à intervenir.
Utilisation périodique
Si une carte de densité affiche des bandes alternées de couleurs sombres et lumineuses dans une plage de clés, cela signifie que vous accédez à cette plage à certaines périodes mais pas à d'autres. Par exemple, une tâche par lots qui accède à la plage de clés s'exécute à des heures précises de la journée.
Ce modèle d'utilisation ne pose pas de problème tant qu'il ne se traduit pas par une utilisation excessive du processeur ou une latence, et que ce mode d'accès à vos données est intentionnel.
En revanche, si vous constatez une utilisation excessive du processeur, vous devrez peut-être ajouter des nœuds à votre cluster pendant les pics d'utilisation.
Si l'accès intensif à vos données à certaines périodes spécifiques n'est pas intentionnel, examinez vos applications pour détecter celles dont le comportement est anormal.
Plages de clés en zone chaude
Si une carte de densité affiche des bandes horizontales de couleurs vives entrecoupées de couleurs sombres, les plages de clés de couleurs vives présentent l'un des problèmes suivants :
Si vous voyez les métriques d'indice de pression de lecture ou d'indice de pression d'écriture, la zone chaude de la plage de clés est probablement à l'origine d'une utilisation élevée du processeur ou d'une latence excessive. Ces problèmes peuvent se produire si vous effectuez un grand nombre de lectures ou d'écritures ou si vous stockez plus de 256 Mo sur une ligne. Soyez particulièrement vigilant si cet avertissement est déclenché par une seule ligne plutôt que par une plage de lignes.
Si vous consultez la métrique Lignes volumineuses, la plage de clés comprend des lignes contenant plus de 256 Mo de données ou une moyenne supérieure à 200 Mo par ligne.
Si vous voyez une autre métrique, vous faites un usage probablement beaucoup plus intensif des lignes de cette clé que des autres lignes.
Appliquez au moins l'une des mesures suivantes pour résoudre le problème :
Utilisez des filtres pour réduire la quantité de données en lecture.
Modifiez la conception du schéma ou votre application afin que les données sur une ligne utilisée de façon intensive ou trop volumineuse soient réparties sur plusieurs lignes.
Mettez à jour votre application pour mettre en cache les résultats des lectures de Bigtable.
Mettez à jour votre application par lot et supprimez les écritures en double dans Bigtable.
Augmentation soudaine
Si une carte de densité montre qu'une plage de clés passe soudainement d'une couleur sombre à brillante, cela signifie que l'un des événements suivants est survenu :
Si vous voyez la métrique Grandes lignes, vous avez ajouté une grande quantité de données aux lignes de cette plage de clés pendant une courte période.
Supprimez les données des grandes lignes ou modifiez la conception du schéma de manière à stocker moins de données dans ces lignes.
Si vous voyez une autre métrique, il est probable que, à un moment donné, vous avez commencé à accéder à ces lignes de façon beaucoup plus intensive que d'ordinaire.
Ce modèle d'utilisation ne pose pas de problème tant qu'il ne se traduit pas par une utilisation excessive du processeur ou une latence, et que ce mode d'accès à vos données est intentionnel.
En revanche, si vous constatez une utilisation excessive du processeur, vous devrez peut-être ajouter des nœuds à votre cluster pendant les pics d'utilisation.
Si l'accès intensif à vos données à certaines périodes spécifiques n'est pas intentionnel, examinez vos applications pour détecter celles dont le comportement est anormal.
Lectures et écritures séquentielles
Si une carte de densité affiche un tracé brillant en diagonale, cela signifie que vous accédez aux plages de clés contiguës dans une table dans un ordre séquentiel. Par exemple, vous avez peut-être exécuté une tâche par lots qui se répète sur les clés de ligne de la table.
Ce modèle d'utilisation ne pose pas de problème tant qu'il ne se traduit pas par une utilisation excessive du processeur ou une latence, et que ce mode d'accès à vos données est intentionnel.
En revanche, si vous constatez une utilisation excessive du processeur, vous devrez peut-être ajouter des nœuds à votre cluster pendant les pics d'utilisation.
Si l'accès à vos données dans un ordre séquentiel n'est pas intentionnel, examinez vos applications pour détecter celles dont le comportement est anormal.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eKey Visualizer heatmaps display patterns that can indicate performance issues with Bigtable, and this page explains how to interpret these patterns.\u003c/p\u003e\n"],["\u003cp\u003eEvenly distributed reads and writes are optimal and appear as a fine-grained mix of dark and bright colors in the heatmap, indicating no action is needed.\u003c/p\u003e\n"],["\u003cp\u003ePeriodic usage, showing as alternating bands of colors, is acceptable unless it causes high CPU usage or latency, in which case adding nodes may be necessary.\u003c/p\u003e\n"],["\u003cp\u003eHot key ranges, shown as horizontal bright bands, suggest high CPU usage, latency, or overly large rows, and resolution includes using filters, modifying schema design, caching, or batching writes.\u003c/p\u003e\n"],["\u003cp\u003eSudden increases in the heatmap indicate a sudden change to a specific key range, whether it be due to data being added or accessed, which may require adding nodes or deleting data.\u003c/p\u003e\n"]]],[],null,["Heatmap patterns\n\nThis page shows examples of patterns that you might see in the heatmap for a Key\nVisualizer scan, then explains the meaning of each pattern. Use this information\nto help you diagnose performance issues with Bigtable.\n\n- To learn how to open a Key Visualizer scan, see [Viewing the scan for a time\n period](/bigtable/docs/keyvis-getting-started#viewing-scan).\n- To find out how to explore a Key Visualizer scan in detail, see [Exploring\n Heatmaps](/bigtable/docs/keyvis-exploring-heatmaps).\n\n\nBefore you read this page, you should be familiar with the\n[overview of Key Visualizer](/bigtable/docs/keyvis-overview).\n\nOverview of common patterns\n\nThis page explains how to interpret the following Key Visualizer patterns. \n[Even distribution](#even-distribution) [Periodic usage](#periodic-usage) [Hot key ranges](#hot-key-ranges) \n\n[Sudden increases](#sudden-increases) [Sequential reads/writes](#sequential-ops)\n\nEvenly distributed reads and writes\n\nIf a heatmap shows a fine-grained mix of dark and bright colors, then reads and\nwrites are evenly distributed throughout the table. This heatmap represents an\neffective usage pattern for Bigtable, so you do not need to take\nany action. \n\nPeriodic usage\n\nIf a heatmap shows alternating bands of dark and bright colors within a key\nrange, then you are accessing that key range during certain periods but not\nothers. For example, you might be running a batch job that accesses the key\nrange at specific times of day.\n\n\nThis usage pattern is not a problem as long as it does not result in excessive CPU utilization or\nlatency, and as long as you intended to access your data in this way.\n\nIf this pattern results in excessive CPU usage, you might need to\n[add nodes to your cluster](/bigtable/docs/modifying-instance#nodes) during peak usage\nperiods.\nIf you did not intend to\naccess your data much more heavily during specific periods of time, examine your\napplications to find out which ones are not behaving correctly. \n\nHot key ranges\n\nIf a heatmap shows horizontal bands of bright color, separated by dark colors,\nthen the brightly colored key ranges have one of the following issues:\n\n- If you are viewing the **Read pressure index** or **Write pressure index** metrics, the hot key range might be causing high CPU utilization or high latency. These issues can occur if you perform a large number of reads or writes, or if you store more than 256 MB in a row. Pay special attention if this warning is triggered by a single row, rather than a range of rows.\n- If you are viewing the **Large rows** metric, the key range includes rows that contain more than 256 MB of data or an average of more than 200 MB per row.\n- If you are viewing another metric, it's likely that you are accessing rows in that key range much more heavily than other rows.\n\nTake at least one of the following actions to address the issue:\n\n- Use [filters](/bigtable/docs/filters) to reduce the amount of data that you read.\n- Change your [schema design](/bigtable/docs/schema-design) or your application so that the data in a heavily used row, or in an excessively large row, is spread across multiple rows.\n- Update your application to cache the results of reads from Bigtable.\n- Update your application to batch and deduplicate writes to Bigtable.\n\nSudden increases\n\nIf a heatmap shows a key range that suddenly changes from dark to bright, then\none of the following changes occurred:\n\n- If you are viewing the **Large rows** metric, you added a large amount of data\n to rows in that key range during a short period of time.\n\n Delete data from the large rows, or change your [schema\n design](/bigtable/docs/schema-design) so that less data is stored in those rows.\n- If you are viewing another metric, it's likely that you started to access\n those rows much more heavily than usual at a specific point in time.\n\n\n This usage pattern is not a problem as long as it does not result in excessive CPU utilization or\n latency, and as long as you intended to access your data in this way.\n\n If this pattern results in excessive CPU usage, you might need to\n [add nodes to your cluster](/bigtable/docs/modifying-instance#nodes) during peak usage\n periods.\n If you did not intend\n to start accessing your data much more heavily at a specific point in time,\n examine your applications to find out which ones are not behaving correctly.\n\nSequential reads and writes\n\nIf a heatmap shows a bright diagonal line, then you are accessing contiguous key\nranges within a table in sequential order. For example, you might have run a\nbatch job that iterates over the table's row keys.\n\n\nThis usage pattern is not a problem as long as it does not result in excessive CPU utilization or\nlatency, and as long as you intended to access your data in this way.\n\nIf this pattern results in excessive CPU usage, you might need to\n[add nodes to your cluster](/bigtable/docs/modifying-instance#nodes) during peak usage\nperiods.\nIf you did not intend to\naccess rows within your table in sequential order, examine your applications to\nfind out which ones are not behaving correctly. \n\nWhat's next\n\n- Learn how to [get started with Key Visualizer](/bigtable/docs/keyvis-getting-started).\n- Find out how to [explore a heatmap in detail](/bigtable/docs/keyvis-exploring-heatmaps).\n- Read about the [metrics you can view in a heatmap](/bigtable/docs/keyvis-metrics)."]]
