用于企业管理系统的 GAE DataStore 与 Google Cloud SQL答案

【问题标题】：GAE DataStore vs Google Cloud SQL for Enterprise Management Systems用于企业管理系统的 GAE DataStore 与 Google Cloud SQL
【发布时间】：2012-06-09 23:24:59
【问题描述】：

我正在构建一个使用 gae 的企业管理系统应用程序。我已经使用 gae 和数据存储构建了几个应用程序，但从来没有一个需要大量用户输入事务以及需要管理和管理报告的应用程序。我最大的担心是，当我需要创建交叉表和其他详细报告（或商业智能报告和数据操作）时，我将面临 gae 的数据存储查询和数据拉取限制的大量问题。这真的只是架构偏好还是这里有数量问题？

过去，我曾使用 C++/c#/Java 针对 Oracle/MySql/MSSql 构建系统（在复杂或经常访问的数据库结果中添加了一个缓存层以提高性能）。

我一直在读到，我们要抛弃关系数据的旧心态，转向空中大 McHashTable 的新世界……但新世界并不总是更好……任何关于上述内容的见解或经验都会乐于助人。

【问题讨论】：

关系模型已经证明自己非常有用，但是现有产品无法在互联网规模上提供它，这就是为什么我们有很多不同的解决方案来解决它们自己的问题。 NuoDB 是一个有趣且有前途的“NewDB”数据库示例。在我们等待的时候，人们倾向于为他们的特定用例组合解决方案，将数据复制到单独的数据库以进行查询和报告，在 rdbms 前面使用 gigaspaces 等等。

标签： google-app-engine google-cloud-datastore google-cloud-sql

【解决方案1】：

来自Cloud SQL FAQ：

我应该使用 Google Cloud SQL 还是 App Engine 数据存储区？

这取决于应用程序的要求。 Datastore 提供高度可扩展的 NoSQL 键值 > 存储，但不支持 SQL 数据库提供的复杂查询。 Cloud SQL 支持复杂的查询和 ACID 事务，但这意味着数据库充当“固定管道”并且性能的可扩展性较差。许多应用程序同时使用这两种类型的存储。

如果您需要对带有分布式密钥的 db 实体进行大量写入（每秒约 XXX 次），那么这就是 Google App Engine 数据存储区真正发挥作用的地方。

如果您需要支持复杂且随机的用户制作的查询，那么 Google Cloud SQL 会更方便。

【讨论】：

在这种情况下，听起来两者的结合可能是最好的。也许我可以把事情分成两个阶段。我可以将数据存储用作 OLTP 的应用程序接口，然后通过异步队列或 cron 作业将该数据迁移到 OLAP 的云 sql。存在数据重复，但我可以利用迁移活动作为一个机会，在写入更规范化的状态之前转换代码本身中的数据，并从数据存储端清理“陈旧”数据....啊，我刚刚为之创建的工作我自己...
我实际上只是遇到了这个问题，这对我之前的评论有一定的影响。 stackoverflow.com/a/1711757/525541
如果数据量很大，也可以考虑使用Big Query developers.google.com/bigquery，更适合对大量导入数据进行操作。
谢谢，太好了。这让我有点想知道什么是正确的工具（OLTP = 数据存储，OLAP = Google Cloud SQL）或（OLTP = Google Cloud SQL，OLAP = BigQuery）......无论如何，我认为最好我会请参阅使用数据存储的 OLTP，使用 GCSQL 进行日常查询/报告，并在报告窃取一些海量数据（例如借记/贷记交易数据）时进行大量查询...

【解决方案2】：

在 GAE 数据存储中更让我害怕的是索引数限制。例如，如果您需要按某个字段搜索或排序 - 您需要 +1 索引。总共可以有 200 个索引。如果您有具有 10 个可搜索字段的实体，并且您可以按任何字段排序 - 将有大约 100 个组合。所以你需要 100 个索引。我为 gae 开发了几个小项目——这就是成功案例。但是当大人物来临时 - 这不是为了 gae。

关于缓存——你可以用 gae 来做，但是他们的分布式缓存工作很慢。我更喜欢使用 RESTfull API 创建永久后端的私有单个实例，该 API 将缓存值保存在内存中。前端实例调用此 API 来获取/设置值。

也许用 gae 构建复杂的系统是可能的，但这将是一组小型应用程序/服务。

【讨论】：

如本文developers.google.com/appengine/articles/indexselection 中所述，新的高级查询计划器可以通过在单个属性索引上使用锯齿形合并连接而不是昂贵的复合索引组合来大大减少复杂查询的索引数量。
是的，已经读过了。在限制方面有很大的不同。
是的，我已经阅读了它，但仍然通过提供的公式，如果您按 10 个字段中的 1 个进行搜索并按 10 个字段中的 1 个进行排序，您将获得相同的大约 100 个索引。因此，如果您的项目中很少有这样的实体 - 是的，gae 可能就是其中之一。但有些项目包含大量此类实体。所以我仍然在我的立场上 - 带有数据存储的 gae 非常适合小型项目。如果你通过小项目分发它，你可以使用 gae 构建一些巨大的东西。
索引限制即将取消（已发布公告）。 DS 查询的费用也在发生变化，对于大多数用户来说可能会下降