1
phus 2011-09-06 12:07:42 +08:00
看来Python 2.7值得期待的。
|
2
fcicq 2011-09-06 16:52:35 +08:00
GAE/Java or Go 没有特别大的参考价值. 楼主也没有说上面跑的什么样的 load. 依赖 db 和 urlfetch 的应用还是赶紧搬走的好, 无论是 HRD 还是 Master-Slave.
|
3
Livid MOD 新的定价模型里最可怕的是按照 datastore 的读写次数进行收费。
幸好 Google 还没有变态到按照 memcache 的读写次数收费。 |
4
keakon 2011-09-06 17:54:58 +08:00
@Livid 准确来说不是datastore的读写次数,而是entity、key和index的读写次数。
假如打开V2EX首页显示20篇文章,那么需要20篇文章+20用户信息=40次entity fetch。别忘了还有节点,每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。 而在文章页,每篇回复也包含用户信息,因此相当于2次entity fetch。 而免费配额是每天5万次Datastore Reads操作,即使使用memcache,也只有访问量很小的站才能不超过这个配额。 |
6
darcy 2011-09-06 17:57:14 +08:00
谷歌越来越小气,先是关掉一大堆东西,再是减少配额提高价格,原来免费的变成收费,收费的改变计费方式。
|
8
jeeson OP @keakon @Livid @fcicq datastore 部分我没优化. 我的Java应用是通过Objectify来操作datastore, Objectify内置了cache支持, 只要在class前加上 @cache 就可以对该对象的实例进行cache(读), 可以通过Filter实现异步cache (写)
@keakon "假如打开V2EX首页显示20篇文章,那么需要20篇文章+20用户信息=40次entity fetch。别忘了还有节点,每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。" v2ex 如果使用Memcache, cache命中率应该会很高. 比如, 最新的n条回复都保存在Memcache中, 这样可以大大降低读操作. 而datastore的写操作, 主要是计数器, 可以用异步批量写入. |
9
fcicq 2011-09-06 18:54:47 +08:00
100% 命中率又如何? 命中率高不能掩盖高价的事实.
咱看看 EBS 的 pricing. $0.10 per 1 million IO, 虽然偶觉得这已经很高了. GAE: $0.01 / 10k operations. IO 与 operations 的比例比较说明问题. 虽然 GAE 是 HRD, 但并不意味着就可以收 n 倍的钱. 熟悉 MySQL 的同学应该知道 show status 显示什么, 自己换算一下会很吓人的. |
10
jckwei 2011-09-07 08:25:57 +08:00
@keakon 早期,看过V2EX的代码后,感觉很浪费GAE资源,因为又特别喜欢这种形式,就仿着做了一个GAE-BBS,虽然GAE读比写快、省很多,但还是尽量减少读,如同说过的V2EX读一个帖子需要 读帖子+用户+用户头像(头像还有三种尺寸),设计时就把用户和头像省掉,只需读取一次帖子信息。但要花费一些空间来存储,每个帖子估计多出50-80个字节(包含Metadata)。
希望免费下能承载更多。 使用了你早期的YUI,很好用。 |
12
keakon 2011-09-07 09:59:35 +08:00
|
13
lfeng 2011-09-07 10:20:17 +08:00
@keakon 改进缓存策略和算法,可以提升到80%-90%,memcache本身的作用就只是数据缓存(或者说活跃数据)来减小数据库读写压力,虽然有一些持久化的项目,但那些项目现在看实际也是一种NoSQL的实现。
P.S 我觉得你想法,太过极端了。。。。 |
14
jeeson OP @keakon 我还没有做过这些优化, 也没试验验证过, 以下只是推测
首先, 如果可以按最高使用频率来cache, 肯定比常规FIFO方式更合适, 而这个恰恰在v2ex具备条件(推测). 比如, cache最新的n条回复, 以及最新回复的n位用户. 然后, 只在发生写操作时cache (用户发帖子/回复的时候, 不包括计数器之类的操作), cache该用户信息和发帖/回复信息. (初始加载时, 可能需要加载最新的n条信息) "一是memcache随时有可能丢失数据;二是有些数据不能把缓存时间设得太长;三是一旦有更新,很多缓存必须删除。" 一,二点同意, 选择合适的cache规模应该可以克服 =============================== 假如, datastore访问是通过get, put, 那只要在put时, 顺便放入cache, get时先检查cache 如果是通过query然后逐条读取, 或者批量读写, Python我不了解, Java/Objectify因为在中间架了一层, 所以所有操作都支持cache GAE/Java 因为原生数据接口非常不方便, 效率底下, 所以有许多第三方的接口: http://blog.cogipard.org/articles/tag/datastore (可能要翻墙访问) |
15
jckwei 2011-09-07 10:55:10 +08:00
|
16
keakon 2011-09-07 12:28:53 +08:00
@jeeson @lfeng 我觉得你们还是看看Billing History里的Datastore Reads再辩驳吧。
前面我已经说过了,我几乎对所有的数据库访问都做了缓存,这点你可以在我博客的源码里看到,有遗漏的你可以指出。 昨晚我对所有的数据库访问都进行了记录,并将获取超过5个实体的请求用warning标记出来。在后台可以看到最近5分22秒内有20个这样的请求,共计178个实体。其中所有请求的URL都不相同,获取的数据也都不相同,并且我都做过缓存但没有命中。这都是由访问者决定的,我不可能只让他们访问已经缓存的页面。 虽然1个PV可能会有1~3个动态请求,不过我就按1个来算,最多也只有20PV,因此理论上来说5万/天的配额只能支持到5600PV。考虑到少于5个实体的请求我没记录,实际情况只会更少。 至于最开始时,Google承诺的是免费配额可以支持每月500万PV,相差将近30倍。 顺便提醒一下,count操作虽然只返回一个整数,但也算多次key fetch。所以如果你的实体超过50000,然后执行count(50000),你会发现Small Datastore Operations配额已经用完了,而这花不了几秒… |