这是一个创建于 5088 天前的主题，其中的信息可能已经有所发展或是发生改变。
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.
当你的程序要写入新数据的时候，为了能够以最环保的方式使用 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.
 | 1 keakon 2011-11-07 00:59:23 +08:00 异步或是缓存html片段都不会对datastore的read、write数目造成影响，只有缓存的命中率才有影响。而对于小应用，memcache非常不可靠。你做任何代码上的优化，都不如访问量提升来得明显。 那些老外都没看透这点，只有Google的一个员工在我发的那帖中提到了，其他人都是想着法子弄些奇怪的方式来实现。 比如有个人说获取文章时，为了避免访问的实体过多，直接把评论和用户也保存在一个实体里。 而对于节点的信息，也可以把所有节点保存在一个实体里。 他这样做后可以在免费配额内达到500万PV，也就是每10个页面才获取1个实体，很显然memcache命中率至少得90%，这对于小应用来说是天方夜谭。 而实现也特别麻烦，如果实体大于1M还得分成多个实体，搜索和删除的时候非常痛苦。 GAE曾经是个很好的平台，因为只需要考虑CPU，只要设计得合理就没问题。而现在变成必须使用非正常、奇葩或是麻烦的设计，把datastore的ORM能大幅简化设计和编码优势给丧失了。 我宁愿把CPU的价格提升10倍，也不想为新价格去做恶心的设计。 顺带一提，现在支持mysql了，而且免费。不过我估计迟早会变成datastore那样按条数来收费的，count(*)一下就去掉几刀了。 |
 | 2 hq5261984 2011-11-07 01:02:36 +08:00 或者改用SAE。 |
 | 3 dreampuf 2011-11-07 03:13:49 +08:00 你不觉得这样下去的memcache会夺了database的事儿吗? 我的意思是,价值政策导致我们将缓存当作数据库用.只是因为他看上去廉价. |
 | 4 Livid MOD OP PRO @dreampuf 以前，对于小应用，memcache 是一个可有可无的东西。 而现在 Google 通过调整价格和调整 free quota，迫使即使每天只有几千 PV 的小型动态应用都要考虑一些复杂的优化方式。 这其中的方式之一就是如我文章中所述，每次新数据写入时，你需要花费脑力去思考如何修改 memcache 中的内容，确实是把 memcache 当 k-v 数据库用，datastore 只是作为一个昂贵的持久层了。 适应了的人或许会觉得爽和赚到，但是目前似乎世界上还是不适应的人更多。 |
 | 5 saga 2011-11-07 07:59:11 +08:00 我的一些优化心得 1）datastore read以及small datastore read很恶心，为此不得不删掉以前无用的历史数据，这个对于论坛类比较麻烦，可以用urlfetch另一个数据库作为dirty solution，但是大数据量很难不花钱。 2）memcache有失效问题，不得不加入datastore的检查作为get_and_insert的矫正，光依赖memcache是不行的，实际上appengine文档也提到了失效问题，所以不能完全依赖它 3）现在看来urlfetch花钱不多，可以用来做点文章，一般来说完全的appengine不太可能，大多有个vps或者什么的辅助服务，可以考虑用RPC方案做一些非紧要数据方面的工作，然后缓存以下 现在看appengine日访问几千的非数据写频繁的应用，免费quota是足够用的。 |
| 6 keakon 2011-11-07 11:41:28 +08:00 @saga 我目前每天超过10000的动态请求，每月将近20万PV（根据CloudFlare统计），访问量再大1/4就超出配额了。而如果采用以前的计费方式，可以增大20倍，考虑到memcache会更有效，达到最初宣称的500万pv/月毫无压力。 我这几个月所做的优化，我确信并没有多少能帮助提高memcache命中率的，但是却从49%增加到61%了，唯一能想到的原因就是访问量增大了不少。 |
 | 7 daqing 2011-11-07 12:20:29 +08:00 为了新价格模型，浪费脑力去搞一些复杂的hack, 到底是节约了成本，还是增加了成本？把时间考虑在内的话，恐怕是增加了成本吧，而且这样写代码，可维护性是个问题。 |
| 8 dreampuf 2011-11-07 15:35:14 +08:00 @Livid 一个Model被几个View引用,在数据库中,我们只需要对一个Model修改. 而在Memcache中的View Model则随着每个Model的修改都要进行修改,于是我们开始尝试维护View Model的关系,于是开始有一对一,一对多.随着开发页面越来越多,关系也越复杂,工作量也越大. 我们干的难道不应该是数据库应该干的事么? |
| 9 keakon 2011-11-07 18:47:37 +08:00 更正前面说错的一点。免费配额是每天5万read，所以memcache命中率得高于99%。 |
 | 10 bhuztez 2011-11-07 19:29:54 +08:00 更新的时候直接修改memcache里的HTML是不靠谱的 |
 | 11 jckwei 2011-11-07 20:01:54 +08:00 这回可以好好看不花钱能做多大的事。 |
| 12 Livid MOD OP PRO 刚才想到另外一件事，考虑到在新的免费配额下 read 和 write 的量，再用 MapReduce 来处理数据的话，简直就是自杀啊。 |
| 13 Livid MOD OP PRO |
| 14 Livid MOD OP PRO |
| 15 Livid MOD OP PRO 如果我没记错的话，Things 的云同步也是基于 Google App Engine。 |
 | 16 SamuelBinYE 2011-12-03 10:16:30 +08:00 把 project babel 联系到 GAE 的价格体系 我承认以上所有 jargon 都看不懂 由于 VPN 时好时坏 我只能停留在 Mail&blogging 反正也只是个人博客 没有太多技术期望值 |
Select Language