Google Cloud Bigtable 耐用性/可用性保证

Question

我希望 Google 的某个人就Cloud Bigtable 服务提供的持久性和可用性保证提供一些指导。

这是我目前的理解：

• 最小集群需要 3 个节点这一事实表明，至少在一个区域内，数据具有高度持久性，并且可以复制到 3 个节点。

• 但是，Google 员工的 this answer 声明“Cloud Bigtable 不会复制数据”——这与 Cloud Bigtable homepage 上的引述直接矛盾，后者声称它“采用复制的存储策略构建”。那么它是哪一个？是复制还是不复制？如果有，保留多少份？

• 只能在特定区域内设置集群这一事实表明，集群的可用性与该区域的可用性直接相关。那么如果我想拥有一个高可用的基于 Bigtable 的数据存储，最好是跨多个区域设置独立的集群并自己处理跨集群的写入同步吗？

没有关于跨区域的 Bigtable 集群是否独立的信息。如果我要跨多个区域设置集群，并且一个区域出现故障，我们是否可以期望其他区域中的集群继续工作？或者是否存在一些潜在的单点故障，甚至会影响跨区域的集群？

与对这些细节非常具体的 App Engine 数据存储区相比，Cloud Bigtable 文档相当缺乏 — 或者，至少，我还没有找到详细介绍这些方面的页面。

Cloud Bigtable 文档在其他方面也同样含糊不清，例如关于值的大小限制，the documentation 声明单个值应保持在“每个单元格约 10 MB”以下。 “~10 MB”到底是什么意思？！我可以硬编码一个正好为 10MB 的限制，并期望它始终有效，还是会因未知因素而每天发生变化？

无论如何，如果我听起来很激动，请道歉。我真的很想使用 Bigtable 服务。但我和其他许多人一样，需要先了解它的耐用性/可用性方面，然后才能对其进行投资。谢谢。

Answer 1

复制时： 您引用的答案是指跨 Bigtable Clusters 的数据复制，目前不支持。 （例如，美国的一个 Bigtable 集群将其写入复制到欧洲的第二个集群）

这个概念与 Bigtable 集群中的数据复制是分开的，后者类似于 HDFS 中的复制，而 HDFS 中的复制是该产品今天绝对要做的事情。

关于可用性： 是的，Bigtable 集群的可用性与 Google Cloud Zone 的可用性相关。

关于独立： 是的，Cloud Bigtable 集群是跨地区独立的。一个区域的中断不应影响其他区域的可用性。

关于每个单元格的数据： 我们不拒绝每个单元格大于 10Mb 的写入，我们将此设置作为获得最佳性能的指南。