high-availability - Google Cloud Bigtable 持久性/可用性保证

Question

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

到目前为止，这是我的理解:

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

然而，this answer一位 Google 员工表示“Cloud Bigtable 不会复制数据”——这与 Cloud Bigtable homepage 上的引用直接矛盾。它声称它“是用复制的存储策略构建的”。那么它是哪个？是复制还是不复制？如果是这样，保留了多少副本？

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

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

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

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

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

Answer 1

关于复制:
您引用的答案是指跨 Bigtable 集群的数据复制，目前不支持。 (例如，美国的一个 Bigtable 集群将其写入复制到欧洲的第二个集群)

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

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

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

每个单元格的数据:
我们不会拒绝每个单元 >10Mb 的写入，我们将此设置为获得最佳性能的指导方针。