为什么 BigTable 具有高延迟峰值？

Question

我们有两个 BigTable 集群加入到一个实例中。这些集群之间存在双向复制。据我了解，复制始终是双向的，不可能进行单向复制。 有两个配置文件：

• 首先 - 对于生产，它可以读取和写入并且需要低延迟。该配置文件被路由到一个集群
• 第二个 - 用于分析。该配置文件读取大量数据并路由到另一个集群。

此外，用于分析的集群具有自动扩展策略。默认情况下它有 1 个节点，但是当负载很大时，它会扩展到 10 个节点。

大多数情况下，生产集群提供或多或少一致的延迟。但有时可能会出现高延迟峰值。看起来，与第二个集群上的高读取活动存在相关性（在这些活动期间，集群的负载可能为 100%，并且在扩展期间出现新节点）

问题：一个集群是否有可能影响另一个集群的延迟？有什么方法可以处理吗？

Answer 1

使用复制时的性能当然是基于用例的，并且根据您使用它的业务模型的需要。此外，当您启用复制时，它肯定会影响Bigtable实例的性能当CPU 利用率始终高于建议水平。

我还建议您查看

有关性能和流量路由的官方文档，以了解使用复制时如何保持性能。

在使用您的用例时，一个实例中的多个bigtable集群在读取和写入期间将有自己的分析工作负载，以维持主集群的高可用性。您可以尝试向集群提供额外的CPU资源以拉动在此期间复制发生变化并且不会影响性能。另请检查在此期间是否存在与批量读写或复制线程活动的重新连接，以了解其原因。

Answer 2

您使用什么路由策略？如果您使用多集群路由，某些分析读取可能会影响您的服务/生产集群。

如果您希望分析读取仅针对第二个集群，则应使用单集群路由策略。