你好。方法有二个:
我觉得是这样设计的
一个字段记录他所关注的好友信息
应该是json的
然后去数据库查最新的就是更新就是
uchome就是这么干的
-- 用户表(如果这个表数据相当多,可以用分区表)create table userinfo
( userid number(38,0), -- 可以用序列递增值也成,自己看着办
username varchar2(60),
phone varchar2(20),
address varchar2(20),
sex char(1),
cdate date default sysdate
-- 其他字段,自己添加
)
alter table userinfo add constraints pk_userinfo primary key(userid)
-- 用户关注信息表(如果这个表数据相当多,可以用分区表):
create table userattention
( userid number(38,0), -- 用户ID
attention_userid number(38,0), -- 被关注的用户ID
status number(18,0), -- 关注状态(或者说关注等级,自己定义:0代表什么,1代表什么)
cdate date default sysdate, -- 创建时间
udate date default sysdate -- 修改时间
-- 其他字段,自己添加
)
-- 为保持数据完整性:不管是“用户ID”还是“被关注的用户ID”其ID必须在userinfo表中存在!
alter table userattention add constraints pk_userattention primary key(userid,attention_userid)
alter table userattention add constraints fk_userattention_userid foreign key (userid) references userinfo(userid)
alter table userattention add constraints fk_userattention_att_userid foreign key (attention_userid) references userinfo(userid)
userattention表中一个userid对应该可能有N条记录(而不像你说的:用一条记录,其不同的attention_userid 用逗号隔开,这样设置是不合理的)
-- 好比QQ号,我的QQ可以添加N个QQ好友,但我想:腾迅应该不会将我这N个QQ好友用字串连成一条记录(这也太吝啬啦)
对于第一个问题,设计一个schema->(messageID,likedCount),记录每条微博的点赞数。messageID是微博的编号,likedCount是该微博的点赞人数。但是这里有两个问题需要解决,第一是并发,第二是数据量。
每条微博都有可能有很多人同时点赞,为了保证点赞人数精确就需要保证likedCount++是原子 *** 作,这个可以由应用程序来实现,也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话),但是我觉得为了性能考虑,也可以不用实现原子 *** 作,具体原因就不展开了。
每天都上亿可能更多的微博内容产生,这样就会有上亿个新的(messageID,likedCount)生成,这样的数据量是比较大的,单机数据库比较难提供高效的服务,所以需要采取sharding的功能(有时候也叫分表分库),可能根据messageID把这些schema分散到十个或者更多的shards上(据说,sina微博有600个节点,如何三个节点组成一个shard,就有200个shards),这样每个shard处理的请求就只有原来的十分之一,从而就能提高服务的性能。
关于点赞人列表的设计,一般来说,可能想到的schema是(messageID,userID),但是这样的设计有一个小问题,就是有些大发的微博可能会得到几十万的点赞,这样就会产生几十万个条数据,这样数据有点多,读取起来可能也慢。所以可以用这样一个schema(messageID,partID,userIDs),让一个messageID对于多个userID,同时比对应太多的userID,所以加入一个新的partID,一个part存1000个userID,这样几十万个点赞,只需要存几百条数据。这样做还有一个好处,用户点击查看点赞人时的,一般都不是完全显示所有点赞人,而是一批一批显示,这样可以一次只读一条数据,就可显示一批点赞用户信息。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)