3

我有我的第一个应用程序，不是那么大，但这是第一步。（下一个大的在路上）

现在，如果我想把它放在我自己的 Linode VPS 上，我必须配置mod_python or mod_wsgi,memcache、Ngix、mySQL 或 Postgresql 等才能使其工作。如果我把它称为 GAE，我所要做的就是将模型转换为使用 GAE 的 API。

我喜欢 GAE 的地方在于扩展。（如果他们真的能做到）

然后我只担心开发我的应用程序并对其进行 SEO 工作，而不是担心负载共享/平衡、缓存、db / IO 冗余等。

我不想以后做任何移植。（我现在必须决定并坚持下去）

所以，如果你有这方面的经验，你有什么建议：

1- Use VPS(s) for everthing
2- Use VPS(s) plus Amazon S3
3- Use VPS(s) plus Amazon S3 & SimpleDB
4- Use GAE

另外：在使用 BigTable 时，我是否能够摆脱没有 JOIN 权限的情况？

注意：我现在没有任何空间需求，但是对于位置表，我以后可能需要它。

我想知道你怎么看！

4

6 回答 6

3

存在业务风险和技术风险。

业务风险是您可能必须稍后出于某些外部原因移动主机。VPS、EC2 等需要更多的前期投资，但要保持独立。Chef之类的工具可以帮助完成配置工作。

技术风险是您的应用程序可能无法在平台上轻松实现。由于大多数 VPS 选项允许您安装任意软件，因此它们将这种情况最小化，同样以您付出更多配置工作为代价。AFAIK，GAE 对您施加的最大限制是很难执行长时间运行的后台任务。（在没有 JOIN 和非规范化数据的其他方面的情况下工作需要不同的思维方式，但这种方法在 Web 应用程序中相当普遍，无论它们在哪里运行，一旦 SQL 数据库大于单个主机可以支持。）

如果您能够承受这两种风险，GAE 似乎可以为您节省大量精力。如果您不能忍受这些风险，您应该定制自己的环境。

顺便说一句，无论您的环境如何，我发现 S3 都是值得的。这比确保可靠地备份本地服务器静态文件存储要简单得多，而且您永远不必担心容量问题。最好将它用于上传但很少被覆盖或删除的数据（想想 facebook 相册）。

于 2009-06-05T03:51:35.603 回答
2

我不想以后做任何移植。（我现在必须决定并坚持下去）

如果是这种情况，您不是更愿意从一开始就控制部署吗？如果您达到其限制（无论是技术限制还是谷歌的商业决策与您对应用程序未来的计划背道而驰），稍后从 GAE移植回来可能会非常痛苦。

此外，配置 mod_wsgi、安装 postgres 等也不是特别困难，而且您暂时不必担心负载平衡和数据库冗余之类的事情。

如果是我，我更喜欢传统服务器的长期确定性，而不是 GAE 的快速获胜。然而，这一切都取决于您对应用程序的愿景。

于 2009-06-05T03:14:39.593 回答
1

我可能有偏见，但如果你能忍受 GAE 的限制，它确实可以为你节省大量工作并担心系统管理问题（以及在一定程度上扩展）——另外，只要你的资源消耗低（基本上意味着您的流量很低）。

你可以不加入吗？我不知道，因为我不知道你的应用程序——我自己是一个 SQL 狂热者，但对于足够简单的需求，我发现它并不难适应。正如我所看到的，非关系数据库的主要限制是它们在“临时”查询中不如关系数据库好......您通常必须编写大量程序代码而不是一个或两个不错的 SELECT :-(。但是，这更像是一个“稍后进行数据挖掘”的问题，而不是与为您的 Web 应用程序服务相关的问题——最好的解决办法是定期从 Web 应用程序的在线存储中批量下载数据到“数据仓库”类型的设置，无论如何，即使这种存储首先是关系型的；-)。

于 2009-06-05T01:59:12.413 回答
1

在决定之前，可能值得快速将您的应用程序原型改编为 GAE。你可能会遇到迫使决定的塞子。可能的塞子问题包括

  • 您的架构没有过渡到 BigTable
  • 您依赖于 GAE 不支持的一些基于 C 的库
  • 您有一些长时间运行的请求超过了 GAE 施加的阈值
于 2009-06-05T02:29:32.960 回答
0

答案实际上取决于模型层的复杂性和性质。如果它很复杂或与您的其余代码紧密绑定，那么移植可能是一项重大工作。如果它相当简单，或者很容易撕掉和更换，我会说去吧。

这些天来，我主要为 GAE 编写新代码，但我可以使用单个命令简单地部署这一事实确实降低了我编写酷炫新应用程序的障碍。不必担心部署和托管是相当解放的。

于 2009-06-05T03:22:11.637 回答
0

我所要做的就是将模型转换为使用 GAE 的 API。

对不起，你完全错了。

您还需要重写所有views使用 ORM 的代码。没有连接。因此，您必须处理和编写大量程序代码，而不是提供您想要的任何东西的漂亮 SQL。

查询很慢。您需要覆盖每个模型的保存方法来存储该模型的附加信息，这在需要时可能需要大量时间来计算。您还需要努力memcache使查询足够快。

然后，Guido 表示 Django 1.1 将包含在 Appengine 的未来版本中。我希望他们将有一个开箱即用的通用 ORM 到 BigTable 映射器。

也就是说，如果您的应用程序很简单，不需要很多连接，您可以使用 appengine 补丁项目在 Appengine 上使用当前版本的 django。这里是如何。

于 2009-06-05T15:10:45.917 回答