关于在 GAE 上实现 home timeline

[Livid]

SELECT IN() 操作限制只能有 30 个 item，因此理论上来说，如果用传统做法，好友超过 30 个就 not working 了。而且想必很慢。

大家有什么好想法么？

[zaykl]

人多流量就马上超了。。

[orlaa]

如果已经不在乎墙了的话，国外一个便宜的VPS或者能让程序更加的“自由”，当然，看起来似乎没有部署在GAE上那么酷。

[Livid]

当注册用户过万之后，需要面临的 scale out 问题，在 LAMP 上和在 GAE 上的难度是差不多的。

[orlaa]

对于GAE没有深入了解，没有过多的发言权，只是感觉一个让人愉悦的web应用它的内在也是需要自由的，而GAE给我的感觉太多条条框框了。
总之，加油！

[Livid]

^_^

我希望有一天这里能够有超过 10 万的用户，却依然很快很愉悦。

[orlaa]

^_^
假如这样，估计v2ex是第一个在GAE上有超10万用户的应用，Google到时是否会有政策倾斜呢？哈，我想多了。

[number5]

可以参考一下jaiku的实现，他们现在全部在GAE上了，http://code.google.com/p/jaikuengine/

[darcy]

jaiku都被Google废弃了

[Kenyth]

上一届Google IO会议有一个slides就是讲scalability的best practice的，你可以参考一下，结合 @number5 提到的jaiku的GAE实现一起看效果更佳:)

[zack]

这确实是个麻烦问题，GAE如果支持类似Cassandra的存储机制就比较好解决了。当然最主要的还是取决于功能设计上是否有需求。

[Livid]

其实 Twitter 自己的做法也不是 SELECT IN()，而是为每个用户创建一个队列。然后当新的 status 发出来时，就将 status 的 ID 插入到 followers 的队列中，而 status 的正文是在一个 key-value 数据库中。

这种做法是可以在 GAE 上实现的。只是当 unfollow 的时候，清除队列中的数据貌似很头疼。

[zack]

@Livid 恩，确实是这样的。GAE并没有一个很好用的应对这种情景的存储API。

而Cassandra似乎比较适合这样的应用场景。

两篇参考的文章，问题的情景是基本一样的：

http://about.digg.com/blog/looking-future-cassandra

http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/

[xuming]

使用query.ancestor，数据存放在同一个节点上，再加上一些必要的冗余或许可以

[Los]

redis 很适合这些场景，而且性能上也跟得上去。

[vvoody]

@livid 用Task Queue在后台维护这么一个队列？不知道效率如何

[vvoody]

@Livid 如果已经跟随的用户发出tweets那么插入timeline队列没什么问题。但如果你新follow了一个人，他之前的tweets如何高效的插入timeline队列就是个问题了

[Tigris10]

可以运行在vps上吗？要怎么配置呢

[jorakura]

有同样的需求，也考虑类似的做法。 #11 @livid提到的做法。
有Twitter的实现的具体ref么？

和#15 @vvoody 说的一样，插入 timeline 和 unfo 的时候的删除都会是大规模的批量操作。只能用taskqueue做，但是性能还不确定。

这里有一个即时的性能参考 http://gaejava.appspot.com/

[keakon]

用一个model专门保存每个用户的公开时间线（实际上就是topic id），然后memcache它们

取的时候直接用memcache.get_multi()来获取

如果其中有些为None，再去数据库里取公开时间线

详细的想法可以参考这篇：

http://www.keakon.net/2010/04/26/Twitter%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BC%9A%E4%BD%BF%E7%94%A8NoSQL%EF%BC%9F

[vvoody]

很丑陋地实现了... https://github.com/vvoody/twidao
不过还是如 @keakon 文章里说的那样，用单一公开时间线比较好。

[jorakura]

@vvoody twidao 很赞！学习中