Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Padrões de mapas de calor
Nesta página, mostramos exemplos de padrões que você pode ver no mapa de calor de uma verificação do Key Visualizer e explicamos o significado de cada um deles. Use essas informações
para ajudar a diagnosticar problemas de desempenho com o Bigtable.
Se um mapa de calor mostrar uma mistura refinada de cores escuras e claras, as leituras e gravações estão distribuídas uniformemente pela tabela. Esse mapa de calor representa um
padrão de uso eficaz do Bigtable e não exige nenhuma
ação.
Uso periódico
Se um mapa de calor mostrar faixas alternadas de cores escuras e claras dentro de um intervalo de chave, você está acessando o intervalo de chaves durante determinados períodos, mas não em outros. Por exemplo, talvez você esteja executando um job em lotes que acessa o intervalo de chaves em horários específicos do dia.
Esse padrão de uso não é um problema, desde que não resulte em uso ou latência excessivos da CPU e desde que você pretenda acessar seus dados dessa maneira.
Se esse padrão resultar em utilização excessiva da CPU, talvez seja necessário adicionar nós ao cluster durante os períodos de pico de uso.
Se você não pretendia acessar seus dados com intensidade maior durante períodos específicos, analise os aplicativos para descobrir quais estão se comportando de maneira inadequada.
Intervalos de chaves com uso intenso
Se um mapa de calor mostrar faixas horizontais de cor clara, separadas por cores escuras, as faixas de cores claras terão um dos seguintes problemas:
Se você estiver visualizando as métricas de Índice de pressão de leitura ou Índice de pressão de gravação, o intervalo de chaves com uso intenso pode estar causando alto uso da CPU ou alta latência. Esses problemas podem ocorrer se você executar um grande número de leituras ou gravações ou se armazenar mais de 256 MB em uma linha. Preste bastante atenção se esse aviso for acionado por uma única linha, em vez de um intervalo de linhas.
Se você estiver visualizando a métrica Linhas grandes, o intervalo de chaves incluirá linhas que contêm mais de 256 MB de dados ou uma média de mais de 200 MB por linha.
Se estiver visualizando outra métrica, provavelmente está acessando linhas nesse intervalo de chaves com muito mais intensidade do que outras linhas.
Realize pelo menos uma das seguintes ações para resolver o problema:
Usar filtros para reduzir a quantidade de dados lidos.
Alterar o design do esquema ou seu aplicativo para que os dados em uma linha muito usada ou em uma linha excessivamente grande sejam distribuídos em várias linhas.
Atualize seu aplicativo para armazenar em cache os resultados das leituras do Bigtable.
Atualize seu aplicativo para gravar em lote e eliminar duplicações de gravações no Bigtable.
Aumentos repentinos
Se um mapa de calor mostra um intervalo de chaves que muda repentinamente de escuro para claro, uma das seguintes mudanças ocorreu:
Se estiver visualizando a métrica de Linhas grandes, você adicionou uma grande quantidade de dados às linhas nesse intervalo de chaves durante um curto período.
Exclua os dados das linhas grandes ou altere o design do esquema para que menos dados sejam armazenados nessas linhas.
Se estiver visualizando outra métrica, é provável que você tenha acessado essas linhas com muito mais intensidade que o normal em um momento específico.
Esse padrão de uso não é um problema, desde que não resulte em uso ou latência excessivos da CPU e desde que você pretenda acessar seus dados dessa maneira.
Se esse padrão resultar em utilização excessiva da CPU, talvez seja necessário adicionar nós ao cluster durante os períodos de pico de uso.
Se você não pretendia acessar seus dados com intensidade muito maior em um período específico, analise os aplicativos para descobrir quais estão se comportando de maneira inadequada.
Leituras e gravações sequenciais
Se um mapa de calor mostra uma linha diagonal clara, você está acessando intervalos de chaves contíguos dentro de uma tabela em ordem sequencial. Por exemplo, você pode ter executado um job em lote que se repete nas chaves de linha da tabela.
Esse padrão de uso não é um problema, desde que não resulte em uso ou latência excessivos da CPU e desde que você pretenda acessar seus dados dessa maneira.
Se esse padrão resultar em utilização excessiva da CPU, talvez seja necessário adicionar nós ao cluster durante os períodos de pico de uso.
Se você não pretendia acessar as linhas da sua tabela em ordem sequencial, analise os aplicativos para descobrir quais estão se comportando de maneira inadequada.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 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)."]]
