Routing options

When you send requests from an application to Bigtable, you use anappprofile that tells Bigtable how tohandle the requests. An app profile specifies theroutingpolicy for the requests. For instances that use replication, the routing policycontrols which clusters receive the requests and how failovers are handled.

This document describes the routing policies that are available for a standardapp profile.

Routing policies are especially important forworkloadisolation use cases, whenyou're not able to useData Boost. Youcan configure them in conjunction withrequestpriorities.

Routing policies don't affect replication, but you should be familiar with howBigtablereplication works before you read this page. You should also readFailovers.

Single-cluster routing

A single-cluster routing policy routes all requests to one cluster in yourinstance. If that cluster becomes unavailable, you must manually fail over toanother cluster.

This is the only routing policy that lets you enablesingle-rowtransactions.

A replicated instance normally provideseventualconsistency. However, you can achieveread-your-writesconsistency for a workload in a replicated instance if you configure an app profile for thatworkload to use single-cluster routing to send read and write requests to thesame cluster. You can route traffic for additional workloads on the replicatedinstance to other clusters in the instance depending on your workloadrequirements.

Multi-cluster routing

A multi-cluster routing policy routes requests that you send to an instance tothe nearest region that the instance has a cluster in. If the cluster becomesunavailable, traffic automatically fails over to the nearest cluster that isavailable.

This configuration provides eventual consistency. You can't enable single-rowtransactions with multi-cluster routing, because single-row transactions cancausedataconflicts when you use multi-cluster routing. For details, seeSingle-rowtransactions.

Use multi-cluster routing if you want high availability (HA). For recommendedinstance configurations and further details, seeCreate high availability(HA).

When you use multi-cluster routing, you can route requests toany cluster inthe instance or to acluster group that you define. If your workload consistsmostly of single-row operations and you want to achieve a higher rate ofread-your-writes consistency, you can enablerow-affinity routing.

For more information about SQL-related routing considerations, see theRouting with SQL section of this document.

Any cluster routing

Any cluster routing makes every cluster in the instance available to receiverequests and for failover.

Cluster group routing

If you want to exclude one or more of an instance's clusters from possiblefailover, you can use cluster group routing. This form of multi-cluster routinglets you specify a subset of clusters that an app profile can send traffic to.This can be helpful if you want to reserve a cluster for a separate workload.

Row-affinity routing

Row-affinity routing automatically routes single-row read and writerequests to a specific cluster based on the row key of the request.

For more information about failovers, seeFailovers. To learn how to complete a failover, seeManagingfailovers.

Routing with SQL

When you use SQL to query Bigtable, there are specialconsiderations for how your requests are routed. The routing behavior for SQLqueries differs from other types of Bigtable requests in thefollowing ways:

• While amulti-cluster routing policy provides highavailability through automatic failover for most requests, this behaviordoesn't extend to SQL queries. If a SQL request fails, it won't fail over toanother cluster, even if your app profile is configured for multi-clusterrouting.
• Row-affinity routing directs single-row reads and writesautomatically to a specific cluster based on the row key. However,Bigtable doesn't support this routing policy for SQL queries.This limitation means that you can't use row-affinity routing with theExecuteQuery method, even if the query is designed to read a single row.If you send anExecuteQuery request using an app profile with the--row-affinity flag enabled, the request succeeds, but row affinity isn'tenforced.

Single-row transactions

In Bigtable mutations, such as read, write, and delete requests,are always atomic at the row level. This includes mutations to multiple columnsin a single row, as long as they are included in the samemutation operation. Bigtable doesn'tsupport transactions that atomically update more than one row.

However, Bigtable supports some write operations that wouldrequire a transaction in other databases. In effect, Bigtable usessingle-row transactions to complete these operations. These operations includereads and writes, and all of the reads and writes are executed atomically,but the operations are still atomic only at the row level:

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

If your use case allows it, you can avoid these conflicts by using aggregates.When you send an add request to an aggregate field, the new value is merged withthe existing value. Aggregates let you keep a running sum or counter. For moreinformation, seeAggregate values at write time.

To illustrate the problem that can arise when you don't use aggregates, supposeyou have a table that you use to store data for a ticketing system. You use aninteger counter to store the number of tickets that have been sold. Each timeyou sell a ticket, your app sends aread-modify-writeoperation to increment the counter by 1.

If your instance has one cluster, client apps can sell tickets at the same timeand increment the counters without data loss because the requests are handledatomically in the order they are received by that single cluster.

On the other hand, if your instance has multiple clusters and your app profilewere to allow multi-cluster routing, simultaneous requests to increment thecounter might each be sent to different clusters, then replicated to the otherclusters in the instance. If you send two increment requests at the same timethat are routed to different clusters, each finishes its transaction without"knowing" about the other. The counter on each cluster is incremented by one.When the data is replicated to the other cluster, Bigtable can'tpossibly know that you meant to increment by 2.

To help you avoid unintended results, Bigtable does the following:

• Requires each app profile to specify whether it allows single-rowtransactions.
• Prevents you from enabling single-row transactions in an app profilethat uses multi-cluster routing, because there's no safe way to enable both ofthese features at once.
• Warns you if you enable single-row transactions in two or more different appprofiles that use single-cluster routing and point to different clusters. If youchoose to create this type of configuration, you must ensure that you don'tsend conflicting read-modify-write or check-and-mutate requests to differentclusters.

What's next

• Review examples of replication settings.
• Learn how to manage failovers.
• Change an app profile's routing policy.