出处: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取模分裂

MySQL在數據庫和編程中的地位非常重要,它是一個開源的關係型數據庫管理系統,廣泛應用於各種應用場景。 1)MySQL提供高效的數據存儲、組織和檢索功能,支持Web、移動和企業級系統。 2)它使用客戶端-服務器架構,支持多種存儲引擎和索引優化。 3)基本用法包括創建表和插入數據,高級用法涉及多表JOIN和復雜查詢。 4)常見問題如SQL語法錯誤和性能問題可以通過EXPLAIN命令和慢查詢日誌調試。 5)性能優化方法包括合理使用索引、優化查詢和使用緩存,最佳實踐包括使用事務和PreparedStatemen

MySQL適合小型和大型企業。 1)小型企業可使用MySQL進行基本數據管理,如存儲客戶信息。 2)大型企業可利用MySQL處理海量數據和復雜業務邏輯,優化查詢性能和事務處理。

InnoDB通過Next-KeyLocking機制有效防止幻讀。 1)Next-KeyLocking結合行鎖和間隙鎖,鎖定記錄及其間隙,防止新記錄插入。 2)在實際應用中,通過優化查詢和調整隔離級別,可以減少鎖競爭,提高並發性能。

MySQL不是一門編程語言,但其查詢語言SQL具備編程語言的特性:1.SQL支持條件判斷、循環和變量操作;2.通過存儲過程、觸發器和函數,用戶可以在數據庫中執行複雜邏輯操作。

MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。


熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

MantisBT
Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

MinGW - Minimalist GNU for Windows
這個專案正在遷移到osdn.net/projects/mingw的過程中,你可以繼續在那裡關注我們。 MinGW:GNU編譯器集合(GCC)的本機Windows移植版本,可自由分發的導入函式庫和用於建置本機Windows應用程式的頭檔;包括對MSVC執行時間的擴展,以支援C99功能。 MinGW的所有軟體都可以在64位元Windows平台上運作。

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

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