抛开价格不谈，为啥要选择 Google Cloud Bigtable 而不是 Google Cloud Datastore？

Posted 2023-02-16

【中文标题】抛开价格不谈，为啥要选择 Google Cloud Bigtable 而不是 Google Cloud Datastore？

【英文标题】：Price aside, why ever choose Google Cloud Bigtable over Google Cloud Datastore?抛开价格不谈，为什么要选择 Google Cloud Bigtable 而不是 Google Cloud Datastore？

【发布时间】：2019-04-28 13:53:03

【问题描述】：

如果我有一个同时用于海量数据存储和可搜索性的用例，我为什么会选择 Google Cloud Bigtable 而不是 Google Cloud Datastore？

我已经看到一些关于 SO 和其他方面“比较”Bigtable 和 Datastore 的问题，但似乎归结为相同的非特定答案。

这是我目前的知识和想法：

数据存储更昂贵。

在这个问题的背景下，让我们完全忘记定价。

Bigtable 适用于大型数据集。

Datastore 似乎也是？我看不出是什么让 Bigtable 在客观上更胜一筹。

Bigtable 在分析方面比 Datastore 更好。

怎么样？为什么？看来我也可以在 Datastore 中进行分析，没问题。为什么 Bigtable 似乎是全行业一致的分析决策？ GMail、eBay 等从 Bigtable 中获得了 Datastore 无法提供的哪些价值？

Bigtable 与 Hadoop、Spark 等集成。

考虑到它是基于 Bigtable 构建的，Datastore 是否也不是很好？

来自this question，这个声明是在一个答案中做出的：

Bigtable 和 Datastore 截然不同。是的，数据存储是建立在 Bigtable 之上的，但这并不像它。这有点像说汽车是建立在 [car] 车轮之上的，因此汽车与车轮没有太大区别。

但是，这种类比似乎是荒谬的，因为汽车（包括车轮）在本质上提供的价值不仅仅是汽车的车轮本身。

乍一看，Bigtable 似乎比 Datastore 差，只提供单一索引，限制了快速搜索。我错过了什么？

【问题讨论】：

我建议同时考虑 Cloud Spanner 和 Firestore。我建议在进行比较时考虑每秒 100K+ 操作的性价比。

我还查看了 Firestore，并且肯定也将其加入。我不一定会考虑 Cloud Spanner，因为它是一个关系数据库。在 100K ops/second 时，价格肯定会发挥作用，但这里的用例可能永远不会超过 500-1000 ops/second，而且两家商店之间的价格非常相似。

【参考方案1】：

Bigtable 和 Datastore 针对略有不同的用例进行了优化，并提供了不同的权衡取舍。主要有：

数据模型：

Bigtable 是一个宽列数据库——想想 HBase 和 Cassandra Datastore 是一个文档数据库——想想 MongoDB 请注意，这两种方法都可以用于键值对用例

成本模型：

Bigtable 每个预置节点的费用 数据存储是无服务器的，按操作收费

一般来说，如果您需要，Bigtable 是一个不错的选择：

快速点读取和范围扫描（尤其是在规模上）。 Bigtable 将为键值查找提供更低的延迟，以及对连续行的快速扫描——这是一个强大的工具，因为行是按字典顺序存储的。如果您拥有简单、可预测的查询模式并且设计良好的架构，那么从 Bigtable 中读取数据会非常高效。 高吞吐量写入（再次强调，尤其是大规模写入）。这部分是可能的，因为 Bigtable 最终是一致的 - 作为交换，您可以看到价格/性能方面的巨大胜利。

非常适合 Bigtable 的示例用例包括时间序列数据（用于 IoT、监控等 - 想想极其繁重的工作负载和在 x 单位时间内生成的大量数据）、分析（想想欺诈检测、个性化、推荐）和广告投放（每一微秒都很重要）。

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

查询灵活性：Datastore 提供文档支持和二级索引。 强一致性和/或事务：Bigtable 具有最终一致性复制，不支持多行事务。 移动 SDK：Datastore 和 Firestore 与 firebase 生态系统完美集成。

示例用例包括移动和网络应用程序、游戏状态、用户配置文件和产品目录。

明确回答您的一些问题：

为什么将 Bigtable 用于分析？

这主要与性能有关：分析用例更有可能拥有大型数据集并需要高写入吞吐量。如果您要存储点击流数据，则更容易遇到数据库的限制，而不是像用户帐户信息这样的东西。快速扫描对于分析用例也很重要：Bigtable 允许您非常快速地检索您需要的有关用户或设备的所有信息，您可以在批处理作业中处理这些信息或用于动态创建建议和分析。

Bigtable 真的比 Datastore 差吗？

Datastore 确实提供了更多的内置功能，例如二级索引和文档支持，如果您需要这些功能，Datastore 是一个绝佳的选择。但该功能需要权衡取舍。 Bigtable 提供了可能较低级别但性能令人难以置信的 API，允许用户为自己做出这些权衡：如果用户重视，例如，写性能优于二级索引，那么 Bigtable 是一个很好的选择。您可以将其视为一个用途广泛且功能强大的基础设施构建块。我实际上喜欢车轮/汽车的类比：有时您不想要汽车——如果您真正需要的是一辆越野车，那么一套实心车轮会更有用:)

【讨论】：

感谢 Sandy Ghai 的详细解答。

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

很公平！ Bigtable 在一个区域内是强一致的，并且在区域之间是最终一致的——但大多数时候用户在启用复制时比较一致性模型！