gpt4 book ai didi

python - 旨在轻松迁移到 Google App Engine

转载 作者:太空狗 更新时间:2023-10-29 23:56:16 25 4
gpt4 key购买 nike

我很快就会开始设计一个网络应用程序,虽然我在 SQL 领域有很多经验,但我不知道为了迁移到 GAE 而需要考虑什么在不久的将来。

或者,我可以从一开始就为 GAE 设计应用程序,那么在这种情况下,我需要考虑哪些差异?换句话说,从过去的关系数据库中,为 GAE 编写应用程序的注意事项是什么。

最佳答案

就在我的脑海里:

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

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

关于python - 旨在轻松迁移到 Google App Engine,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2365647/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com