我想构建一个能够为大量人（超过200万）提供服务的应用程序，因此我认为我应该使用Google Cloud Datastore。然而，我也知道有一个选项可以使用Google Cloud SQL，并且仍然可以使用mySQL为大量用户提供服务（就像Facebook和Youtube一样）。
使用Datastore而不是关系型Cloud SQL是否是正确的假设，当有这么多用户时？ 非常感谢。
谷歌应用引擎中的数据存储(Datastore)与云SQL(Cloud SQL)的比较
17
- user3376321
1
1Google Cloud SQL的价格昂贵得难以承受，除非您只是在创建一个“测试/玩耍”的应用程序，或者您的应用程序并不需要存储大量数据，否则使用它根本不可行。 - Pacerier
3个回答
32
为了给出一个智能的答案，我需要了解更多关于您的应用程序的信息。但是...我会概述我发现的最大的陷阱...
Google Datastore实际上是一个分布式层次数据存储库。为了获得他们想要的可伸缩性，必须做出一些让步。作为开发人员，你会发现这些让步从容易解决到难以解决，或者根本无法解决。后者比你想象的要多得多。
如果您习惯于关系型数据库和在同一事务中跨多个表操作数据的能力，则可能会因datastore而抓狂。最大的（？）陷阱是事务仅受到有限数量的实体组支持（当前为5个）。举个简单的例子，假设您有一个简单的父子关系，并且需要在同一事务中更新超过5个父记录下的子记录...无法完成（是的，真的）。如果重新组织数据结构并尝试将所有以前的子记录放在单个实体下，以便可以在单个事务中进行更新，那么您将遇到另一个限制...无法可靠地每秒更新同一实体组超过一次（是的，真的）。如果您在未指定每个根实体的情况下查询跨父级的实体类型，则会得到委婉地称为“最终一致性”的结果...这意味着它并不是（是的，真的）。
以上所有内容都在Google文档中，但如果您刚开始使用可能会忽略它（当然可以处理它！）。
Google Datastore实际上是一个分布式层次数据存储库。为了获得他们想要的可伸缩性，必须做出一些让步。作为开发人员，你会发现这些让步从容易解决到难以解决，或者根本无法解决。后者比你想象的要多得多。
如果您习惯于关系型数据库和在同一事务中跨多个表操作数据的能力，则可能会因datastore而抓狂。最大的（？）陷阱是事务仅受到有限数量的实体组支持（当前为5个）。举个简单的例子，假设您有一个简单的父子关系，并且需要在同一事务中更新超过5个父记录下的子记录...无法完成（是的，真的）。如果重新组织数据结构并尝试将所有以前的子记录放在单个实体下，以便可以在单个事务中进行更新，那么您将遇到另一个限制...无法可靠地每秒更新同一实体组超过一次（是的，真的）。如果您在未指定每个根实体的情况下查询跨父级的实体类型，则会得到委婉地称为“最终一致性”的结果...这意味着它并不是（是的，真的）。
以上所有内容都在Google文档中，但如果您刚开始使用可能会忽略它（当然可以处理它！）。
- Robert D
1
2值得注意的是，限制已经发生了变化，例如：在事务中可以访问的实体组的最大数量现在为25。您可以在此处找到最新的限制：https://cloud.google.com/datastore/docs/concepts/limits - David Salzer
19
Facebook和YouTube并不严格使用MySQL来为大多数用户提供大部分内容。它们主要使用非常大的NoSQL存储（Cassandra和BigTable）来实现可扩展性，并可能在需要更复杂的关系型存储的小规模工作中使用MySQL。如果可以，请尝试使用Datastore，因为您可以免费开始，并在处理大量数据时也会节省费用。
- Martin Berends
1
1实际上，我的应用程序将为超过2百万人提供服务，并拥有约5万个实体。那么，您认为数据存储是最佳选择吗？ - user3376321
9
这取决于你所说的“很多人”的数量、你拥有的数据类型，以及你想做什么。
Cloud SQL是为需要SQL数据库的应用程序设计的，它可以处理任何在SQL中编写的查询，并确保你的数据始终处于一致的状态。
Cloud SQL可以提供高达3200个并发查询，这取决于层。如果查询简单且可以从RAM中提供服务，则只需要几毫秒，假设你的用户每秒发出1个请求，那么它可以支持数万个同时活跃的用户。但是，如果他们正在进行更复杂的查询（例如搜索）或写入大量数据，则会受到影响。
如果你有一个简单的查询集合，不太关心即时一致性，或者期望更多的流量，请考虑使用Datastore。
Cloud SQL是为需要SQL数据库的应用程序设计的，它可以处理任何在SQL中编写的查询，并确保你的数据始终处于一致的状态。
Cloud SQL可以提供高达3200个并发查询，这取决于层。如果查询简单且可以从RAM中提供服务，则只需要几毫秒，假设你的用户每秒发出1个请求，那么它可以支持数万个同时活跃的用户。但是，如果他们正在进行更复杂的查询（例如搜索）或写入大量数据，则会受到影响。
如果你有一个简单的查询集合，不太关心即时一致性，或者期望更多的流量，请考虑使用Datastore。
- Joe Faith
2
实际上，我的应用程序将为超过2百万人提供服务，并拥有约5万个实体。那么，您认为数据存储是最佳选择吗？ - user3376321
3随着数据量不断增大，像Datastore这样的分布式键值系统在速度和成本上越来越能够胜任SQL的工作。这不仅适用于AppEngine，还适用于Azure和其他云平台，你可以看看。如果你指的是每个人有50,000个实体的2百万人，那将是一千亿个实体，显然更适合使用Datastore。如果你指的是2百万人共享相同的50,000个实体，那么SQL是可行的，同时你可以使用Memcache来提高性能。但是，这时的Memcache更像Datastore而不是SQL。 - Martin Berends
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接