新浪微博,腾讯微博mysql数据库主表猜想

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 用户信息表(t_user_info)字段名称字节数类型描述User_id4uint32用户编号(主键)User_name...

用户信息表(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为0

2)更新t_user_info_A中Msg_count

3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)

4)在t_user_relation_A中找到所有关注A的人,比如B,C,D,E,F等等,并发在这些用户的t_uer_msg_index中插入A的这条信息索引,比如名人微博可以并发多个进程来实现对粉丝的消息同步

3.A转发B的消息msg_b

1)在t_msg_info_A中添加这条元消息msg_a,type为2

2)更新t_user_info_A中Msg_count

3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)

4)在t_msg_info_B中更新msg_b的Transferred_count和Transfer_count

5)在t_msg_msg_relation中添加User_a,msg_a与User_b,msg_b的转发关系,page_index为Transferred_count%page_count

4.A评论B的消息msg_b

1)在t_msg_info_A中添加这条元消息msg_a,type为1

2)更新t_user_info_A中Msg_count

3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)

4)在t_msg_info_B中更新msg_b的Commented_count和Comment_count

5)在t_msg_msg_relation中添加User_a,msg_a与User_b,msg_b的评论关系,page_index为Commented_count%page_count

5.A删除消息msg_a

1)删除t_msg_info中的元数据msg_a

2)删除t_uer_msg_index_A中的User_a,msg_a行记录

3)备注:如果A的msg_a被别人评论或者引用,那么在对方查看评论或者转发的时候会提示“原消息已被作者删除”

6.A删除转发消息msg_a

1)删除t_msg_info_A中的元数据msg_a

2)删除t_uer_msg_index_A中的User_a,msg_a行记录

3)在t_msg_msg_relation_A表中找到msg_a的源消息,即B的msg_b

4)删除t_msg_msg_relation_A中user_a,msg_a和user_b,msg_b的转发关系

5)更新t_msg_info_B中msg_b记录的Transfer_count,减1

7.A删除评论消息msg_a

1)删除t_msg_info_A中的元数据msg_a

2)删除t_uer_msg_index_A中的User_a,msg_a行记录

3)在t_msg_msg_relation_A表中找到msg_a的源消息,即B的msg_b

4)删除t_msg_msg_relation_A中user_a,msg_a和user_b,msg_b的评论关系

5)更新t_msg_info_B中msg_b记录的Commecnt_count,减1

8.A拉取全部消息

1)从t_uer_msg_index_A中拉取Author_id,Msg_id,Time_t索引,并以Time_t排序

2)通过页码和每页count控制返回结果数量,这样避免了server io 压力冲击

 

5月25日更新:

1)条件允许的话,所有的index表可以放到内存中,全部cache,而元数据直接ssd,这样读速度会提高很多,当然也要做好热备

2)t_user_relation表最好做合并存储

 

5月27日更新:

1)在第二步原创发消息要通知给粉丝,这时如果是明星,那么推送的数量可能数百万,新浪采取的做法是对这数百万粉丝进行区别对待,按照活跃度划分为几个层级,每个层级有一个推送时效限定,这样可以做到最想看到这个信息的人能够最及时的看到明星动态

2)用硬件来提升速度,将所有index表放在memory上,元数据放在ssd上,数据可以现在这两层上做处理,并定时持久化到mysql中

3)提供批量处理接口,比如拉取最新更新索引

4)在一定限度上容忍不一样,但要实现最终一致性

 

6月1日更新:

本文用的是push模式,关于微博的pull模式,请参见 http://blog.csdn.net/cleanfield/archive/2011/05/27/6450626.aspx

 

6月30日更新:

在新浪微博中,评论和转发都与原创消息是一样的独立记录,只不过多了一条消息关系记录,在展现的时候除了要展现自己添加的转发内容或评论内容之外,还需要将最原始的那条目标消息取出来。


12月8日更新:

消息与消息关系表(t_msg_msg_relation)的备注中,应该是以Referenced_id取模分裂

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
固态存储 关系型数据库 MySQL
"惊!20亿数据秒速入MySQL,揭秘数据库极速插入的黑科技,你不可不知的绝密技巧!"
【8月更文挑战第11天】面对20亿级数据量,高效插入MySQL成为挑战。本文探讨优化策略:合理设计数据库减少不必要的字段和索引;使用批量插入减少网络往返;优化硬件如SSD和内存及调整MySQL配置;并行处理加速插入;附Python示例代码实现分批导入。这些方法将有效提升大规模数据处理能力。
52 2
|
2月前
|
SQL 关系型数据库 MySQL
"告别蜗牛速度!解锁批量插入数据新姿势,15秒狂插35万条,数据库优化就该这么玩!"
【8月更文挑战第11天】在数据密集型应用中,高效的批量插入是性能优化的关键。传统单条记录插入方式在网络开销、数据库I/O及事务处理上存在明显瓶颈。批量插入则通过减少网络请求次数和数据库I/O操作,显著提升效率。以Python+pymysql为例,通过`executemany`方法,可实现在15秒内将35万条数据快速入库,相较于传统方法,性能提升显著,是处理大规模数据的理想选择。
116 5
|
5月前
|
关系型数据库 MySQL
Mysql基础第八天,排序检索数据
Mysql基础第八天,排序检索数据
41 1
|
5月前
|
关系型数据库 MySQL
Mysql基础第二十二天,插入数据
Mysql基础第二十二天,插入数据
25 0
|
5月前
|
SQL 大数据 HIVE
每天一道大厂SQL题【Day28】腾讯数据提取(一)搞笑类型视频的曝光点赞数据
每天一道大厂SQL题【Day28】腾讯数据提取(一)搞笑类型视频的曝光点赞数据
103 0
|
Oracle 关系型数据库 数据库
2013-12-19 无奈的数据库 随笔说说
2013-12-19 无奈的数据库 随笔说说
2013-12-19 无奈的数据库 随笔说说
|
SQL 数据可视化 数据库
<数据库视图>--数据库的“眼镜”(世界杯例题篇),查阅必备
<数据库视图>--数据库的“眼镜”(世界杯例题篇),查阅必备
111 0
|
SQL 关系型数据库 MySQL
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身 下
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身 下
148 0
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身   下
|
关系型数据库 MySQL 程序员
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身 上
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身 上
99 0
数据库 mysql 优化一 听说发第二遍全网程序员都不会单身    上