GAE Cloud SQL 和高复制数据存储答案

【问题标题】：GAE Cloud SQL and High Replication DatastoreGAE Cloud SQL 和高复制数据存储
【发布时间】：2012-03-14 19:19:06
【问题描述】：

使用 HRD 和 BigTable，您必须处理所有非祖先查询的最终一致性。您的代码必须足够健壮，以应对结果可能过时的事实。

随着 Google 推出 Cloud SQL，他们提出了免责声明：(https://developers.google.com/cloud-sql/faq#hrapps)

"We recommend that you use Google Cloud SQL with 
High Replication App Engine applications. While you can use use 
Google Cloud SQL with applications that 
do not use high replication, doing so might impact performance."

这是什么意思？这是否意味着将 SQL 与 HRD 结合使用会出现相同的最终一致性问题？ SQL 中没有实体组的概念，但这是否意味着特定情况下的特定 SQL 查询会提供陈旧的结果？

这意味着 Google 实施的 SQL 原子交易合约将被破坏，SQL 将无法像关系数据库用户所期望的那样运行。如果不是这种情况，使用 SQL 的主/从或 HRD 模型有什么问题？为什么 Google 会让您选择性能较差的模型？

【问题讨论】：

标签： sql google-app-engine cloud bigtable

【解决方案1】：

（来自论坛）

Cloud SQL 和数据存储系统是独立的。您可以根据自己的应用使用一种或两种方式。

我们建议使用 HRD 应用，因为该类型的应用将与 Cloud SQL 共存。主从应用程序由一组不同的数据中心提供服务，其中云 sql 不存在。它会起作用，但会慢一些。

【讨论】：

【解决方案2】：

文档引用：

“简单地说，Google Cloud SQL 是一个驻留在云端的 MySQL 实例。它具有 MySQL 的所有能力和功能”

为了回答您的问题，关系数据库的高复制/主从选项与一致性无关，而是与其他因素有关，例如峰值负载时的延迟和计划维护时的写入可用性。对于高复制数据存储，即使负载达到峰值，延迟也很低，并且即使在计划维护时它们也可用于写入。在http://code.google.com/appengine/docs/java/datastore/hr/查看比较

问题的第二部分是关于为什么谷歌会提供一个不完全证明的主从选项。答案是让不需要完整正常运行时间并想尝试 GAE 的人可以使用它。

【讨论】：

感谢您的回复。非常感激。就个人而言，我认为如果 SQL HRD 的唯一缺点是同步写入期间写入时间稍慢，那么不关心维护停机时间的普通用户也不会关心写入速度稍慢。我认为 Google 最好删除主/从选项，因为即使该决定也会引起混乱。
如果你认为答案是你想要的，你可以投票/标记为正确答案:)
如果您可以确认我对我的评论的直觉是有道理的，那么我会将答案标记为正确，或者，您能否突出显示保留主/从选项的其他案例？（抱歉，没有足够的声望点来投票给答案。:-( )
主/从仍然是一个选项的主要原因是支持仍然使用它的旧应用程序代码。正如您所指出的，M/S 与 HR 具有不同的一致性保证，因此迁移到后者有时需要仔细考虑代码，并且不能自动完成。强烈建议所有新应用程序的开发人员使用 HR 数据存储，这就是为什么它是新应用程序的默认设置，也是 Python 2.7 和 Go 运行时环境等新功能所必需的原因。
嗨，丹。您的回答解释了为什么 BigTable 旧版应用程序需要 M/S，但没有解释为什么 SQL 旧版需要它，因为 SQL 似乎没有一致性问题？？？