复制和性能

启用复制会影响 Bigtable 实例的性能。这对某些指标而言是正面影响,而对于其他指标则是负面影响。您应该先了解性能可能受到的影响,然后再决定是否启用复制。

读取吞吐量

复制可以提高读取吞吐量,尤其是在使用多集群路由的情况下。此外,复制可将您的 Bigtable 数据放置在地理位置上更接近应用的用户,从而减少读取延迟时间。

写入吞吐量

虽然复制可以提高可用性和读取性能,但它不会增加写入吞吐量。对一个集群的写入必须复制到实例中的所有其他集群。因此,每个集群都会消耗 CPU 资源以从其他集群中拉取更改。实际上,写入吞吐量可能会下降,因为复制会要求每个集群执行更多工作。

例如,假设您有一个单集群实例,且该集群包含 3 个节点:

包含 3 个节点的单集群实例

如果您向集群添加节点,这对写入吞吐量产生的影响,与向实例添加第二个含 3 个节点的集群来启用复制所产生的影响不同。

向原始集群添加节点:您可以向集群添加 3 个节点(总共 6 个节点)。实例的写入吞吐量会加倍,但实例的数据仅在一个地区中可用:

包含 6 个节点的单集群实例

使用复制:此外,您也可以添加第二个含 3 个节点(总共 6 个节点)的集群。现在,出现以下情况时该实例将各个数据写入两次:首次接收写入时以及将写入复制到另一个集群时。写入吞吐量不会增加,还有可能会下降,但是您将从数据在两个不同地区可用中获益。

包含 6 个节点的双集群实例

在这些示例中,即使每个实例的集群总共有 6 个节点,单集群实例所处理的写入吞吐量也可以是复制实例可以处理的两倍。

复制延迟时间

使用多集群路由时,Bigtable 的复制最终一致。一般来说,距离越远,复制数据需要更长的时间。相较于同一区域中的复制集群,不同区域中的复制集群的复制延迟时间通常更长。

节点使用率

写入吞吐量中所述,当实例使用复制功能时,除了处理从应用接收的负载之外,实例中的每个集群还必须处理复制工作。因此,多集群实例中的集群通常需要的节点比单集群实例中具有类似流量的集群更多。

应用配置文件和流量路由

根据您的用例,您将使用一个或多个应用配置文件来路由您的 Bigtable 流量。每个应用配置文件都使用多集群或单集群路由。选择的路由可能会影响性能。

多集群路由可将延迟时间减至最低。从应用的角度来看,使用多集群路由的应用配置文件会自动将请求路由到实例中最近的集群,然后写入将会复制到实例中的其他集群。这种自动选择的最短距离会使延迟时间达到可能限度内的最低值。

使用单集群路由的应用配置文件对于某些用例(例如分离工作负载或在单个集群上具有写后读语义)可能是最佳选择,但它不会像多集群路由那样减少延迟时间。

如需了解如何为这些和其他用例配置您的应用配置文件,请参阅复制设置的示例

舍弃行范围

如果可能,请请尽量避免在使用复制功能的实例中丢弃一定范围的行,因为操作会很慢,CPU 使用率在操作期间会增加。

后续步骤