GAE云SQL和高复制数据存储

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

随着谷歌推出云SQL，他们加入了一个免责声明：（）

这是什么意思？这是否意味着使用SQL和HRD最终会出现相同的一致性问题？SQL中没有实体组的概念，但这是否意味着特定环境中的特定SQL查询会产生过时的结果

这意味着谷歌对SQL原子事务契约的实现将被打破，SQL将无法像关系数据库用户所期望的那样发挥作用。

---

如果不是这样，那么使用SQL的主/从或HRD模型有什么问题？为什么Google会让您选择性能较差的模型？

引用文档：

“简单地说，Google Cloud SQL是一个生活在云中的MySQL实例。它拥有MySQL的所有功能和功能”

为了回答您的问题，关系数据库的高复制/主从选项与一致性无关，而是与其他因素有关，如峰值负载时的延迟和有计划维护时的写入可用性。对于高复制数据存储，即使出现负载峰值，延迟也很低，即使有维护计划，它们也可用于写入。检查以下位置的比较：

问题的第二部分是为什么谷歌会提供一个主从式的选择，而这并不是充分的证据。答案是，那个些不需要完全正常运行时间并想尝试GAE的人可以使用它

（来自论坛）

云SQL和数据存储系统是独立的。您可以根据自己的应用程序使用其中一个或两个

---

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

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

"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."