1對多業務，數據庫水平切分架構一次搞定

本文將以「帖子中心」爲例，介紹「1對多」類業務，隨着數據量的逐步增大，數據庫性能顯著下降，數據庫水平切分相關的架構實踐：

• 如何來實施水平切分
• 水平切分後常見的問題
• 典型問題的優化思路及實踐

1、什麼是1對多關係

所謂的「1對1」，「1對多」，「多對多」，來自數據庫設計中的「實體-關係」ER模型，用來描述實體之間的映射關係。

1對1

• 一個用戶只有一個登陸名，一個登陸名只對應一個用戶
• 一個uid對應一個login_name，一個login_name只對應一個uid

這是一個1對1的關係。

1對多

• 一個用戶能夠發多條微博，一條微博只有一個發送者
• 一個uid對應多個msg_id，一個msg_id只對應一個uid

這是一個1對多的關係。

多對多

• 一個用戶能夠關注多個用戶
• 一個用戶也能夠被多個粉絲關注

這是一個多對多的關係。

2、帖子中心業務分析

帖子中心是一個典型的1對多業務。

一個用戶能夠發佈多個帖子，一個帖子只對應一個發佈者。

任何脫離業務的架構設計都是耍流氓，先來看看帖子中心對應的業務需求。

帖子中心，是一個提供帖子發佈/修改/刪除/查看/搜索的服務。

寫操做：

• 發佈(insert)帖子
• 修改(update)帖子
• 刪除(delete)帖子

讀操做：

• 經過tid查詢(select)帖子實體，單行查詢
• 經過uid查詢(select)用戶發佈過的帖子，列表查詢
• 帖子檢索(search)，例如經過時間、標題、內容搜索符合條件的帖子

在數據量較大，併發量較大的時候，一般經過元數據與索引數據分離的架構來知足不一樣類型的需求：

架構中的幾個關鍵點：

• tiezi-center：帖子服務
• tiezi-db：提供元數據存儲
• tiezi-search：帖子搜索服務
• tiezi-index：提供索引數據存儲
• MQ：tiezi-center與tiezi-search通信媒介，通常不直接使用RPC調用，而是經過MQ對兩個子系統解耦(爲什麼這麼解耦，請參見《到底何時該使用MQ?》)

其中，tiezi-center和tiezi-search分別知足兩類不一樣的讀需求：

如上圖所示：

• tid和uid上的查詢需求，能夠由tiezi-center從元數據讀取並返回
• 其餘類檢索需求，能夠由tiezi-search從索引數據檢索並返回

對於寫需求：

如上圖所示：

• 增長，修改，刪除的操做都會從tiezi-center發起
• tiezi-center修改元數據
• tiezi-center將信息修改通知發送給MQ
• tiezi-search從MQ接受修改信息
• tiezi-search修改索引數據

tiezi-search，搜索架構不是本文的重點(外置索引架構設計，請參見《100億數據1萬屬性數據架構設計》)，後文將重點描述帖子中心元數據這一塊的水平切分設計。

3、帖子中心元數據設計

經過帖子中心業務分析，很容易瞭解到，其核心元數據爲：

Tiezi(tid, uid, time, title, content, …);

其中：

• tid爲帖子ID，主鍵
• uid爲用戶ID，發帖人
• time, title, content …等爲帖子屬性

數據庫設計上，在業務初期，單庫就能知足元數據存儲要求，其典型的架構設計爲：

• tiezi-center：帖子中心服務，對調用者提供友好的RPC接口
• tiezi-db：對帖子數據進行存儲

在相關字段上創建索引，就能知足相關業務需求：

• 帖子記錄查詢，經過tid查詢，約佔讀請求量90%
  1. select * from t_tiezi where tid=$tid 
• 帖子列表查詢，經過uid查詢其發佈的全部帖子，約佔讀請求量10%
  1. select * from t_tiezi where uid=$uid 

4、帖子中心水平切分-tid切分法

當數據量愈來愈大時，須要對帖子數據的存儲進行線性擴展。

既然是帖子中心，而且帖子記錄查詢量佔了總請求的90%，很容易想到經過tid字段取模來進行水平切分：

這個方法簡單直接，優勢：

• 100%寫請求能夠直接定位到庫
• 90%的讀請求能夠直接定位到庫

缺點：

• 一個用戶發佈的全部帖子可能會落到不一樣的庫上，10%的請求經過uid來查詢會比較麻煩

如上圖，一個uid訪問須要遍歷全部庫。

5、帖子中心水平切分-uid切分法

有沒有一種切分方法，確保同一個用戶發佈的全部帖子都落在同一個庫上，而在查詢一個用戶發佈的全部帖子時，不須要去遍歷全部的庫呢?

答：使用uid來分庫能夠解決這個問題。

