1
wwwjfy 2013-01-18 10:14:52 +08:00
Sorted Sets?
|
2
yibin001 OP @wwwjfy
性能上,Sorted Sets与list/set差异大吗?像关注列表还好办,每个人的关注数是有限制的。 但粉丝列表就有点夸张了,这个地方还没有完全想好怎么存粉丝。初步的粉丝存法呢,只保存1000个,1000个之后的直接DB了,况且这样的需求并不常见。 |
3
linnchord 2013-01-18 10:50:35 +08:00
好友粉丝列表一般要按关系建立时间点排序吧?还是sorted好,粉丝一般排个5页就ok吧———数据分页大多数时候是个伪需求。
|
4
wwwjfy 2013-01-18 11:24:58 +08:00
@yibin001 搜了下,看到新浪也说了,大数据量,redis做存储已经不太合适。虽然没说原因,但是内存太贵了。
是不是可以数据库做存储,redis只做cache,去重在数据库完成,redis可以只用list,设置过期时间,只存储活跃用户的数据,内存就用不了太多 |
5
xcl3721 2013-01-18 11:56:47 +08:00
微博用的hset
|
6
yibin001 OP |
7
TerranC 2013-01-18 12:07:32 +08:00
其实可以在前端代码逻辑里去cache
用户时常产生交互的人也就那么多 list cache一份常用关系到redis |
8
qiongqi 2013-01-18 12:50:44 +08:00
通常来说,zset会好些,各种操作的时间复杂度,占用cpu都好过list
|
9
miizoo 2013-01-18 17:37:42 +08:00
如果列表也从redis中取的话,sorted set.
仅仅关系的话,set。 因为这样就可以用交集来看共同的好友,或是快速看是否关注了,或是看有多少个粉丝之类。 |
10
yibin001 OP |
11
darklowly 2013-01-19 02:16:36 +08:00
elasticsearch+cache瞬间搞定
|
12
xatest 2013-01-19 19:11:17 +08:00 via iPhone
Redis的sorted set 可以同时满足取区间值和删除指定值的需求,性能上与list, set相比主要是增删操作要慢一点,list增加一个元素是O(1)的,sorted set是O(log(n))级别,假如在每个用户的好友数据量不超过1000的情况下,也就是不超过O(10)的时间复杂度,可以接受。
|