我希望 Google 的某个人就Cloud Bigtable服务提供的持久性和可用性保证提供一些指导。
到目前为止，这是我的理解：
最小集群需要 3 个节点这一事实表明，至少在一个区域内，数据是高度持久的，并且可以复制到 3 个节点。
然而，谷歌员工的这个回答指出“Cloud Bigtable 不会复制数据”——这与Cloud Bigtable 主页上声称它“使用复制的存储策略构建”的引述直接矛盾。那么它是哪一个？是复制还是不复制？如果是这样，保留多少份？
只能在特定区域内设置集群这一事实表明，集群的可用性与该区域的可用性直接相关。那么如果我想拥有一个高可用的基于 Bigtable 的数据存储，最好是跨多个区域设置独立集群并自己处理跨集群的写入同步吗？
没有关于跨区域的 Bigtable 集群是否独立的信息。如果我要跨多个区域设置集群，并且一个区域出现故障，我们是否可以期望其他区域中的集群继续工作？或者是否存在一些潜在的单点故障，甚至可能影响跨区域的集群？
与对这些细节非常具体的 App Engine 数据存储区相比，Cloud Bigtable 文档相当缺乏——或者，至少，我还没有找到一个详细介绍这些方面的页面。
Cloud Bigtable 文档在其他方面同样含糊不清，例如在值的大小限制问题上，文档指出单个值应保持在“每个单元格约 10 MB”以下。“~10 MB”到底是什么意思？！我可以硬编码一个正好为 10MB 的限制并期望它始终有效，还是会根据未知因素每天发生变化？
无论如何，如果我听起来很激动，请道歉。我真的很想使用 Bigtable 服务。但我可能和其他许多人一样，需要先了解它的耐用性/可用性方面，然后才能对其进行投资。谢谢你。