@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配额已经用完了，而这花不了几秒…

@jeeson @lfeng 高不了的…我几乎对所有的数据库访问加了缓存，目前的状态是Hit ratio: 55% (315327 hits and 254064 misses)。

一是memcache随时有可能丢失数据；二是有些数据不能把缓存时间设得太长；三是一旦有更新，很多缓存必须删除。

而且就算命中率是100%，以V2EX这1万多篇文章举例，搜索引擎爬个几千篇就没了…

@panlilu 据说因为产能不够，明年3月才能出

@Livid 准确来说不是datastore的读写次数，而是entity、key和index的读写次数。

假如打开V2EX首页显示20篇文章，那么需要20篇文章＋20用户信息＝40次entity fetch。别忘了还有节点，每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。

而在文章页，每篇回复也包含用户信息，因此相当于2次entity fetch。

而免费配额是每天5万次Datastore Reads操作，即使使用memcache，也只有访问量很小的站才能不超过这个配额。

Flipboard、网易阅读、ZAKER和昨天出的中文摄影杂志 for iPad也是这种色调，感觉最早采用的应该是Reeder吧。

这个例子应该可以直接用inner join吧…

不到万不得已不用子查询

居然没被墙

@kingrever 大概就这样吧：
Message.filter('direct_to =', current_user)
Message.filter('sender IN', current_user.follower).filter('status =', 'public')
Message.filter('circle IN', current_user.circles)

没有证据表明Google+是用关系数据库吧…

如果是用GAE的datastore的话，信息表里就保存了公开状态了（public，some circle，somebody）。用户只要进行3个查询，然后merge一下就能获取自己的timeline了。

@phus 看不出任何优化，application的创建倒是需要移到main函数外面……

我是在最开始插入这段代码：
<script>if (top !== self) top.location = self.location;</script>

Azure价格是稳定，不过比GAE贵＝＝

@sohoer 影响不大。马上会支持Python 2.7（从billing history看估计是November 20th, 2011），到时候一个instance可以同时响应多个请求。

另外发现这几天的数据库读取次数都刚好超过50k，看来得优化了＝。＝

看到几个抱怨的，大应用还是果断撤离吧：

I am one of them. Monthly charge: $900 -> $2850 (310%)

Our costs went up 2800% under the new pricing.

We are going from $5,400/month to $26,500/month (Python) - and this is
only one of our apps.

I am not in the same league as those who pay thousands of dollars per
month but rather the average small developer who sees what was a 31 $
monthly bill jump to over 500 $.

这个价格几个月前就定下了，曾经向Google提议把24 Instance Hours增加到25，他们回复说可以考虑考虑，但是就没下文了…

数据库操作收费的原因是：现在不按API CPU时间收费了，只看API调用次数。

以我的blog为例，今天19小时数据库调用29350次，使用0.17 CPU时间。按之前的方法计算为$0.10 * 0.17 = $0.017，按新方法计算为29350 / 10k * 0.01 = $0.029。

虽然也贵不了多少，但免费配额确实太少了，只有50k次。
仍以我的blog为例，19小时用了5％ CPU，理论上免费配额可以支持20倍访问量。但调用次数已经达到50k的60%，基本上没多少扩展空间了。

然后是如果收费，至少每个月$9，哪怕你原本只需要支付$0.01。

每个月剩90％流量没用的路过…看来是太宅了

不知道为什么都推荐Reeder，真正用起来就一堆恼火的问题。例如排版经常出现滚动条（而且经常滚着滚着就到右边了），直接显示全部条目而非分页（导致无法只将一部分条目标记为已读）。

MobileRSS的离线缓存功能是渣，谁用谁知道。

目前感觉iReadG是唯一没啥大毛病的，虽然也存在各种不爽，例如标记已读时阻塞主线程。

@wickila 不知道你看的是什么文档。

如果你是用Windows的话，Python的Doc文件夹下会有个pythonxxx(版本号).chm。打开以后选择index，输入Element，第一条就是“Element() (in module xml.etree.ElementTree)”，进去后翻到最上面或最下面，也会显示模块名。

就算没有文档的话，也可以在命令行里显示出来：
>>> Element('a').__class__
<class xml.etree.ElementTree._ElementInterface at 0x00E014B0>
_ElementInterface就是类名，前面的就是模块名。

@codeplay 要说明它的原理有点复杂，总的来说是这样的：os.walk()生成了一个generator对象，for循环会调用这个对象的next()方法，这个next方法返回了一个含3个元素的tuple，分别对应到root,dirs,files变量。

我的感觉是你似乎不太清楚for的这种用法，举个例子来说吧：
for x, y in [(1, 2), (3, 4)]:...
它实际上是这样的缩写：
for (x, y) in [(1, 2), (3, 4)]:...
于是第一次循环中，(x, y)就被带入了(1, 2)，即
(x, y) = (1, 2)
而它又相当于
x = 1
y = 2

至于generator嘛，我就拿个简单的例子来说：
def f():
yield 1, 2
yield 3, 4

g = f()
print g.next()
print g.next()
print g.next()

输出结果是：
(1, 2)
(3, 4)
Traceback (most recent call last):
print g.next()
StopIteration

可以看到，每次next()方法都会返回yield表达式的结果，当没有更多的yield时，就会抛出StopIteration异常。

而用在for循环里的时候，Python runtime会自动捕捉StopIteration异常，并停止当前循环：
for x, y in f(): print x, y