GAE 用的算是 Hierarchical Database，记得十多年前念大学时听过，这 些年来还真的是第一次碰到，到现在还在找书交怎麽设计资料结构较好 GAE 这样设计的好处是，在同一个子树(Entity Group)下，可以保证每秒 最少可以有五次的写入，跟上百次的读取；此外，lock住一个子树，并不 会影响到另一个树的存取。 最後你说cron job的问题， GAE datastore在设计上，就不是拿来跑分析 报表用的，所有的统计相关的资料，该在写入时就更新。 再不然，就是把你 8xx个 Query改成用 Queue处理，拆成 8xx个独立的事 件，这样就不会超过 CPU的使用上限了。 GAE 的问题是，为了不知道会不会长大的软体，从第一天起就要开始为资 料跟程式结构，对流量做最佳化；这些额外的工作，是 startup该负担的吗？ ※ 引述《twck (twck)》之铭言： : 为了平衡报导，我也来说一下Google App Engine的缺点。XD : 对我来说，GAE有几项致命的缺点，之前网友的讨论里似乎没讲到。 : 先说一下GAE用的非关联性资料库，以下图片是盗用Ericsk上官林杰在COSCUP的简报： : http://farm3.static.flickr.com/2630/4177320925_9af5b354df_o.jpg : 一张图片就可以清楚明白关联跟非关联资料库的差别。 : 过去用关联性资料库久了，我一遇到GAE的非关联资料库时，一开始竟然搞不懂！ : 後来发现Google一开始用非关联资料库是有道理的，也拉开跟对手的竞争差距。 : 牺牲了资料库的体积（反正硬碟很便宜嘛），换来存取速度跟扩展规格的方便性。 : 所以对我来说，非关联资料库反而是优点，用顺手之後非常方便。 : Ericsk上官林杰演讲影片在： : https://www.youtube.com/watch?v=tUZKta19TnY : 再来盗用一张： : http://www.flickr.com/photos/kevin814/3587610731/sizes/o/ : CPU Time使用时间超过，除了改善程式码之外，花点小钱就可以解决，也不是大问题。 : http://farm5.static.flickr.com/4011/4177338277_7b4c7eea49_o.jpg : 以上图片是我GAE设定付费的画面，每项都可以自订预算。 : 没超过就不用付钱，用多少付多少，很合理。 : （我虽然启动付费机制，但是还没付到钱，显然网站不够热门XD） : 可以看到CPU使用时间是以美金1角为单位，花个1.6元美金预算就有很多可以用。 : 那真正致命的缺点是什麽？ : 变数不能超过1MB！ : 一般变数传递很少会超过1MB，但是过去当我在果子咖啡万楼噗聚活动时， : 想用GAE撷取那个在噗浪的万则留言，再用jQuery计算几层楼，回应至Blogger网站时， : 前几小时都正常，但过没多久就撷取的页面就超过1MB爆掉了。 : 只好另找其他空间摆我的Python程式码。 : 这个花钱也无法解除限制。 : 除了CPU Time限制，我发现其实还是有个CPU(API)使用率限制，如下图： : http://farm3.static.flickr.com/2661/4177360627_ec511f4d6d_o.jpg : 这是我帮BillyPan统计县市长选举搜寻笔数，总共54个候选人，16种搜寻条件， : 所以一下子就要去作864次查询、撷取关键字、存入资料库。 : 虽然我已经拆成11个cron分别去跑，但是可以看到一小时内跑第二轮就会爆掉。 : 在CPU Time还很少时，这个CPU(API)已经纷纷爆掉了。 : 这个也是用钱买不到的。 : 要等一小时过後才会恢复正常。 : 所以GAE的限制也不少啊，不过这跟租用其它虚拟主机同样会有CPU使用率的问题， : 但是GAE有详细的数据给你看，让你有机会调整。 : 很多虚拟主机业者并没提供这种详细数据，爆掉就网站停掉，EMAIL要你快交钱。 : 即使如此，Google还是很积极改善GAE，版本更新非常快速。 : 例如之前抓网页不能设Referer，这样像无名正妹相簿就没办法抓， : 後来新版本就提供Referer了！ : 之前也没提供主机收信功能，都是突然冒出一个新版本，突然提供新功能。 : 跟Google其它热门产品很相像。 : 所以我相信GAE的功能或是可以使用的工具会愈来愈齐全， : 让网站开发者可以专注创意的发想，用最快的方式达成目的。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 67.185.160.97 ※ 编辑: CPython 来自: 67.185.160.97 (12/12 12:08)