推荐学习书目
› Python Cookbook
› Using Google App Engine
推荐下载
› Latest Google App Engine SDK
其他兼容技术
› AppScale
这是一个创建于 4737 天前的主题，其中的信息可能已经有所发展或是发生改变。
在使用了 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 绝对不是最好的选择。
原因是：
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 绝对不是最好的选择。
 |
1
kimcool 2011-12-08 17:20:43 +08:00
好吧，越来越不靠谱，越来越云了。
|
 |
2
caiwangqin 2011-12-08 17:23:22 +08:00
wow, this is a bad news!
|
 |
3
zxsky1 2011-12-08 17:27:07 +08:00
希望PB3可以找到更好的技术方案，愿意每月付月费使用V2EX。
BTW，Things的Cloud Sync发布了么，花儿都谢了，都开始Things+iCal+提醒事项+iCloud同步手机端的todolist了。 |
 |
4
khaost 2011-12-08 17:27:30 +08:00
Google 各团队近期一系列的决策都有点难以让人理解.
|
 |
5
Livid MOD OP @zxsky1 已经 Beta 了，跑在 https://things-sync.appspot.com/ 上。
|
 |
7
CoX 2011-12-08 17:43:09 +08:00
GAE 现在就是玩玩python可以，真正做应用的话，确实不太合适
|
 |
9
santa 2011-12-08 18:10:13 +08:00
weird new pricing model, any ETA for PB3?
|
 |
10
fanzeyi 2011-12-08 18:23:05 +08:00
期待PB3 @@
更期待的是 将来的各种 V2EX 服务.. Workspace 只是一个开始 @.@ |
 |
11
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 来优化也是扯淡。 |
 |
12
sayori 2011-12-08 19:01:56 +08:00
各公司的疯狂估计目的只有一个：船票
|
 |
13
alexzhan 2011-12-08 19:03:24 +08:00
弱弱的问下：datastore上的数据能比较有格式地下载下来吗？
|
 |
14
kirakira 2011-12-08 19:19:45 +08:00
眼花看成 《为什么 PB3 将会继续跑在 GAE 上》 顿时心里凉了一下 T^T 虚惊一场
|
 |
15
miao 2011-12-08 19:22:11 +08:00
支持
|
 |
16
jckwei 2011-12-08 19:23:38 +08:00
零星项目继续使用SAE。
|
 |
17
kingwkb 2011-12-08 19:33:30 +08:00
一直都不建议使用GAE，因为他是不可被替换的，他说怎么样就怎么样，谁也未知不了未来，还是用可替换的服务好
|
 |
19
NemoAlex 2011-12-08 20:03:02 +08:00
目前 V2EX 一些新帖子的点击数显示不够实时，有些都已经n多回复了才“1次点击”
是更改了缓存机制的原因？ |
 |
20
freefcw 2011-12-08 20:14:31 +08:00
我也觉得读取次数收费很诡异……真不知道gae的人是怎么想的
|
 |
21
cyberscorpio 2011-12-08 22:40:07 +08:00
先 re 再看，最喜欢看这种八卦的文章乐！
|
|
22
cyberscorpio 2011-12-08 22:44:35 +08:00
都是佩奇上台惹得祸啊。
|
 |
23
ooxcoo 2011-12-08 23:30:29 +08:00
wow, this is a good news!
|
 |
24
mxfli 2011-12-08 23:49:02 +08:00
VPS + PB3（或其它易用靠谱的产品），流量大的再加上CDN，这才是方向。
|
 |
25
virushuo 2011-12-09 00:59:59 +08:00
aws+linode才是比较好的解决方案。
|
 |
26
bruceliu 2011-12-09 17:02:18 +08:00
还想知道 pb3的技术方案 如果可能我愿意参加进来。
|
 |
27
jyoe 2012-04-09 09:20:48 +08:00
如果要收费的话 Amazon的EC2 会是首选吧
|
 |
28
douyingxin 2012-04-09 20:12:33 +08:00
盛大云软文
|
 |
29
amom 2012-04-09 21:32:54 +08:00
@douyingxin 盛大云没开张多久就大大提高收费，把一群白高兴了许久的IT民工们气个半死。如此做法，不提也罢
|
 |
30
SR1 2012-04-09 21:44:37 +08:00
我很好奇GoAgent会因此受影响么，理论上应该不会吧
|
|
31
Livid MOD OP |
 |
33
yegle 2014-12-28 11:48:00 +08:00 via Android
哦对了，其实@livid你对datastore的认识是有误的，正确的设计思路是把一个用户所有相关的内容放在一个kind下，保证可以用一次datastore read来读取所有用户相关数据。datastore是nosql，所以不需要用数据库的方式存储数据，该冗余的要冗余。
|
|
34
yegle 2014-12-28 11:50:53 +08:00 via Android
保存数据是需要write操作，但是多个write操作可以batch到一起（比如从memcache里缓存数据通过taskqueue写入datastore）然后一次性写入，这样收费是一次。
还有一些冷门的优化方案… |
|
36
yegle 2014-12-30 01:00:41 +08:00
@Livid
可汗学院（Kham Acadamy）在用GAE，如果能找到他们网站的repo可以参考一下，刚才找了一下没找到 另一个就是 codereview.appspot.com 了，GvR当年在Google的时候写的 |
|
37
yegle 2014-12-30 01:06:15 +08:00
@Livid 哦对了，说起来原贴是很久前写的，但是现在回过头看，像AppEngine Datastore这样带高可用NoSQL方案，业界流行做法是按照读写数进行收费，或者是很高的月费。参考 https://addons.heroku.com/ Data Stores部分
|
 |
38
gancl 2015-12-26 14:49:44 +08:00
pb3 现在是没开源对吗？
|
Select Language