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 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 specifies the routing policy that Cloud Bigtable should use for each request:
- Single-cluster routing routes all requests to 1 cluster in your instance.
- Multi-cluster routing tells Cloud Bigtable that it can route each request to any available cluster.
If one cluster becomes unavailable, and an app profile uses multi-cluster routing, any traffic that uses that app profile automatically fails over to the other cluster. In contrast, if an app profile uses single-cluster routing, you must manually fail over.
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
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 easy 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 both types of app profile.
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 how many clusters it had when you first created it:
- If you created the instance with 1 cluster, the default app profile routes all traffic to that cluster, and it enables single-row transactions.
- If you created the instance with 2 clusters, the default app profile routes traffic to any available cluster, and it disables single-row transactions.
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.