feed设计

对于sns来说，动态就是核心，动态是传播信息的媒体，用户以动态展开各种交互。

从技术角度来说，动态在读和写方面会很多，用户要先看到动态再去做其它操作，而其它操作都会导致动态的更新，表记录会很多，并只有插入，删除和查询，动态显示每个人都不一样，甚至有很大分别。

先说下好友表，好友表需要有用户id和好友的id两个字段，建唯一索引。连接的时候只需using index，如果内存够大，可以缓冲到内存中，速度够快～好友表肯定是sns中的大表之一，所以必须水平切分，好友表比较好分，因为没有查整张表的业务。

而个人动态，从业务来说，就是分为标题和内容。
例如：
[quote]
[用户a] 上传了 [n] 张照片至 [看图不说话]
[图片1] [图片2]

[用户b] 更新的头像
[新头像]

[用户c] 分享了 [用户h] 的日志 [你好，我也好]
[大家好，才是真的好]

[用户f] 与 [用户h] 成为好友

....
[/quote]
所以可以像设计论坛主题那样来设计这张表，但是为了性能，所以这张表要够小，对于动态字段都保存在持久存储系统中，例如Tokyo Tyrant，memcachedb

表结构：
[quote]feed_id mediumint(8)
user_id mediumint(8) 动态产生人
feed_type enum('blog', 'friend', 'album') 动态类型
input_date timestamp 发生动态时间，索引
feed_title 动态标题 放在持久存储系统中
feed_content 动态内容 放在持久存储系统中[/quote]
如果要考虑用户更改数据后更新动态，例如发表日志后，把标题改了，那可以把动态的数据和模板分离，那只需更新动态的数据就可以了，不过要产生动态的应用要记录动态的id

查询的话sql语句如下

SELECT * 
FROM  `friend` f,  `feed` fd
FORCE INDEX ( input_date ) 
WHERE f.friend_user_id = fd.user_id
AND f.user_id =1
ORDER BY fd.input_date
LIMIT 30

为了防止mysql自作聪明优化sql，所以强制用input_date索引，这样不会出现using filesort。。
可以考虑把最终结果放到memcached中缓存起来，无需考虑命中率，因为这里的cache只需起到分担数据库的压力就可以了，而memcahed自己有淘汰机制，非活跃用户的数据会被刷掉，前提是内存不够。

关于分表，可以把旧记录保存起来，极端点就删掉


[b]后期[/b]
这种方式对于初次来说还可以满足，后期的话，好友和feed的数量查询缓慢，所以，只能把feed推给用户，目前还在实验阶段。


参考资料：
uchome