Heatmap patterns

This page shows examples of patterns that you might see in the heatmap for a Key Visualizer scan, then explains the meaning of each pattern. Use this information to help you diagnose performance issues with Bigtable.

Before you read this page, you should be familiar with the overview of Key Visualizer.

Overview of common patterns

This page explains how to interpret the following Key Visualizer patterns.

Evenly distributed reads and writes

Heatmap showing evenly distributed reads and writes

If a heatmap shows a fine-grained mix of dark and bright colors, then reads and writes are evenly distributed throughout the table. This heatmap represents an effective usage pattern for Bigtable, so you do not need to take any action.

Periodic usage

Heatmap showing a periodic usage pattern

If a heatmap shows alternating bands of dark and bright colors within a key range, then you are accessing that key range during certain periods but not others. For example, you might be running a batch job that accesses the key range at specific times of day.

This usage pattern is not a problem as long as it does not result in excessive CPU utilization or latency, and as long as you intended to access your data in this way. If this pattern results in excessive CPU usage, you might need to add nodes to your cluster during peak usage periods. If you did not intend to access your data much more heavily during specific periods of time, examine your applications to find out which ones are not behaving correctly.

Hot key ranges

Heatmap showing hot key ranges

If a heatmap shows horizontal bands of bright color, separated by dark colors, then the brightly colored key ranges have one of the following issues:

  • 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.
  • 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.
  • If you are viewing another metric, it's likely that you are accessing rows in that key range much more heavily than other rows.

Take at least one of the following actions to address the issue:

  • Use filters to reduce the amount of data that you read.
  • Change your 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.
  • Update your application to cache the results of reads from Bigtable.
  • Update your application to batch and deduplicate writes to Bigtable.

Sudden increases

Heatmap showing a sudden increase

If a heatmap shows a key range that suddenly changes from dark to bright, then one of the following changes occurred:

  • If you are viewing the Large rows metric, you added a large amount of data to rows in that key range during a short period of time.

    Delete data from the large rows, or change your schema design so that less data is stored in those rows.

  • If you are viewing another metric, it's likely that you started to access those rows much more heavily than usual at a specific point in time.

    This usage pattern is not a problem as long as it does not result in excessive CPU utilization or latency, and as long as you intended to access your data in this way. If this pattern results in excessive CPU usage, you might need to add nodes to your cluster during peak usage periods. If you did not intend to start accessing your data much more heavily at a specific point in time, examine your applications to find out which ones are not behaving correctly.

Sequential reads and writes

Heatmap showing sequential reads and writes within a key range

If a heatmap shows a bright diagonal line, then you are accessing contiguous key ranges within a table in sequential order. For example, you might have run a batch job that iterates over the table's row keys.

This usage pattern is not a problem as long as it does not result in excessive CPU utilization or latency, and as long as you intended to access your data in this way. If this pattern results in excessive CPU usage, you might need to add nodes to your cluster during peak usage periods. If you did not intend to access rows within your table in sequential order, examine your applications to find out which ones are not behaving correctly.

What's next