新浪微博、腾讯微博：mysql数据库主表设计猜想.doc

新浪微博、腾讯微博：mysql数据库主表设计猜想 发布时间：2011-08-03 You are here: Home / Schema Design / 新浪微博、腾讯微博：mysql数据库主表设计猜想 新浪微博、腾讯微博：mysql数据库主表设计猜想 八月 3, 2011 by Eugene · Leave a Comment 用户信息表（t_user_info） 字段名称 字节数 类型 描述 User_id 4 uint32 用户编号（主键） User_name 20 Char[20] 名称 Msg_count 4 uint32 发布消息数量,可以作为t_msg_info水平切分新表的auto_increment Fans_count 4 uint32 粉丝数量 Follow_count 4 Uint32 关注对象数量 备注：以User_id取模分表 用户之间关系表（t_user_relation）,必须有关注与被关注的关系 字段名称 字节数 类型 描述 User_id 4 uint32 用户编号（联合主键） Follow_id 4 uint32 被关注者编号（联合主键） Type 1 Uint8 关系类型（0，粉丝；1，关注） 备注：关系是单向的，以User_id取模分表 用户消息索引表（t_uer_msg_index） 字段名称 字节数 类型 描述 User_id 4 uint32 用户编号（联合主键） Author_id 4 uint32 消息发布者编号（可能是被关注者，也可能是自己）（联合主键） Msg_id 4 uint32 消息编号(由消息发布者的msg_count自增)（联合主键） Time_t 4 Uint32 发布时间（必须是消息元数据产生时间） 备注：此表就是当我们点击“我的首页”时拉取的消息列表，只是索引，Time_t对这些消息进行排序 消息与消息关系表（t_msg_msg_relation） 字段名称 字节数 类型 描述 Reference_id 4 uint32 引用消息用户编号（联合主键） Reference_msg_id 4 uint32 引用消息编号（联合主键） Referenced_id 4 uint32 消息发布者编号 Referenced_msg_id 4 uint32 被引用消息编号 Type 1 Uint8 操作类型(1,评论；2，转发) Time_t 4 Uint32 发布时间 Page_index 4 Uint32 转发或者评论页码 备注：以Reference_id取模分表。 腾讯微博比新浪微博好的一点是一个消息的所有评论和转发都是被固定页码，这样在点击看评论的时候搜索效率更 高，因为多了一个where Page_index的定位条件，当然带来的问题就是可能看到有些页的评论排版并不是满页，这就是因为标识为这个Page_index的评论有删除操作。 消息元数据表（t_msg_info） 字段名称 字节数 类型 描述 User_id 4 uint32 发消息用户编号（联合主键） Msg_id 4 uint32 消息编号（联合主键） Content 140 Char[140] 消息内容 Type 1 Uint8 消息类型（0，原创；1，评论；2，转发） Commented_count 4 Uint32 评论过数量（只增不减，删除评论不影响此值，可以作为评论多页显示的页码） Comment_count 4 Uint32 保留的评论数量 Transferred_count 4 Uint32 转发过数量（只增不减，删除转发不影响此值，可以作为转发多页显示的页码） Transfer_count 4 Uint32 保留的转发数量 Time_t 4 Uint32 发布时间 备注：消息元数据中，content像可能存在图片，这部分可以在分布式文件系统中存储。在2011年数据库大会上听杨海潮的演讲，对于nosql 也有涉及，本人能力有限，对这部分的职责还不清楚，希望高人指点。 非常推崇杨海潮ppt中的归档做法，因为微博是有时间轴线的，对于一定时间之前的记录可以分层次归档，这样在前端的最新的数据表的压力就会减轻很多。 业务逻辑： 1.A关注B 1）在t_user_relation_A中添加 A B 1 2）在t_user_relation_B中添加 B A 0 2.原创发消息1）在t_msg_info_A中添加这条元消息，type为02）更新t_user_info_A中Msg_count3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）4）在t_user_relation_A中找到所有