...最近在纠结这个问题...
现在的想法是把所有人产生的status归到一个表中... 然后根据following进行提取..
但是不太明白应该怎么做分页之类的东西..
或者说我这个想法本身是错误的？
....好吧问题有点小白+伸手党嫌疑..
这篇文章也许能给你一些启发：http://codecampo.com/topics/4d7f18bf9...
“三维定位——什么是多级映射的数据结构呢?就是一个稀疏的、多维的和排序的Map，每个Cell(单元格)由行关键字、列关键字和时间戳来进行三维定位.Cell的内容本身就是一个字符串，比如，存储每个网页的内容。”
不知道这段话能不能给lz什么启发不。: )
拉的方式可以这么实现：
首先，所有人的产生的status_id记录到一个索引表中，按时间索引
这个表需要有这几个字段 uid status_id ctime
这个单表可以按时间拆成多个表，比如每天一个表.
其次，status数据可以存入key-value存储 status_id => status_data
查询时，使用类似 select * from 索引表 where uid in (uid1, uid2, uid2) 这样的查询
因为索引表按时间排序，所以缓存上很容易做得很足，尤其是老数据.
拿到status_id列表之后，再往key-value存储中把批量把status数据取出，这一步，缓存也可以做得很足
我觉得拉的模式有几个问题，一个是数据量的控制问题，如果用id in (1,2,3,4)这种方式查询会丢失索引，导致查询很慢。有可能一个查询花好几秒（100W条记录的数量级）。第二，如果用定时分表来解决速度的问题的话，检索就困难了，这块的设计就可能会很纠结。
我现在采取的是拉的方式，所有需要保存为timeline的数据放在一张表里，按时间索引。
然后读取的时候根据self和follow的id去取相应用户的timeline数据。
有几个问题：
1、如果分表肯定存在表合并的问题，效率有点慢。不分表的话，数据肯定会很大，慢慢的效率也会降下来。
2、timeline是否要保存原始数据？如果只保存key，并却不使用缓存的话，数据库的操作量会很大。如果保存原始数据，假如源数据需要支持修改，会存在数据一致的问题。
3、如果实现数据合并（比如：一个人在同一天follow了两个人，则合并成一条），为了保证读取的数据量一直，合并仅能使用SQL完成，速度比较慢。
SNS和微博的timeline还是有很大的区别的。
新手，一点不成熟的意见，仅供参考。
PS：在存储上，timeline和源数据的不一致是肯定会存在的。所以在数据取出来之后要考虑有timeline没有源数据的情况，以免出现错误。
这个slide里面有提到，可以看一下 http://www.slideshare.net/nightsailer...
说一种最简单的做法
1.内容作为key-value存储
为每一条statu生成一个唯一id作为key，将内容结合化编码后当纯字符串作为value，存在key-value存储中。具体key-value存储就多了。缓存层当然可以直接用memcached亦可。
2.关系处理（这里讲最常用的推模式）
通常status有两个大的组织形式：
A 某个人所有的status列表
B 你关注的人的所有status列表
如果采用推的模式，那么每个人只需要在数据库中维护上面两个列表，相当于有一倍的数据冗余，但是两个列表本身都是可以按uid分表的。第一个按作者的uid分表，第二个按查看消息的用户的uid分表。具体操作的时候，你可以选择双写数据库，也可以直接写其中一张表的，然后走异步队列去写另外一张表。
这个方案想起来比较简单，一般人都能理解。但是在大数据量下还是有很多问题（比如一个人有一百万粉丝，那么他发一条消息，你得发给100w个人，100w次的数据库操作）。
改进的方案当然还有很多。比如什么拉模式，按时间分表，按不同活跃程度的用户区分对待等等。