feat: Add support for Cloud Bigtable Row Affinity in App Profiles

PiperOrigin-RevId: 673093969

google/bigtable/admin/v2/instance.proto

@@ -258,9 +258,34 @@ message AppProfile {
  // equidistant. Choosing this option sacrifices read-your-writes consistency
  // to improve availability.
  message MultiClusterRoutingUseAny {
+ // If enabled, Bigtable will route the request based on the row key of the
+ // request, rather than randomly. Instead, each row key will be assigned
+ // to a cluster, and will stick to that cluster. If clusters are added or
+ // removed, then this may affect which row keys stick to which clusters.
+ // To avoid this, users can use a cluster group to specify which clusters
+ // are to be used. In this case, new clusters that are not a part of the
+ // cluster group will not be routed to, and routing will be unaffected by
+ // the new cluster. Moreover, clusters specified in the cluster group cannot
+ // be deleted unless removed from the cluster group.
+ message RowAffinity {}
+
  // The set of clusters to route to. The order is ignored; clusters will be
  // tried in order of distance. If left empty, all clusters are eligible.
  repeated string cluster_ids = 1;
+
+ // Possible algorithms for routing affinity. If enabled, Bigtable will
+ // route between equidistant clusters in a deterministic order rather than
+ // choosing randomly.
+ //
+ // This mechanism gives read-your-writes consistency for *most* requests
+ // under *most* circumstances, without sacrificing availability. Consistency
+ // is *not* guaranteed, as requests might still fail over between clusters
+ // in the event of errors or latency.
+ oneof affinity {
+ // Row affinity sticky routing based on the row key of the request.
+ // Requests that span multiple rows are routed non-deterministically.
+ RowAffinity row_affinity = 3;
+ }
  }
 
  // Unconditionally routes all read/write requests to a specific cluster.