App profiles overview

An application profile, or app profile, stores settings that tell your Bigtable instance how to handle incoming requests from an application. When your application connects to a Bigtable instance, it uses either the default app profile or an app profile specified by you. Bigtable uses that app profile for requests that the application sends over that connection.

An app profile defines the routing policy that Bigtable uses and controls whether single-row transactions are allowed. An app profile also lets you specify the priority level for requests sent using the app profile.

This page explains app profiles and provides guidance on using them.

For code samples showing how to use an app profile in your application, see Connect with a custom app profile.

Use a separate app profile for each workload

When you create a Bigtable instance, a default app profile is created automatically, and its settings depend on the number of clusters the instance has. To take full advantage of the benefits of app profiles, you should create and use additional app profiles and use a different app profile for each application or workload.

App profiles are especially important for instances that have two or more clusters, but even if your instance has only one cluster, you should use a unique app profile for each application that you run, or for different components within a single application.

The following sections describe the benefits of creating and using multiple app profiles.

Workload isolation

Using separate app profiles lets you use different routing policies for different purposes. For example, consider a situation when you want to prevent a batch read job (workload A) from increasing CPU usage on clusters that handle an application's steady reads and writes (workload B). You can create an app profile for workload B that routes to a cluster group that excludes one cluster. Then you create an app profile for workload A that specifies single-cluster routing to the cluster that workload B doesn't send requests to.

You can change the settings for one application or function without affecting other applications that connect to the same data.

Observability

Using separate app profiles for different workloads gives you better insight into your applications' usage of Bigtable, because metrics are available per app profile. This increase in observability can be helpful in the following ways:

  • You're able to look at latency at the app profile level to help you determine which application might be impacting overall performance.

  • Monitoring a the CPU utilization per app profile for a workload can help you troubleshoot CPU utilization issues or make decisions about the size or location of the cluster, so you can optimize usage and reduce costs.

  • Metrics at the app profile level are useful if you need to seek support, because you're better able to share the exact workload that is causing an issue.

You can use the Bigtable Google Cloud console to view separate graphs of your Bigtable metrics for each app profile. To learn which metrics that are available at the profile level, see the table at Monitoring charts for Bigtable resources.

Request priority

You can specify the priority that Bigtable should give to an app profile's data requests. To review the priority levels that are available, see Configure request priorities.

App profile changes

If you need to change the routing policy for a workload, you can update the app profile that is used for the workload. Changes are effective immediately.

However, in many cases, instead of modifying an app profile that is in use, you should create a new app profile with a different routing policy and then change your application code to use the new app profile. To see how to view, create, and update app profiles, see Create and configure app profiles.

Default app profile

When you create an instance, Bigtable automatically creates a default app profile for the instance. If your application does not specify an app profile, or if you use the HBase shell to connect to your instance, Bigtable uses the settings in the default app profile.

The settings in an instance's default app profile depend on the number of clusters the instance had when you first created it:

  • If you created the instance with 1 cluster, the default app profile uses single-cluster routing, and it enables single-row transactions. This ensures that adding additional clusters later doesn't change the behavior of your existing applications.
  • If you created the instance with 2 or more clusters, the default app profile uses multi-cluster routing to any cluster. Single-row transactions are never allowed with multi-cluster routing.

The default app profile does not change when you add or remove clusters. You must manually update the default app profile to change its settings. However, as a best practice you should create and use a new app profile instead of changing the default app profile.

Custom app profiles

A custom app profile is an app profile that you create and configure. An instance can have up to 2,000 app profiles. Every app profile that is not the default is considered a custom app profile.

What's next