Application profiles

An application profile, or app profile, stores settings that tell your Cloud Bigtable instance how to handle incoming requests from an application. When one of your applications connects to a Cloud Bigtable instance, it can specify an app profile, and Cloud Bigtable uses that app profile for any requests that the application sends over that connection.

App profiles affect how your applications communicate with an instance that uses replication. As a result, app profiles are especially useful for instances that have 2 or more clusters. Even if your instance has only 1 cluster, you can use a unique app profile for each application that you run, or for different components within a single application. You can then view separate graphs of your Cloud Bigtable metrics for each app profile.

This page explains the settings that an app profile controls, as well as how app profiles work with your application. For examples of settings you can use to implement common use cases, see Examples of Replication Settings. For details about creating and managing app profiles, see Configuring App Profiles.

If you're using app profiles to configure replication, you should be familiar with the overview of Cloud Bigtable replication before you read this page.

Settings in app profiles

An app profile defines the routing policy that Cloud Bigtable uses. It also controls whether single-row transactions are allowed.

Routing policy

An app profile specifies the routing policy that Cloud Bigtable should use for each request.

  • Single-cluster routing routes all requests to 1 cluster in your instance. If that cluster becomes unavailable, you must manually fail over to another cluster.

  • Multi-cluster routing automatically routes requests to the nearest cluster in an instance. If the cluster becomes unavailable, traffic automatically fails over to the nearest cluster that is available. Cloud Bigtable considers clusters in a single region to be equidistant, even though they are in different zones.

For more information about failovers, see Failovers. To learn how to complete a failover, see Managing Failovers.

Single-row transactions

In Cloud Bigtable, reads and writes are always atomic at the row level. Cloud Bigtable does not provide atomicity above the row level; for example, Cloud Bigtable does not support transactions that atomically update more than one row.

However, Cloud Bigtable also supports some write operations that would require a transaction in other databases:

  • Read-modify-write operations, including increments and appends. A read-modify-write operation reads an existing value; increments or appends to the existing value; and writes the updated value to the table.
  • Check-and-mutate operations, also known as conditional mutations or conditional writes. In a check-and-mutate operation, Cloud Bigtable checks a row to see if it meets a specified condition. If the condition is met, Cloud Bigtable writes new values to the row.

In effect, Cloud Bigtable uses single-row transactions to complete these operations. These operations include both reads and writes, and all of the reads and writes are executed atomically, but the operations are still atomic only at the row level.

Conflicts between single-row transactions

Every cluster in a Cloud Bigtable instance is a primary cluster that accepts both reads and writes. As a result, operations that require single-row transactions can cause problems when you enable replication. For example, suppose that a cell contains the value ABC, and you send two append operations to different clusters; one append changes the value to ABCDEF, and the other append changes the value to ABCXYZ. How should Cloud Bigtable resolve this conflict?

To help you avoid these issues, Cloud Bigtable requires each app profile to specify whether it allows single-row transactions. It also prevents you from enabling single-row transactions in an app profile that uses multi-cluster routing, because there's no safe way to enable both of these features at once.

Cloud Bigtable also warns you if you enable single-row transactions in 2 different app profiles that both use single-cluster routing, and that point to different clusters. If you choose to create this type of configuration, you must ensure that you do not send conflicting read-modify-write or check-and-mutate requests to 2 different clusters.

How app profiles work

An app profile specifies the settings that Cloud Bigtable uses to handle an instance's incoming requests.

Many Cloud Bigtable users have multiple applications that connect to the same instance. For example, you might have one application that serves data to customers on request, and another application that runs occasional batch jobs to analyze your data. To handle these different applications, you should create multiple app profiles—at a minimum, one for each application—and configure each app profile with the right settings for that application. This setup makes it possible to change the settings for one application but not others.

You might also have a single application that performs multiple functions, such as viewing current data and querying historic data. To handle these different functions, you should create one app profile for each function, so you can configure each function differently and update the settings for one function but not others.

Every instance has a default app profile, and you can create custom app profiles for each instance as well. The sections below describe default and custom app profiles.

You use an app profile by specifying that profile in your code when you connect to your instance. If you do not specify an app profile, Cloud Bigtable uses the instance's default app profile.

Default app profile

When you create an instance, Cloud 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, Cloud Bigtable uses the settings in the default app profile. You can view and change these settings at any time.

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

Custom app profiles

You can create many different custom app profiles for each instance. Use custom app profiles to control how each application, or each distinct function within an application, interacts with an instance. For example, you might use one app profile for a batch application to isolate its traffic to a single cluster, and you might use a different app profile to provide high availability for another application.

What's next