推荐下载
在使用了 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 绝对不是最好的选择。
Select Language