关于新价格模型的一些新体会

[Livid]

GAE 即将上线新的定价模型。这个模型不完美，但是它带来了一些架构上的启发：

当你的程序要写入新数据的时候，为了能够以最环保的方式使用 GAE，你可能需要这样做：

1. 取出 memcache 中的 html 片段或是 serialized 的 object lists，然后将新对象的相关的 html 更改或者 serialized object 更改 append。
2. 写入 datastore（将来这部分应该就是一个 async api）。
3. 尽可能不要 memcache.delete 或是覆盖，而是 get，然后更新其中的部分内容，然后 set。

!!! 当用户使用的时候，直接读取 memcached 中的 rendered html 而不是取出一堆对象来交给 template 去 render。

如果以这种方式编程的话，你将可以从 GAE 中继续获得足够多的好处。但是：

* 这种编程方式可能不是大部分人的习惯（比如 async 数据写入），需要一段时间训练和适应。
* 你将会需要花非常多的时间思考关于如何取出并更改 memcached content 的那些操作，这是一种和目前的很多主流做法不一样的架构。
* 这样的方式开发新功能，一开始可能会有点慢。

这样做的话，即使是新的价格模型下，你在 free tier 依然可以支撑足够大的动态流量。

感谢 App Engine group 上的各位老外的热情回帖。

以上算是抛砖，希望能够和大家更多地讨论新价格模型下的挑战和启发。

cc @keakon :)

Whatever, a new era started.

[keakon]

异步或是缓存html片段都不会对datastore的read、write数目造成影响，只有缓存的命中率才有影响。而对于小应用，memcache非常不可靠。你做任何代码上的优化，都不如访问量提升来得明显。

那些老外都没看透这点，只有Google的一个员工在我发的那帖中提到了，其他人都是想着法子弄些奇怪的方式来实现。
比如有个人说获取文章时，为了避免访问的实体过多，直接把评论和用户也保存在一个实体里。
而对于节点的信息，也可以把所有节点保存在一个实体里。
他这样做后可以在免费配额内达到500万PV，也就是每10个页面才获取1个实体，很显然memcache命中率至少得90%，这对于小应用来说是天方夜谭。
而实现也特别麻烦，如果实体大于1M还得分成多个实体，搜索和删除的时候非常痛苦。

GAE曾经是个很好的平台，因为只需要考虑CPU，只要设计得合理就没问题。而现在变成必须使用非正常、奇葩或是麻烦的设计，把datastore的ORM能大幅简化设计和编码优势给丧失了。
我宁愿把CPU的价格提升10倍，也不想为新价格去做恶心的设计。

顺带一提，现在支持mysql了，而且免费。不过我估计迟早会变成datastore那样按条数来收费的，count(*)一下就去掉几刀了。

[hq5261984]

或者改用SAE。

[dreampuf]

你不觉得这样下去的memcache会夺了database的事儿吗?

我的意思是,价值政策导致我们将缓存当作数据库用.只是因为他看上去廉价.

[Livid]

@dreampuf 以前，对于小应用，memcache 是一个可有可无的东西。

而现在 Google 通过调整价格和调整 free quota，迫使即使每天只有几千 PV 的小型动态应用都要考虑一些复杂的优化方式。

这其中的方式之一就是如我文章中所述，每次新数据写入时，你需要花费脑力去思考如何修改 memcache 中的内容，确实是把 memcache 当 k-v 数据库用，datastore 只是作为一个昂贵的持久层了。

适应了的人或许会觉得爽和赚到，但是目前似乎世界上还是不适应的人更多。

[saga]

我的一些优化心得

1）datastore read以及small datastore read很恶心，为此不得不删掉以前无用的历史数据，这个对于论坛类比较麻烦，可以用urlfetch另一个数据库作为dirty solution，但是大数据量很难不花钱。

2）memcache有失效问题，不得不加入datastore的检查作为get_and_insert的矫正，光依赖memcache是不行的，实际上appengine文档也提到了失效问题，所以不能完全依赖它

3）现在看来urlfetch花钱不多，可以用来做点文章，一般来说完全的appengine不太可能，大多有个vps或者什么的辅助服务，可以考虑用RPC方案做一些非紧要数据方面的工作，然后缓存以下

现在看appengine日访问几千的非数据写频繁的应用，免费quota是足够用的。

[keakon]

@saga 我目前每天超过10000的动态请求，每月将近20万PV（根据CloudFlare统计），访问量再大1/4就超出配额了。而如果采用以前的计费方式，可以增大20倍，考虑到memcache会更有效，达到最初宣称的500万pv/月毫无压力。

我这几个月所做的优化，我确信并没有多少能帮助提高memcache命中率的，但是却从49%增加到61%了，唯一能想到的原因就是访问量增大了不少。

[daqing]

为了新价格模型，浪费脑力去搞一些复杂的hack, 到底是节约了成本，还是增加了成本？把时间考虑在内的话，恐怕是增加了成本吧，而且这样写代码，可维护性是个问题。

[dreampuf]

@Livid 一个Model被几个View引用,在数据库中,我们只需要对一个Model修改.

而在Memcache中的View Model则随着每个Model的修改都要进行修改,于是我们开始尝试维护View Model的关系,于是开始有一对一,一对多.随着开发页面越来越多,关系也越复杂,工作量也越大.

我们干的难道不应该是数据库应该干的事么?

[keakon]

更正前面说错的一点。免费配额是每天5万read，所以memcache命中率得高于99%。

[bhuztez]

更新的时候直接修改memcache里的HTML是不靠谱的

[jckwei]

这回可以好好看不花钱能做多大的事。

[Livid]

刚才想到另外一件事，考虑到在新的免费配额下 read 和 write 的量，再用 MapReduce 来处理数据的话，简直就是自杀啊。

[Livid]

另外就是，我实在很好奇这次 new pricing model 上线之后，对 Simplenote 的成本影响？

http://simple-note.appspot.com/

[Livid]

So I asked on Quora:

http://www.quora.com/What-does-GAE-new-pricing-model-mean-to-Simplenote

[Livid]

如果我没记错的话，Things 的云同步也是基于 Google App Engine。

[SamuelBinYE]

把 project babel 联系到 GAE 的价格体系
我承认以上所有 jargon 都看不懂
由于 VPN 时好时坏
我只能停留在 Mail&blogging
反正也只是个人博客
没有太多技术期望值