Replication and performance

Enabling replication affects the performance of a Bigtableinstance. The effect is positive for some metrics and negative for others. Youshould understand potential impacts on performance before deciding to enablereplication.

Read throughput

Replication can improve read throughput, especially when you use multi-clusterrouting. Additionally, replication can reduce read latency by placing yourBigtable data geographically closer to your application's users.

Write throughput

Although replication can improve availability and read performance,it doesnot increase write throughput. A write to one cluster must be replicated toall other clusters in the instance. As a result, each cluster is expending CPUresources to pull changes from the other clusters. Write throughput mightactually go down because replication requires each cluster to do additionalwork.

For example, suppose you have a single-cluster instance, and the cluster has 3nodes:

If you add nodes to the cluster, the effect on write throughput is differentthan if you enable replication by adding a second 3-node cluster to theinstance.

Adding nodes to the original cluster: You can add 3 nodes to the cluster,for a total of 6 nodes. The write throughput for the instance doubles, but theinstance's data is available in only one zone:

With replication: Alternatively, you can add a second cluster with 3nodes, for a total of 6 nodes. The instance now writes each piece of data twice:when the write is first received and again when it is replicated to the othercluster. The write throughput does not increase, and might go down, but youbenefit from having your data available in two different zones:

In these examples, the single-cluster instance can handle twice the writethroughput that the replicated instance can handle, even though each instance'sclusters have a total of 6 nodes.

Replication latency

When you use multi-cluster routing, replication for Bigtable iseventually consistent. As a general rule, it takeslonger to replicate data across a greater distance. Replicated clusters indifferent regions will typically have higher replication latency thanreplicated clusters in the same region.

Node usage

As explained inWrite throughput, when aninstance uses replication, each cluster in the instance must handle the work ofreplication in addition to the load it receives from applications. For thisreason, a cluster in a multi-cluster instance often needs more nodesthan a cluster in a single-cluster instance with similar traffic.

App profiles and traffic routing

Depending on your use case, you will use one or more app profiles to route yourBigtable traffic. Each app profile uses either multi-cluster orsingle-cluster routing. The choice of routing can affect performance.

Multi-cluster routing can minimize latency. An app profile with multi-clusterrouting automatically routes requests to the closest cluster in an instance fromthe perspective of the application, and the writes are then replicated to theother clusters in the instance. This automatic choice of the shortest distanceresults in the lowest possible latency.

An app profile that uses single-cluster routing can be optimal for certain usecases, like separating workloads or to have read-after-write semantics on asingle cluster, but it won't reduce latency in the way multi-cluster routingdoes.

To understand how to configure your app profiles for these and other use cases,seeExamples of Replication Settings.

Dropping row ranges

If possible,avoid dropping a row range in aninstance that uses replication because the operation is slow and the CPU usageincreases during the operation.

What's next

• Read aboutFailovers.
• ExploreRouting options.