旨在轻松迁移到 Google App Engine

Question

我将很快开始设计一个 Web 应用程序，虽然我在 SQL 领域拥有丰富的经验，但我不知道为了迁移到 GAE 需要考虑什么不久的将来。

或者，我可以从一开始就为 GAE 设计应用程序，那么在这种情况下，我需要考虑哪些差异？换句话说，为 GAE 编写应用程序的 DO 和 DONT 是什么，来自过去的关系数据库。

Answer 1

就在我的脑海中：

• 它实际上只是一个键->值存储，不要被 GQL 之类的东西所迷惑（这只是 SQL SELECT 的一个子集）
• 没有 JOIN - 通常你必须去规范化或忘记
• 或多或少的超时
• （非常）与本地 SQL 库相比访问速度较慢。
• COUNT 非常昂贵
• OFFSET（在 SELECT 中）在客户端实现 - 所以实际上你获取所有记录直到 offset - 正如 Nick Johnson 在其中一个 cmets 中指出的那样，它不是客户端，所以现在，作为 LIMIT 1000 没了，类似于 SQL 数据库。
• （最近删除）LIMIT of 1000 fetched rows
• SELECT 性能随着返回行数的增加而急剧下降
• 迁移很难进行，因为您必须使用普通的 http 请求进行迁移，并且每个请求都会在 30 秒后被终止。您必须求助于批量处理行的任务队列
• 存在伪外键 - 在 Python API 中称为 ReferenceProperties - 但它们不会以任何方式强制执行 - 如果某人/某物删除目标对象，那么您就有了 C++ 中所谓的悬空指针
• 您用于查询的字段必须被索引，但仍然使用 key（每行/实例的主键排序）可以让您的查询运行得更快
• 在实时实例上构建索引可能会花费大量时间（而且您无法减少时间），如果没有它们，您的应用程序通常无法运行。强烈推荐啤酒和耐心..
• 大量人为限制（例如已删除的最大 LIMIT 1000）。例如。 GQL 'IN' 运算符只是多个 OR-s 的语法糖，使用的值上限为 30 个。

这意味着您可能无法避免将不一致的状态暴露给用户，并且几乎可以肯定您无法避免数据的不一致状态（例如，在手动 JOIN 数据更改期间迁移了一半的行，而另一半没有迁移）