为什么 PB3 将不会继续跑在 GAE 上

2011-12-08 17:17:25 +08:00
 Livid
在使用了 GAE 几年之后,我现在在想的是,未来我的所有新的网站项目,比如 Project Babel 的下一代——PB3,恐怕不会再选择使用 GAE。

原因是:

GAE 开始针对 datastore read/write 收费。

我很难理解为什么 GAE 的运营团队要做出这个新的收费决定,我能够想到的唯一一种导致他们做出这个疯狂决定的可能性就是:如果他们再不为公司制造利润,他们会像 Google Wave 一样被彻底关闭。

那么对 datastore read/write 收费会产生什么影响呢?

GAE 在 2011 年 11 月之前的旧收费模式,是一种非常容易理解的模式:假设你的每个页面请求渲染要花费 200 毫秒,也就是 0.2 秒,那么如果你一天要服务 10000 个页面,那么你会消耗的时间大约是 0.2 * 10000 也就是 2000 秒,而每天的免费时间是 6.5 个小时,也就是 23400 秒,理论上来说,足够服务超过 10 万个动态请求。如果你把免费的时间消耗完了,那么你可以额外花钱买更多的时间,而且非常便宜,差不多 10 美分就可以买到 3600 秒,也就是差不多 10000 个动态请求只需要花不到人民币一块钱就可以搞定。

而在新的收费模型下,除了按照时间收费之外(而且计算时间的方式也改变了),同时也会对 datastore 的读取和写入次数进行收费。价格差不多是每 100 万次读取 70 美分。而每天的免费额度是 50000 次读取。

而这带来了一系列严重冲击。

乍一看 50000 次读取不是个小数字,而 100 万次读取 70 美分也好像很便宜。但是实际上,这是一个疯狂的定价。

假设你在做的,是一个非常动态的网站,就比如说豆瓣或者人人,那么理论上,每个用户登录之后看到的首页,都是完全不同的。首页上充满了个性化的数据。而这个页面上的每一个元素,可能都意味着 1 次甚至更多的 datastore 读取。

GAE 在他们的优化指南中提出你尽可能将数据放入 memcache 来避免产生 datastore 操作,但是现实中有些情况真的是很难缓存的。比如豆瓣中最热门的那些小组,你每次刷新的时候,看到的主题列表都不一样,因为如果每秒都有人在发帖回帖的话,那么就算是你设计了缓存机制,那么实际上缓存下的主题列表页面的生命周期都是非常短的。而用户发帖意味着可能要更新 N 个地方的缓存和数据,比如:

* 小组的主题列表
* 用户自己的主页上的最近参与过的主题
* 如果是回复了别人的帖子,那么会产生相应的通知(数据写入)
* 小组本身的一些统计数据可能会需要更新(比如帖子量,最后活跃时间等等,都是数据写入)

所以你可以看到,一个简单的回帖动作,有可能会产生数十次 datastore 操作,而 50000 次 datastore 操作可能只够几十个用户玩一个小时就用完了。

OK,所以,就算是我准备好了足够的钱用于支付这些 datastore 的读写操作,你发现这个其中的一个问题了么?

那就是,GAE 的新定价,可能会阻碍到你去开发那些非常动态的及个人化的新功能,因为:

1. 一个非常动态的用户体验,意味着可能会非常贵。想想如果在 GAE 上跑一个像 Asana 那样的应用?

2. 省钱的一个方法可能是尽可能多的使用 memcache,但是如果你花在规划 memcache 上的时间比你实际开发新功能用的时间还多呢?

我不知道 Google 自己在开发 Google+ 的时候花了多少时间去规划 memcache,或许他们自己真的用的是这种极端性能优化编程方式。但是对于一个每天 PV 甚至都不超过 100 万的小网站来说,一开始就把大量时间花在 memcache 上,或者不考虑成本地在 GAE 上实现那些动态+实时的功能,在我看来都是疯了。

所以,结论?离开 GAE。

