我希望Google提供有关Cloud Bigtable服务提供的耐用性和可用性保证的指导。
到目前为止,我的理解是这样的:
最小集群需要3个节点的事实表明,至少在一个区域内,数据非常耐用,并且复制到3个节点。
然而,Google员工this answer表示" Cloud Bigtable不会复制数据" - 直接与Cloud Bigtable homepage上的引用相矛盾,the documentation声称它是使用复制存储策略构建的#34;。那是哪个呢?它复制与否?如果是这样,保留了多少份?
群集只能在特定区域内设置这一事实表明群集的可用性直接与该区域的可用性相关联。因此,如果我想拥有一个高度可用的基于Bigtable的数据存储,那么最好是跨多个区域设置独立的集群并自己处理集群中的写入同步吗?
没有关于跨区域的Bigtable集群是否独立的信息。如果我要跨多个区域设置集群,并且一个区域出现故障,我们是否可以期望其他区域中的集群继续工作?或者是否存在一些潜在的单一故障点,甚至可能跨区域影响集群?
与针对这些细节非常具体的App Engine数据存储区相比,Cloud Bigtable文档相当缺乏 - 或者至少我没有设法找到一个详细介绍这些方面的页面。 / p>
Cloud Bigtable文档在其他方面同样含糊不清,例如:关于值的大小限制问题,{{3}}指出个别值应保持低于每个单元格大约#10;"。究竟是什么" ~10 MB"意思?!我可以对10MB的限制进行硬编码并期望它始终有效,还是会根据未知因素每天变化?
无论如何,如果我听起来很激动,道歉。我真的很想使用Bigtable服务。但是,我和许多其他人一样,在能够投资之前需要了解它的耐久性/可用性方面。谢谢。
答案 0 :(得分:9)
复制时: 您引用的答案是指跨Bigtable Clusters的数据复制,目前不支持。 (例如,美国的Bigtable Cluster将其写入复制到欧洲的第二个群集中)
这个概念与Bigtable集群中的数据复制是分开的,这类似于HDFS中的复制,这是该产品今天绝对做的事情。
可用性: 是的,Bigtable Cluster的可用性与Google Cloud Zone的可用性有关。
独立: 是的,Cloud Bigtable集群跨区域是独立的。一个区域的中断不应影响其他区域的可用性。
每个单元格的数据: 我们不会拒绝每个单元格写入> 10Mb,我们将此设置作为获得最佳性能的指南。