WOT(World Of Tech)2015,網際網路運維與開發者大會将在北京舉行,會上58同城将分享《大資料量下,58同城mysql實戰》的主題,幹貨分享搶先看。
零、分享提綱
1)基本概念
2)常見問題及解決思路
3)拆庫實戰
4)拆庫後業務實戰
5)總結
一、基本概念
大資料量下,搞mysql,以下概念需要先達成一緻
1)單庫,不多說了,就是一個庫
2)分片(sharding),水準拆分,用于解決擴充性問題
3)複制(replication)與分組(group),用于解決可用性問題
4)分片+分組,這是大資料量下,mysql架構的實際情況
二、大資料量下,mysql常見問題及解決思路
1)常見問題
如何保證可用性?
各色各異的讀寫比,怎麼辦?
如何做無縫倒庫,加字段,擴容?
資料量大,怎麼解決?
2)解決思路
2.1)可用性解決思路:複制
讀庫可用性
從庫複制多個,例如:1主2從
從庫挂了讀主庫,例如:1主1從
寫庫可用性
雙主模式
“雙主”當“主從”用
2.2)讀寫比解決思路-針對特性做設計
讀多些少場景:提升讀性能,3種常見方案:
a)建立索引提高讀性能,什麼小技巧?
b)讀寫分離,增加從庫擴充讀性能
c)增加緩存來擴充讀性能
a)b)c)方案存在什麼問題?
如何解決這些問題?
讀寫相近場景:不要使用緩存,考慮水準切分
寫多讀少場景:不要使用緩存,考慮水準切分
2.3)無縫倒庫[擴容,增加字段,資料遷移]
追日志方案
a)記錄寫日志
b)倒庫
c)倒庫完畢
d)追日志
e)追日志完畢+資料校驗
f)切庫
雙寫方案
a)服務雙寫
c)倒庫完畢+資料校驗
d)切庫
2.4)資料量大解決思路:拆庫
三、58同城資料庫拆庫實戰
四類場景覆寫99%拆庫業務
a)“單key”場景,使用者庫如何拆分: user(uid, XXOO)
b)“1對多”場景,文章庫如何拆分: tiezi(tid, uid, XXOO)
c)“多對多”場景,好友庫如何拆分: friend(uid, friend_uid, XXOO)
d)“多key”場景,訂單庫如何拆分:order(oid, buyer_id, seller_id, XXOO)
1)使用者庫如何拆分
使用者庫,10億資料量
user(uid, uname, passwd, age, sex, create_time);
業務需求如下
a)1%登入請求 => where uname=XXX and passwd=XXX
b)99%查詢請求 => where uid=XXX
結論:“單key”場景使用“單key”拆庫
2)文章庫如何拆分
文章庫,15億資料量
tiezi(tid, uid, title, content, time);
a)查詢文章詳情(90%請求)
SELECT * FROM tiezi WHERE tid=$tid
b)查詢使用者所有發帖(10%請求)
SELECT * FROM tiezi WHERE uid=$uid
結論:“1對多”場景使用“1”分庫,例如文章庫1個uid對應多個tid,則使用uid分庫,tid生成時加入分庫标記
3)好友庫如何拆分
好友庫,1億資料量
friend(uid, friend_uid, nick, memo, XXOO);
a)查詢我的好友(50%請求) => 用于界面展示
SELECT friend_uid FROM friend WHERE uid=$my_uid
b)查詢加我為好友的使用者(50%請求) => 使用者反向通知
SELECT uid FROM friend WHERE friend_uid=$my_uid
結論:“多對多”場景,使用資料備援方案,多份資料使用多種分庫手段
4)訂單庫如何拆分
訂單庫,10億資料量
order(oid, buyer_id, seller_id, order_info, XXOO);
a)查詢訂單資訊(80%請求)
SELECT * FROM order WHERE oid=$oid
b)查詢我買的東東(19%請求)
SELECT * FROM order WHERE buyer_id=$my_uid
c)查詢我賣出的東東(1%請求)
SELECT * FROM order WHERE seller_id=$my_uid
結論:“多key”場景一般有兩種方案
a)方案一,使用2和3綜合的方案
b)方案二,1%的請求采用多庫查詢
四、分庫後業務實戰
分庫後出現的問題:單庫時mysql的SQL功能不再支援了
1)海量資料下,mysql的SQL怎麼玩
不會這麼玩
a)各種聯合查詢
b)子查詢
c)觸發器
d)使用者自定義函數
e)“事務”都用的很少
原因:對資料庫性能影響極大
2)分庫後,IN查詢怎麼玩
使用者庫如何進行uid的IN查詢
user(uid, uname, passwd, age, sex, photo, create_time, ...);
Partition key:uid
查詢需求:IN查詢:WHERE uid IN(1,2,3,4,5,6)
解決方案:服務做MR
方案一:直接分發
方案二:拼裝成不同SQL,定位不同的庫
3)分庫後,非Partition key的查詢怎麼玩
方案一:業務方不關心資料來自哪個庫,可以隻定位一個庫
例如:有頭像的使用者查詢
方案二:結果集隻有一條資料,業務層做分發,隻有一條記錄傳回就傳回
例如:使用者登入時,使用userName和passwd的查詢
4)分庫後,誇庫分頁怎麼玩?
問題的提出與抽象:ORDER BY xxx OFFSET xxx LIMIT xxx
a)按時間排序
b)每頁100條記錄
c)取第100頁的記錄
單機方案
ORDER BY time OFFSET 10000 LIMIT 100
分庫後的難題:如何确認全局偏移量
分庫後傳統解決方案,查詢改寫+記憶體排序
a)ORDER BY time OFFSET 0 LIMIT 10000+100
b)對20200條記錄進行排序
c)傳回第10000至10100條記錄
優化方案一:增加輔助id,以減少查詢量
a)技術上,引入特殊id,作為查詢條件(或者帶入上一頁的排序條件)
b)業務上,盡量禁止跨頁查詢
單庫情況
a)第一頁,直接查
b)得到第一頁的max(id)=123(一般是最後一條記錄)
c)第二頁,帶上id>123查詢:WHERE id>123 LIMIT 100
多庫情況
a)将WHERE id>xxx LIMIT 100分發
b)将300條結果排序
c)傳回前100條
優點:避免了全局排序,隻對小量記錄進行排序
優化方案二:模糊查詢
a)業務上:禁止查詢XX頁之後的資料
b)業務上:允許模糊傳回 => 第100頁資料的精确性真這麼重要麼?
優化方案三:終極方案,查詢改寫與兩段查詢
方案一和方案二在業務上都有所折衷,前者不允許跨頁查詢,後者資料精度有損失,解決誇庫分頁問題的終極方案是,将order by + offset + limit進行查詢改寫,分兩段查詢。
由于wot2015大會時間優先,這個方案待到dtcc2015資料庫大會上,58同城的架構師再與大家細講
五、總結
《概念》
單庫、分片、複制、分組
《常見問題及解決思路》
1)可用性,解決思路是備援(複制)
2)讀寫比
2.1)讀多些少:用從庫,緩存,索引來提高讀性能
2.2)業務層控制強制讀主來解決從庫不一緻問題
2.3)雙淘汰來解決緩存不一緻問題
2.4)讀寫相近,寫多讀少:不要使用緩存,該怎麼整怎麼整
3)無縫導庫
3.1)寫日志追資料
3.2)雙寫
4)資料量大,解決思路是分片(拆庫)
《四大類拆庫思路》
1)使用者庫,“單key”場景使用“單key”拆庫
2)文章庫,“1對多”場景使用“1”分庫,例如文章庫1個uid對應多個tid,則使用uid分庫,tid生成時加入分庫标記
3)好友庫,“多對多”場景,使用資料備援方案,多份資料使用多種分庫手段
4)訂單庫,“多key”場景一般有兩種方案
4.1)方案一,使用2和3綜合的方案
4.2)方案二,1%的請求采用多庫查詢
《拆庫後業務實戰》
1)不這麼玩:聯合查詢、子查詢、觸發器、使用者自定義函數、誇庫事務
2)IN查詢怎麼玩
2.1)分發MR
2.2)拼裝成不同SQL語句
3)非partition key查詢怎麼玩
3.1)定位一個庫
3.2)分發MR
4)誇庫分頁怎麼玩
4.1)修改sql語句,服務内排序
4.2)引入特殊id,減少傳回數量
4.3)業務優化,禁止跨頁查詢,允許模糊查詢
4.4)終極方案,dtcc2015資料庫大會揭曉