除了价格之外，为什么会选择谷歌云大表格（Google Cloud Bigtable），而不是谷歌云数据存储（Google Cloud Datastore）？

Question

如果我需要大数据存储和可搜索性的用例，为什么会选择Google Cloud Bigtable而不是Google Cloud Datastore？我看到一些在SO和其他网站上“比较”Bigtable和Datastore的问题，但似乎都归结于相同的非具体答案。据我目前的了解和思考：

- Datastore更昂贵。 - 在这个问题的背景下，让我们完全忘记价格。 - Bigtable适用于大型数据集。 - Datastore似乎也是如此？我没有看到什么明确使Bigtable在这里客观优越的东西。 - Bigtable比Datastore更适合分析。 - 如何？为什么？看起来我也可以在Datastore中进行分析，没有问题。为什么Bigtable在行业范围内似乎是一致的决定？GMail、eBay等从Bigtable获得哪些Datastore无法提供的价值？ - Bigtable与Hadoop、Spark等集成。 - 考虑到Datastore是建立在Bigtable之上构建的，它不也是吗？

根据这个问题的回答，有人说：

- Bigtable和Datastore非常不同。是的，Datastore是建立在Bigtable之上的，但这并不意味着它与Bigtable类似。这有点像说汽车是建立在[汽车]轮子上的，因此汽车与轮子并没有太大的区别。

然而，这个比喻似乎是无意义的，因为汽车（包括轮子）本质上比仅有轮子的汽车提供更多价值。

乍一看，Bigtable似乎严格劣于Datastore，只提供单个索引并限制快速搜索能力。我错过了什么？

- zeBugMan

---

我建议在考虑时也将Cloud Spanner和Firestore加入其中。当进行比较时，建议考虑每秒100K+操作的价格/性能。 - Solomon Duskis

我还研究了Firestore，绝对可以加入其中。我并没有考虑Cloud Spanner，因为它是一个关系型数据库。每秒100K次操作的情况下，价格肯定会成为一个考虑因素，但在这种情况下，使用量可能永远不会超过500-1000次操作/秒，而且这两个存储之间的价格相当接近。 - zeBugMan

Answer 1

Bigtable和Datastore针对不同的使用情况进行了优化，并提供不同的权衡。其中主要的差异包括：

数据模型：

• Bigtable是一个宽列数据库——类似于HBase和Cassandra
• Datastore是一个文档数据库——类似于MongoDB
• 请注意，这两者都可以用于键值（key-value）用例。

成本模型：

• Bigtable按预配节点收费
• Datastore是无服务器的，并按操作计费

一般而言，如果您需要以下功能，则Bigtable是一个不错的选择：

• 快速点读和范围扫描（特别是在大规模情况下）。对于键值查找和连续行的快速扫描，Bigtable将提供更低的延迟——这是一个强大的工具，因为行以词典顺序存储。如果您有简单、可预测的查询模式并且良好设计架构，从Bigtable中读取数据可以非常高效。
• 高吞吐量写入（再次特别是在大规模情况下）。这在某种程度上是因为Bigtable最终一致性——作为交换，您可以在性价比方面获得巨大的优势。

适合Bigtable的示例用例包括时间序列数据（用于物联网、监测等——考虑极高的写入负载和在x时间单位内生成的海量数据）、分析（考虑欺诈检测、个性化、推荐）和广告投放（每微秒都很重要）。

Datastore（或Firestore）是一个不错的选择，如果你需要：

• 查询灵活性：Datastore提供文档支持和次要索引。
• 强一致性和/或事务：Bigtable具有最终一致性复制，并不支持多行事务。
• 移动SDK：Datastore和Firestore与Firebase生态系统非常良好地集成在一起。

示例用例包括移动和Web应用程序、游戏状态、用户资料和产品目录。

回答一些你的问题：

• 为什么Bigtable用于分析？ 主要是因为性能：分析用例更有可能有大型数据集，并且需要高写入吞吐量。如果你存储点击流数据，而不是像用户账户信息之类的东西，更容易达到数据库的限制。快速扫描对于分析用例也很重要： Bigtable可以让你极快地检索有关用户或设备的所有信息，这可以在批处理作业中处理，也可以用于实时创建推荐和分析。

Bigtable和Datastore相比严格劣于它吗？ Datastore提供了更多内置功能，如二级索引和文档支持。如果您需要这些功能，则Datastore是一个不错的选择。但这些功能会带来一些权衡。Bigtable提供了可能更低级别但极具性能的API，使用户可以自行进行这些权衡：如果用户将写入性能视为重要因素而非二级索引，则Bigtable是一个很好的选择。您可以将其看作是一个非常灵活且强大的基础构建块。我喜欢轮子/汽车的类比：有时候您并不想要汽车-如果您真正需要的是越野摩托车，则一组坚固的轮子更加有用 :)

- Sandy Ghai

---

“Bigtable最终是一致的” - 这是不正确的。除非使用集群复制，否则Bigtable是强一致的。 - egordoe

好的！Bigtable在区域内是强一致性的，在区域之间则是最终一致性的——但大多数情况下，用户在启用复制时比较一致性模型！ - Sandy Ghai