@Los 曾经学过，但感觉篇幅太长，学不进去。我喜欢那种简单的构架，可以一眼看透底层的实现。
Ruby倒是花了很长一段时间去学习，最终觉得不适合我而放弃了。

提到ActiveRecord的原因是GAE的ORM很复杂，属性放在不同的model里，key和parent的设定，索引的取舍，会造成功能、可行性、性能、扩展性、存储空间等方面的巨大差异。
举个简单的例子，昨天我还在GAE论坛看到有人抱怨30多M的数据，就用掉了1G的数据库空间（其实很多人都有这样的抱怨）；而在我的博客里，7M的数据只用了10M左右（看不到个位）的空间，且性能和功能上完全达到了我的需求。
我还用过其他GAE上的blog，响应速度方面甚至可以相差1～2个数量级，这也是我为什么说数据库设计需要花非常多时间的原因。

@fly2never
1. 在Chrome下登录时，自动填写的密码会和占位符叠加到一起。
2. 希望有个日历模式。
3. 在隐私政策里只提到了用户的personal information，但我比较关心你们是否会任意查看用户的todo列表。说实话如果是国外的服务，别人看不懂中文，我就很放心。

@Los 我不知道ActiveRecord是怎么做ORM，这些关系型的数据也是存储在一个ActiveRecord对象里么？会自动映射出一张关系表？那么作为post还是user的属性会有区别么？那么如果换个数据库，例如MongoDB，是否又有区别呢？

前面我也说过，我来设计的话，可能会变得面目全非。
例如我想做成长连接，服务器自动将更新push到浏览器。
而一旦这样做，可能不少表都需要增加一个时间戳，索引也需要变动；又或者设计一个更新表，可以封装所有类型的更新；甚至直接脱离数据库，用队列来驱动。

在思考功能的过程中，可能经常需要对数据库的设计和索引的取舍进行改变；而如果将这些思考过程延后到二次开发时进行，很多行为会与新功能冲突，或是有假定失效的可能（即原设计隐含的假设，但新设计下可能得区分不同情况）。


@Hyperion 我觉得中国的论坛逛多了，就会失去对人的尊重，也渐渐变得不懂自重。
像你这样挑衅的口吻说话，对象换成是你，你会接受吗？如果不接受，那说出来的意义只是为了自己的快感吗？
人都是聪明的动物，不需要太过直白。想想这句话，也许会让你避免很多无谓的争吵：在自己有理时，记得给对方台阶；在自己无理时，坦率地道歉。

@Los 忙了一下午，先去吃饭＝。＝

字段好像少了点，比如收藏、关注和已读没看到。

@Los 我回顾了一下，好像没人嘲讽你。以前和 @Livid 争论时，或者看他和别人争论时，发现他自尊心比较强，而且比较敏感（好像很多人都这样）。不过这里我还是老观点，他说得没错。

作为一个开源项目的发起人，我觉得他不仅是为自己写产品，更是为其他人写产品，因此有义务写得易于维护。
以我的经验，思考需求和设计上的时间越多，维护起来就越轻松。
以前也出现过想改PB代码，但最终决定干脆重写的人。没记错的话，@Livid 说过他只是想以最小的努力把PHP的PB1移植到Python的PB2。如果他不是那么急于移植的话，我想PB的开源会更为成功。
既然clone自己的项目都离不开重新设计，那么clone别人的，是否更应如此呢？

很显然，如果是抱着对他人有用的想法来做项目，就不会这样急于求成。
我回顾了一下自己博客的代码库，除去需求之类的时间，在数据库设计和实现上花了8天，其他地方用了3天完成雏形。当时我对自己用到的很多东西并不熟悉，重新开发的话，那3天时间可能会大幅缩短，但数据库设计上，我想仍不会少于一周。
曾经也看过PB的源码，让我设计的话，数据库这部分会变得面目全非，而功能自然也会有所调整。我不认为7天内可以clone出一个让人心动的产品，我想你也不愿意别人拿你的产品二次开发时，觉得还不如重写一个算了。

@dongsheng 直接操作啊，更新数据还要lazy干啥…印象中操作1000个花了4秒，而sqlite不到0.1秒。于是我立刻理解iReadG标记已读时为什么会阻塞半天主线程了…

@dongsheng 初学Core Data时曾经做过一个测试，批量插入、更新和删除数据时，它比SQLite慢2个数量级。而我经常需要批量更新几百条数据，差距基本上就是秒和毫秒级的，于是果断放弃了。

@Los 我不知道RoR是怎样的开发速度，但7天显然不够。

如果我去做这样一个社区，我至少会花1个月的空闲时间来考虑需求，收集各种时刻闪现出来的创意，在考虑可行性和必要性后，融合和舍弃一些特性。
在将未来的发展方向考虑进去后，才会开始数据库建模，并同时根据可行性和性能来调整。因为这才能保证性能和扩展性。你当然可以把1小时内搭建出来的模型用于一个几千人的社区，但如果人数增加1000倍呢？

你或许会说你只是clone，需求什么的直接照搬就行了。但GAE的datastore是特有的，你几乎无法重用V2EX的model。而在脱离datastore后，你可以有更大的发挥空间，也应该有更好的实现。舍弃掉该有的改进，这种产品真的就只能像 @Livid 那样理解了。

如果你的项目都是3天完工的，我很疑惑你能从中得到些什么，也无法想象有人对花5年时间做这样的事怀有成就感。
对我来说，思考远比编码的收获大，因为后者只是印证一个理所当然的结果。

而在编码完成后，我还经常需要改变需求或者优化性能，几乎每个月都要抽出点空来做。这种看着自己的代码日渐成熟的心情，或许你也是没空来体验的。

我也经常和 @Livid 有不同的观点，但这次我认为他说得很对。如果你还在V2EX的话，好好思考一下那几个问题，大概比你继续下一个5年要有意义一些。

@hyden 安装信息
1. 安装游戏
2. 运行游戏 需要测试资格或等待破解

@sohoer 更新量不大，小的更新我都不会去删除缓存。

顺便更正上面一个错误，PV数应该翻倍，因为memcache有55%的命中率。

再给个数据吧，我每天的请求数是2万多，Datastore Reads是7万多。这几天优化过后变成5万了，昨晚又优化了一个地方，但估计只能降到4万，几乎没多少增长空间了。
2万/天请求换算成秒只相当于0.2 QPS，而实际上平均0.1秒就能处理一个请求。也就是说，免费配额虽然给了一个免费的instance，但80%的时间都必须让它空闲着。

@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了。