文档介绍：微博(Micro-Blog)顾名思义是微型博客,是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype等)及外部API接口等多种渠道发布140字以内信息[1]。支持跨平台交流、与移动设备无缝连接的技术优势,。
有这么一道题- 微博数据库设计:有A,B,C3个用户,A关注C,C关注A和B;A,B更新后C会收到信息提示,比如:
  2010-11-16 22:40 用户A 发表a1;
  2010-11-16 22:41 用户A 发表a2;
  2010-11-16 22:42 用户A 发表a3
  2010-11-16 23:40 用户B 发表b1;
  2010-11-16 22:40 用户B 发表b2;
问题1:如何设计数据表和查询?
问题2:如果C关注了10000个用户,A被10万个人关注,系统又该如何设计?
问题1,我的解答是:设计两张表,一张用于表示用户user,有ID,用户名(username),发布内容(message),发布时间(time)等字段;另一张表用于表示用户之间关注,有ID,用户名(username),关注的用户名,开始关注时间等字段。回去想了想,发现如果数据表照我这样设计的话,问题2的情况就会产生大量的数据,但如果把关注的用户都写在一个记录里那样字符串可能会更大。所以想听听诸位达人的意见,如果是你们会怎样设计数据表呢?
问题1简单而且随意,直接跳过,估计面试的人都不会看。问题2的困难在于:
C关注的用户太多,设计上必须在显示C的页面的过程中,避免去数据库查询所有被关注的用户是否有更新。
,设计上必须在A更新的时候,避免去通知所有关注……
为避免不必要的复杂连接关系,最好还是设计符合第三范式的关系数据。
我想至少应该设计三张表,分别是:
用户表 user:ID,username...;
关注关系表 attention: ID->ID;
发布信息表 info:ID->message;
三张表的设计是比较规范的,至于用户和关注之间的关联要看需求,做join也可以,做DataMap也可以。
个人觉得,需要的逻辑关系在哪儿,而且要进数据库,想不数据量大都不行。当然关注可以不做在一张表中也是一个选择,按关系类型分开走,可以减少特定需求的查询量。
这玩意得丢内存里头吧 memcached 发新的话题的话丢队列里头写数据库去
user
{
befollow[0...n];
post[0...n];
topics[0..n];
}
然后,user[befollow[k]].topics=[j];
用户只要检查topics就好了要不每次上来来个join什么的,估计数据库就挂了
是直接写到数据库的,不能用join,发贴后就丢队列里,向每一个follow我的人的tweet写数据
不能用纯粹的关系数据库来解决问题,因为数据量和访问量都很大。所以设计必须首要考虑性能问题。
我假定前提,
1、一个用户不经常更改他的关注对象,
2、用户添加关注对象的操作远多于移除关注对象的操作。
3、用户发微博的频率是比较高的,要比更改关注用户操作的频率高。
4、消息的通知到达时间用户是不敏感的
有了这些前提,我们做平衡处理。
我们可以忍受
1、较慢的删除关注用户操作
2、比删除操作快但比发微博操作慢的添加关注用户操作。
3、快的微博提交操作
4、慢的消息通知
我们每一个用户建立一个InBox和OutBox,InBox包含关注我的用户ID,OutBox是我关注的用户ID。
Box分为三个部分,一个是基准Box,一个是添加Box,一个是删除Box,实际的Box数据是基准Box和添加Box的并集和删除Box做差集后得到的集合。
1、用户插入关注用户,在用户的OutBox的添加Box加入一条,同时在被关注用户的InBox的添加Box也加入一条添加
2、用户删除关主用户,在用户的OutBox的删除Box加入一条,同时在被关注用户的InBox的删除Box也加入一条添加
3、微博产生后发送消息,将发送微博的用户的InBox(其中含基准Box,插入Box和删除Box)连同微博操作连接一起发送给消息处理器。
4、消息处理器合并Box,并把Box的内容回写到发送微博用户的InBox的基准Box中。
5、在后台添加一个Box合并进程,缓慢的合并用户的Box数据。
6、前台在展示的时候,因为没有合并,展示列表展示OutBox的基准Box和我新添加用户的Box以及删除用户的Box内容。
前台展示是需要商榷的,看PUM是否接受这种方式,如果不接受,