Google App Engine 中的 Datastore 与 Cloud SQL

Posted 2023-02-16

【中文标题】Google App Engine 中的 Datastore 与 Cloud SQL

【英文标题】：Datastore vs Cloud SQL in Google App Engine

【发布时间】：2014-04-10 12:41:36

【问题描述】：

我想构建一个服务于很多人（超过 200 万）的应用程序，所以我认为我应该使用 Google Cloud Datastore。不过我也知道有一个选项可以使用 Google Cloud SQL 并且仍然使用 mysql 为很多人提供服务（就像 Facebook 和 Youtube 所做的那样）。 这是使用 Datastore 而不是使用这么多用户的关系 Cloud SQL 的正确假设吗？提前谢谢你

【问题讨论】：

Google cloud sql 非常昂贵，除非您正在创建“测试/播放应用程序”，或者除非您的应用程序不需要存储大量数据，否则使用它根本不可行。

【参考方案1】：

要给出明智的答案，我需要更多地了解您的应用。但是...我将概述我发现的最大问题...

Google Datastore 实际上是一种分布式分层数据存储。为了获得他们想要的可扩展性，必须做出一些妥协。作为开发人员，您会发现这些问题从容易解决、难以解决或无法解决。后者的可能性比你想象的要大得多。

如果您习惯于关系型数据库以及在同一事务中跨多个表操作数据的能力，那么您可能会对数据存储区束手无策。最大的（？）问题是交易仅支持有限数量的实体组（目前为 5 个）。举个简单的例子，假设你有一个简单的父子关系，你需要在一个事务中同时更新超过 5 个父子的子记录......不能完成（是的，真的）。如果您重新组织数据结构并尝试将所有以前的子记录放在单个实体下，以便可以在单个事务中更新它们，您将遇到另一个限制......您无法可靠地更新相同的事实实体组每秒不止一次（是的，真的）。如果您跨父实体查询一个实体类型而不指定每个实体的根实体，您将得到委婉地称为“最终一致性”的东西......这意味着它不是（是的，真的）。

以上内容都在谷歌的文档中，但如果你刚刚开始，你可能会忽略它（当然它可以处理它！）。

【讨论】：

注意限制已更改可能会有所帮助，例如：事务中可以访问的实体组的最大数量现在是 25。您可以在此处找到最新的限制：@ 987654321@

【参考方案2】：

严格来说，Facebook 和 YouTube 使用 MySQL 将其大部分内容提供给大多数用户并不完全正确。它们都主要使用非常大的 NoSQL 存储（Cassandra 和 BigTable）来实现可扩展性，并且可能将 MySQL 用于需要更复杂关系存储的小规模工作。如果可以，请尝试使用 Datastore，因为您可以免费开始使用，并且在处理大量数据时还可以节省资金。

【讨论】：

实际上我的应用将服务超过 200 万人，拥有大约 5 万个实体？那么您认为数据存储是最佳选择吗？

【参考方案3】：

这取决于你所说的“很多人”是什么意思，你拥有什么样的数据，以及你想用它做什么。

Cloud SQL 专为需要 SQL 数据库的应用程序而设计，该数据库可以处理您可以用 SQL 编写的任何查询，并确保您的数据始终处于一致状态。

Cloud SQL 最多可以处理 3200 个并发查询，具体取决于层级。如果查询很简单并且可以从 RAM 中提供服务，它们应该只需要几毫秒，并且假设您的用户每秒发出大约 1 个请求，那么它可以同时支持数以万计的活跃用户。但是，如果他们正在执行更复杂的查询，例如搜索，或者写入大量数据，那么它会更少。

如果您有一组简单的查询，不太关心即时一致性，或者期望更多流量，那么您应该查看数据存储区。

【讨论】：

实际上我的应用将服务超过 200 万人，拥有大约 5 万个实体？那么您认为数据存储是最佳选择吗？

随着数据量的增加，分布式键值系统（如 Datastore）的效率将在速度和成本方面越来越优于 SQL。这不仅适用于 AppEngine，也适用于 Azure 等云平台，一起来看看吧。如果您的意思是 200 万人，每人拥有 50,000 个实体，那么这将是 1000 亿个实体，并且绝对有利于 Datastore。如果你的意思是 200 万人共享相同的 5 万个实体，那么 SQL 是可行的，你可以使用 Memcache 来提高性能。但无论如何，Memcache 更像是 Datastore 而不是 SQL。