新出現的問題：若是使用uid來分庫，確保了一個用戶的帖子數據落在同一個庫上，那經過tid來查詢，就不知道這個帖子落在哪一個庫上了，豈不是還須要遍歷全庫，須要怎麼優化呢?

答：tid的查詢是單行記錄查詢，只要在數據庫(或者緩存)記錄tid到uid的映射關係，就能解決這個問題。

新增一個索引庫：

t_mapping(tid, uid); 

• 這個庫只有兩列，能夠承載不少數據
• 即便數據量過大，索引庫能夠利用tid水平切分
• 這類kv形式的索引結構，能夠很好的利用cache優化查詢性能
• 一旦帖子發佈，tid和uid的映射關係就不會發生變化，cache的命中率會很是高

使用uid分庫，並增長索引庫記錄tid到uid的映射關係以後，每當有uid上的查詢：

能夠經過uid直接定位到庫。

每當有tid上的查詢：

• 先查詢索引表，經過tid查詢到對應的uid
• 再經過uid定位到庫

這個方法的優勢：

• 一個用戶發佈的因此帖子落在同一個庫上
• 10%的請求過過uid來查詢列表，能夠直接定位到庫
• 索引表cache命中率很是高，由於tid與uid的映射關係不會變

缺點：

• 90%的tid請求，以及100%的修改請求，不能直接定位到庫，須要先進行一次索引表的查詢，固然這個查詢很是塊，一般在5ms內能夠返回
• 數據插入時須要操做元數據與索引表，可能引起潛在的一致性問題

6、帖子中心水平切分-基因法

有沒有一種方法，既可以經過uid定位到庫，又不須要創建索引表來進行二次查詢呢，這就是本文要敘述的「1對多」業務分庫最佳實踐，基因法。

什麼是分庫基因?

經過uid分庫，假設分爲16個庫，採用uid%16的方式來進行數據庫路由，這裏的uid%16，其本質是uid的最後4個bit決定這行數據落在哪一個庫上，這4個bit，就是分庫基因。

什麼是基因法分庫?

在「1對多」的業務場景，使用「1」分庫，在「多」的數據id生成時，id末端加入分庫基因，就能同時知足「1」和「多」的分庫查詢需求。

如上圖所示，uid=666的用戶發佈了一條帖子(666的二進制表示爲：1010011010)：

• 使用uid%16分庫，決定這行數據要插入到哪一個庫中
• 分庫基因是uid的最後4個bit，即1010
• 在生成tid時，先使用一種分佈式ID生成算法生成前60bit(上圖中綠色部分)
• 將分庫基因加入到tid的最後4個bit(上圖中粉色部分)
• 拼裝成最終的64bit帖子tid(上圖中藍色部分)

(怎麼生成60bit分佈式惟一ID，請參見《分佈式ID生成算法》)

這般，保證了同一個用戶發佈的全部帖子的tid，都落在同一個庫上，tid的最後4個bit都相同，因而：

• 經過uid%16可以定位到庫
• 經過tid%16也能定位到庫

潛在問題一：同一個uid發佈的tid落在同一個庫上，會不會出現數據不均衡?

答：只要uid是均衡的，每一個用戶發佈的平均帖子數是均衡的，每一個庫的數據就是均衡的。

潛在問題二：最開始分16庫，分庫基因是4bit，將來要擴充成32庫，分庫基因變成了5bit，那怎麼辦?

答：須要提早作好容量預估，例如事先規劃好5年內數據增加256庫足夠，就提早預留8bit基因。

7、總結

將以「帖子中心」爲典型的「1對多」類業務，在架構上，採用元數據與索引數據分離的架構設計方法：

• 帖子服務，元數據知足uid和tid的查詢需求
• 搜索服務，索引數據知足複雜搜索尋求

對於元數據的存儲，在數據量較大的狀況下，有三種常見的切分方法：

• tid切分法，按照tid分庫，同一個用戶發佈的帖子落在不一樣的庫上，經過uid來查詢要遍歷全部庫
• uid切分法，按照uid分庫，同一個用戶發佈的帖子落在同一個庫上，須要經過索引表或者緩存來記錄tid與uid的映射關係，經過tid來查詢時，先查到uid，再經過uid定位庫
• 基因法，按照uid分庫，在生成tid里加入uid上的分庫基因，保證經過uid和tid都能直接定位到庫

對於1對多的業務場景，分庫架構再也不是瓶頸。

Refer：

[1] 1對多業務，數據庫水平切分架構一次搞定

http://zhuanlan.51cto.com/art/201707/544573.htm

[2] 啥，又要爲表增長一列屬性？

http://chuansong.me/n/1298388046739

[3] 分庫分表須要考慮的問題及方案

https://segmentfault.com/p/1210000010189004/read#top

[4] 多對多業務，數據庫水平切分架構一次搞定

http://bit.ly/2voywf7

[5] 多key業務，數據庫水平切分架構一次搞定

http://bit.ly/2wIeblT