新浪微博,腾讯微博mysql数据库主表猜想
出处:http://blog.csdn.net/cleanfield/article/details/6339428 注意,原文下面的评论也是难得的学习资料,千万不能错过 用户信息表(t_user_info) 字段名称 字节数 类型 描述 User_id 4 uint32 用户编号(主键) User_name 20 Char[20] 名称 Msg_count 4
出处: http://blog.csdn.net/cleanfield/article/details/6339428
注意,原文下面的评论也是难得的学习资料,千万不能错过
用户信息表(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取模分裂

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

MySQL和phpMyAdmin是強大的數據庫管理工具。 1)MySQL用於創建數據庫和表、執行DML和SQL查詢。 2)phpMyAdmin提供直觀界面進行數據庫管理、表結構管理、數據操作和用戶權限管理。

Oracle不僅是數據庫公司,還是雲計算和ERP系統的領導者。 1.Oracle提供從數據庫到雲服務和ERP系統的全面解決方案。 2.OracleCloud挑戰AWS和Azure,提供IaaS、PaaS和SaaS服務。 3.Oracle的ERP系統如E-BusinessSuite和FusionApplications幫助企業優化運營。

在MySQL中,外鍵的作用是建立表與表之間的關係,確保數據的一致性和完整性。外鍵通過引用完整性檢查和級聯操作維護數據的有效性,使用時需注意性能優化和避免常見錯誤。

MySQL和MariaDB的主要區別在於性能、功能和許可證:1.MySQL由Oracle開發,MariaDB是其分支。 2.MariaDB在高負載環境中性能可能更好。 3.MariaDB提供了更多的存儲引擎和功能。 4.MySQL採用雙重許可證,MariaDB完全開源。選擇時應考慮現有基礎設施、性能需求、功能需求和許可證成本。

SQL是一種用於管理關係數據庫的標準語言,而MySQL是一個使用SQL的數據庫管理系統。 SQL定義了與數據庫交互的方式,包括CRUD操作,而MySQL實現了SQL標準並提供了額外的功能,如存儲過程和触發器。

Redis是一种内存数据结构存储系统,主要用作数据库、缓存和消息代理。它的核心特点包括单线程模型、I/O多路复用、持久化机制、复制与集群功能。Redis在实际应用中常用于缓存、会话存储和消息队列,通过选择合适的数据结构、使用管道和事务、以及进行监控和调优,可以显著提升其性能。

安全地處理JSON中的函數和正則表達式在前端開發中,經常需要將JavaScript...

MySQL和phpMyAdmin可以通過以下步驟進行有效管理:1.創建和刪除數據庫:在phpMyAdmin中點擊幾下即可完成。 2.管理表:可以創建表、修改結構、添加索引。 3.數據操作:支持插入、更新、刪除數據和執行SQL查詢。 4.導入導出數據:支持SQL、CSV、XML等格式。 5.優化和監控:使用OPTIMIZETABLE命令優化表,並利用查詢分析器和監控工具解決性能問題。
