旨在轻松迁移到 Google App Engine

Question

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

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

Answer 1

就在我的脑海中：

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

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