时间戳

首页 > 解决方案 > BigTable中实例数的建议

google-cloud-bigtable - BigTable中实例数的建议

问题描述

关于 BigTable 中应该有多少个实例，是否有任何最佳实践或建议？这两种情况有什么好的做法？

a) 有 2 个实例，每个实例有 2 个集群

或者

b）只有 1 个实例和 2 个集群：

我知道集群是为了可复制性，上述两种情况都是复制的因素。

对我来说，情况 b) ( 1 Instance ) 更有效，因为它不仅涵盖复制，而且还涵盖两个区域，us-EAST1 和 us-EAST4，并且少了 1 个实例（因此少了 $$$ ）。

请根据您所知道的和/或如果您在这方面也有任何实际经验，请就此提出建议。

标签： google-cloud-bigtablebigtable

解决方案

虽然每个用例都取决于业务需求，但每个复制配置都有自己的影响力。我将指出这两种情况之间需要考虑的一些重要主题。

Bigtable 是一个高性能可扩展的 NoSQL 数据库，非常适合大型分析工作负载。关于Replication，根据文档，它使您能够提高可用性和持久性。此外，它被认为是最终一致的，这意味着当您将更改写入集群时，只要在集群之间复制更改，它就能够从实例中的其他集群读取更改。

  • 复制和吞吐量

读取吞吐量：复制可以提高读取吞吐量，特别是在使用多集群路由时。如果集群更靠近客户所在的区域，它还可以减少延迟。你可以在这里阅读更多关于它。

写入吞吐量：根据文档，复制不会增加写入吞吐量。写入吞吐量可能会下降，因为对一个集群的写入必须复制到其他集群。因此，每个集群都在花费更多的 CPU 资源来从其他集群中提取更改。例如：

  • 如果集群中的节点数量翻倍，一个 3 节点集群现在有 6 个节点（例如），实例的写入吞吐量翻倍。但是，数据仅在一个区域中可用。

  • 添加第二个节点数相同的集群，一个集群有 3 个节点，另一个集群有 3 个节点，总共 6 个节点。然后，数据在两个不同的区域中可用，但写入吞吐量可能会下降，因为每条数据在复制到其他集群时会写入两次。

复制延迟：不同区域中的复制集群通常比同一区域内的集群具有更高的延迟。

您还应该在业务需求中考虑应用配置文件和流量路由。多集群路由可以最大限度地减少延迟，因为它是一种自动选择，可以将请求路由到实例中最近的集群（从应用程序的角度来看），从而导致可能的最低延迟。而单集群路由可用于分离工作负载或在同一集群中具有读写语义。

Google 准备了一些复制用例示例，以阐明每种设置的优势。我鼓励你看看这里。

如果您需要更多架构建议，您还可以联系 GCP，点击此处。

更新

分析你的2个案例：

如果您有 1 个实例和 4 个集群，它将保持您的数据高度可用。此外，如果集群在同一个区域但不同的可用区，它将增加区域弹性和故障转移能力，而不会产生跨区域复制成本。但是，您只能有一个应用配置文件（多或单集群路由）。这意味着，您将无法将分析工作负载与其他应用程序分开。因此，当您需要运行大型批处理作业时，它可能会减慢应用程序用户的速度。

现在，如果您有 2 个实例，每个实例有 2 个集群。如果集群位于同一区域的同一实例，则您可以获得高可用性甚至区域弹性。但是，如果集群位于不同的区域，则会产生从一个区域到另一个区域的复制成本。此外，表/数据属于实例。因此，您将能够将分析工作负载与其他应用程序分开，这将有助于提高性能（在运行大批量作业时），每个实例都有自己的 App Profile 配置。

推荐阅读