貝聊億級資料庫分庫分表實踐

貝途發表於2017-08-15
文章作者:唐璜,貝聊資深JAVA工程師,曾長期就職於網易
方案實施:鄭曉濱,貝聊高階JAVA工程師,曾就職於網易

首先說明一下,這是貝聊2016年針對班級動態所實施的一個資料庫分庫分表方案,經過一年多的驗證,證明我們的方案是可行的,因此分享給大家。
一、業務場景
班級動態是貝聊為家長和老師提供的一個核心功能,類似於微信朋友圈、微博、QQ空間等的好友動態功能,是幼兒園家長老師使用頻率最高的功能之一。在貝聊,老師和家長都可以在班級裡釋出動態、評論動態、點贊動態,內容可以包含文字、圖片或者視訊等內容。目前只要涉及到好友、粉絲之類的APP或者是網站基本都有這個功能,所以這個業務場景大家應該都很熟悉,就不多介紹了,附一張貝聊APP裡班級動態的截圖:
貝聊億級資料庫分庫分表實踐二、現狀(2016年)
貝聊從2013年成立,至2016年,使用貝聊的幼兒園已經達到幾萬所,班級動態業務涉及的資料也已經達到億級,且每天以幾十萬的速度在增長,預計三年左右就能達到數十億。與此同時,動態的回覆和點讚的數量更大,通常是動態量的幾倍到十幾倍的樣子。

而班級動態、評論與點贊三個表,當時跟幼兒園、班級等主業務資料表放在一起,直接儲存在阿里雲RDS(MySQL資料庫)上,雖然有做主從,但未做分庫分表處理(這應該是創業公司初期的通病)。

三、存在問題
容量瓶頸: 單機資料庫隨著資料量和訪問量的增長一定會遇到服務瓶頸。
擴充套件困難: 單機資料庫擴充套件最終需要依賴硬體升級,擴充套件過程複雜、對業務影響大。
使用成本高: 單機資料庫為獲得更高的服務能力,依賴特定的高階裝置,成本高昂。
可靠性低: 單機資料庫的資料集中儲存,當機時直接影響所有資料庫資料的訪問。
四、目標
優化後,未來三到五年不需要進行大規模的優化。同時,在避免效能問題的基礎上,能支撐幾億甚至幾十億的動態。
五、實施方案
1、獨立班級動態資料庫
從主業務資料庫裡剝離班級動態相關資料表,獨立成庫。原因很簡單,一是獨立出來方便做處理,二是任何一方有問題,都不會影響另一業務的正常執行。
2、切分班級動態資料庫的資料
在要支撐幾億甚至幾十億的資料,同時有頻繁的插入和查詢的業務場景,不進行資料切分肯定是行不通的。

這裡說的資料切分是水平切分,水平切分主要目的是為了突破單節點資料庫伺服器的 I/O 能力限制,解決資料庫擴充套件性問題。水平切分時首先是通過一系列的切分規則將資料分佈到不同的DB或table中,再通過相應的DB路由或者table路由規則找到需要查詢的具體DB或者table,最後進行相關操作。

以下看看我們的班級動態、評論與點贊三個表:
貝聊億級資料庫分庫分表實踐由此可見,班級動態表、回覆表與點贊表都與幼兒園id相關。實際業務場景就是如此,使用者必須在其所在的幼兒園下發布動態,也只能檢視、回覆與點贊所在幼兒園的動態。那麼選擇幼兒園id欄位作為分庫與分表的鍵,不論是拆分、插入、查詢都是沒問題的。

那麼,分多少個庫合適,分多少個表合適,根據什麼規則分,一旦單表數量再次達到效能瓶頸怎麼辦?針對這些問題,我們經過了充分的調研討論,最後決定採用阿里雲 DRDS方案來實施。

DRDS(Distributed Relational Database Service,分散式關係型資料庫服務 )是阿里巴巴自主研發,致力於解決單機資料庫瓶頸而推出的分散式資料庫中介軟體產品。

先看看阿里雲官閘道器於DRDS的產品介紹(這塊好像DRDS的軟文,阿里雲是不是該付我們廣告費呢): DRDS 高度相容 MySQL 協議和語法,支援水平拆分、平滑擴容、彈性擴充套件、透明讀寫分離和分散式事務等特性,具備分散式資料庫全生命週期的運維管控能力。
貝聊億級資料庫分庫分表實踐DRDS 支援庫級拆分、表級拆分和分庫分表拆分。拆分鍵暫時只支援單個欄位。
分庫鍵:DRDS 根據分庫鍵的值將資料水平拆分到後端的每一個 RDS 分庫裡。鍵值相同的資料,一定會位於同一個 RDS 資料庫裡。
分表鍵:每一張邏輯表都可以定義自己的分表鍵,鍵值相同的資料,一定會位於同一個 RDS 資料表裡。
貝聊億級資料庫分庫分表實踐由於我們在使用阿里雲的RDS,同時我們只需要根據單個欄位(幼兒園id)拆分,所以我們用阿里雲 DRDS作為分庫分表方案完全沒毛病,對吧?切分方案確定後,丟給阿里搞,少死好多腦細胞,馬雲也一邊偷著樂去了。

根據阿里雲DRDS的官方建議:未來2年預估班級動態資料總量 = DRDS建議單表容量 X 分表數量 X 分庫數量
3、獨立動態業務
重構現有的班級動態模組,並將其獨立成一個Dubbo服務元件。程式碼重構的目標主要有以下幾點:
1)保證大部分的SQL語句能夠使用分庫分表鍵,避免全表掃描
2)避免使用JOIN語句,使用單表查詢替代
3)靈活使用快取策略減少DB壓力
貝聊億級資料庫分庫分表實踐六、效果比較
1、 效能大幅度提升
響應速度提升5至10倍,以當時獲取班級動態列表介面為例:
分庫分表實施前:響應時間大致為200ms至1500ms級之間。
分庫分表實施後:響應時間提升至大致為30ms至300ms之間。
2、 可方便快速進行橫向擴容
如果需要擴容,直接按照阿里雲DRDS指引,增加新的分庫即可。
3、 架構的優化
獨立動態業務,通過Dubbo提供服務,對系統進行解耦,讓業務具備快速橫向擴容能力。
4、後遺症
獨立後,暫時沒有做分散式事務,在業務中需要避免跨庫事務。


相關文章