或许有一些需要大存储和高并发的应用依然可以继续受益于 GAE,比如 Things 的 Cloud Sync 和 Simplenote,但是如果你想做的是像 Asana,Quora,Facebook 那样的具有大量用户交互的网站,那么 GAE 绝对不是最好的选择。
9955 次点击
所在节点    Google App Engine
38 条回复
kimcool
2011-12-08 17:20:43 +08:00
好吧,越来越不靠谱,越来越云了。
caiwangqin
2011-12-08 17:23:22 +08:00
wow, this is a bad news!
zxsky1
2011-12-08 17:27:07 +08:00
希望PB3可以找到更好的技术方案,愿意每月付月费使用V2EX。

BTW,Things的Cloud Sync发布了么,花儿都谢了,都开始Things+iCal+提醒事项+iCloud同步手机端的todolist了。
khaost
2011-12-08 17:27:30 +08:00
Google 各团队近期一系列的决策都有点难以让人理解.
Livid
2011-12-08 17:31:05 +08:00
@zxsky1 已经 Beta 了,跑在 https://things-sync.appspot.com/ 上。
peterlu
2011-12-08 17:41:35 +08:00
@Livid 为啥不考虑aws呢?我们现在用aws用的非常爽。
CoX
2011-12-08 17:43:09 +08:00
GAE 现在就是玩玩python可以,真正做应用的话,确实不太合适
Livid
2011-12-08 17:43:53 +08:00
@peterlu V2EX Workspace 跑在 Linode 上,也非常爽。

这是接下来的方向。
santa
2011-12-08 18:10:13 +08:00
weird new pricing model, any ETA for PB3?
fanzeyi
2011-12-08 18:23:05 +08:00
期待PB3 @@

更期待的是 将来的各种 V2EX 服务.. Workspace 只是一个开始 @.@
88250
2011-12-08 18:54:55 +08:00
即使尽量从应用上面规划 memcache 使用也有问题:据目前观察,GAE/J 上面的 memcache 最多可缓存的大小和应用实例内存占用相关。

大概关系是最多使用内存的实例的内存使用量 + memcache 当前缓存使用量 大于 200M 时 memcache 会开始回收缓存,并且不是只回收一点点,而是基本将整个 memcache 清空。

对于 Java 应用来说,空实例启动内存基本就在 50M 了,随便写几个 Servlets 基本就玩完 200M 了,Memcache 形同虚设,基本没有什么命中可谈。

迫于无奈,改成本地缓存,设置实例配置(使其尽量不会产生多实例,减少本地缓存造成不一致的可能性),勉强维持在免费配额内。

问题是,本地缓存直接占用实例内存,这导致的问题是内存使用到上限(280M 左右?)实例将被直接干掉。继续观察,调整本地缓存上限容量。

这无限制地折腾下去,奔溃是迟早的事。所以,就像 @Livid 说的那样,目前 GAE 的计价模型非常不适合做动态网站,GAE 官网说用 memcache 来优化也是扯淡。
sayori
2011-12-08 19:01:56 +08:00
各公司的疯狂估计目的只有一个:船票
alexzhan
2011-12-08 19:03:24 +08:00
弱弱的问下:datastore上的数据能比较有格式地下载下来吗?
kirakira
2011-12-08 19:19:45 +08:00
眼花看成 《为什么 PB3 将会继续跑在 GAE 上》 顿时心里凉了一下 T^T 虚惊一场
miao
2011-12-08 19:22:11 +08:00
支持
jckwei
2011-12-08 19:23:38 +08:00
零星项目继续使用SAE。
kingwkb
2011-12-08 19:33:30 +08:00
一直都不建议使用GAE,因为他是不可被替换的,他说怎么样就怎么样,谁也未知不了未来,还是用可替换的服务好
linsk
2011-12-08 19:54:06 +08:00
@kingwkb 超级赞成。不可替代的服务后面就是压迫了
NemoAlex
2011-12-08 20:03:02 +08:00
目前 V2EX 一些新帖子的点击数显示不够实时,有些都已经n多回复了才“1次点击”
是更改了缓存机制的原因?
freefcw
2011-12-08 20:14:31 +08:00
我也觉得读取次数收费很诡异……真不知道gae的人是怎么想的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/23087

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX