阿里分布式數(shù)據(jù)庫服務(wù)原理與實踐

會計學1阿里分布式數(shù)據(jù)庫服務(wù)原理與實踐Agenda?DRDS介紹?在線數(shù)據(jù)遷移原理與應(yīng)用?在線應(yīng)用數(shù)據(jù)拆分經(jīng)驗第1頁/共43頁DRDS介紹第2頁/共43頁DRDS介紹????起源核心價值應(yīng)用場景架構(gòu)與原理第3頁/共43頁DRDS介紹-起源?起源–DRDS脫胎于alibaba的cobra分布式數(shù)據(jù)庫引擎?06年上線使用?在alibaba有80+應(yīng)用在使用，目前已經(jīng)開源?DRDS的80%的代碼出自cobraproxy–Sql解析器–執(zhí)行流程–配置第4頁/共43頁DRDS介紹-起源

?起源

–DRDS吸收了taobaoTDDL分布式數(shù)據(jù)庫引擎的 大量優(yōu)秀經(jīng)驗和解決方案

?08年上線使用

?目前在使用的應(yīng)用900+ ?大量實際應(yīng)用解決方案支持––––分布式j(luò)oin分布式aggregation(groupsummaxmin)異步索引構(gòu)建Autosharding,自動擴容縮容第5頁/共43頁DRDS介紹-起源?起源–DRDS專門針對外部用戶進行了配置的重新設(shè)計?簡化了配置操作規(guī)范與流程?盡可能使得應(yīng)用像操作一個數(shù)據(jù)庫一樣的操作DRDS?用戶的專業(yè)化指導(dǎo)第6頁/共43頁DRDS介紹-核心價值?核心價值–mysql兼容性?95%以上的mysql查詢可以直接在drds上運行?在大部分情況下，可以把drds當做一個單機mysql來使用。?適當?shù)淖龀隽斯δ苌系南拗?，以保證用戶可以一直能夠享受到線性的水平擴展能力。–自動數(shù)據(jù)運維?把機器簡單的添加到集群內(nèi)就可以實現(xiàn)水平擴展和自動的負載均衡。–管理更容易?建庫建表增減字段，一個命令可以搞定第7頁/共43頁DRDS介紹-應(yīng)用場景?應(yīng)用的業(yè)務(wù)需求單機已經(jīng)無法滿足–一個RDS數(shù)據(jù)庫的最大實例也無法滿足用戶的需求?容量瓶頸?事務(wù)數(shù)瓶頸?讀取瓶頸第8頁/共43頁DRDS介紹-應(yīng)用場景?Scaleup（單機垂直擴展）–購買或更換更高端的機器-oraclerac/高端存儲盤柜?優(yōu)勢–業(yè)務(wù)不用修改代碼–業(yè)務(wù)改動小?劣勢–架構(gòu)被把持，更換存儲成本巨大–定價權(quán)在數(shù)據(jù)庫軟件廠商–把定時炸彈的時間往后撥了一些時間，最終還是會炸的第9頁/共43頁DRDS介紹-應(yīng)用場景?Scaleout（多機水平擴展）–使用廉價數(shù)據(jù)庫陣列來滿足用戶需求--DRDS–優(yōu)勢?更輕量的使用數(shù)據(jù)庫，未來更換的成本小?一次重構(gòu)，以后基本再無需擔心系統(tǒng)瓶頸–劣勢?重構(gòu)需要付出成本?分布式環(huán)境下一些查詢會被限制不允許執(zhí)行?完成相同功能需要比單機擴展付出更多成本第10頁/共43頁DRDS介紹-應(yīng)用場景

?理想狀態(tài)

–Scaleout與scaleup結(jié)合

?讓系統(tǒng)架構(gòu)具備scaleout的能力

?盡可能提升單機利用率

–但不要過早過度設(shè)計

2.5 2 1.5 1 0.5 0單機垂直擴展成本多機水平擴展成本第11頁/共43頁DRDS介紹-架構(gòu)與原理第12頁/共43頁DRDS介紹-架構(gòu)與原理?DRDS-Server–直接為應(yīng)用或者用戶提供基于MySQL協(xié)議的數(shù)據(jù)服務(wù)，是整個系統(tǒng)提供服務(wù)的核心部分，數(shù)據(jù)服務(wù)以LVS集群的方式對外提供。?DRDS-Manager–為整個系統(tǒng)的各個子系統(tǒng)提供管理、控制和協(xié)調(diào)工作，并對相關(guān)配置進行持久化；該系統(tǒng)目前以主備的模式提供高可用服務(wù)。?用戶管理Web控制臺–用戶管理控制臺是用戶參與系統(tǒng)管理的入口，用戶可以在上面創(chuàng)建表、規(guī)則、修改表結(jié)構(gòu)、執(zhí)行數(shù)據(jù)遷移和擴容工作等，是系統(tǒng)面向用戶的控制臺。第13頁/共43頁DRDS介紹-架構(gòu)與原理?系統(tǒng)管理Web控制臺–WebServer，系統(tǒng)管理控制臺是運維與運營方參與整個系統(tǒng)管理和監(jiān)控的入口，使用方可以查看系統(tǒng)運行狀況、監(jiān)控系統(tǒng)關(guān)鍵指標等，是系統(tǒng)面向管理的控制臺。DRDS-Manager?DataMigration–支持由用戶觸發(fā)的數(shù)據(jù)遷移和擴容操作，系統(tǒng)采用全量+基于binlog增量的方式工作。?RDS實例群–基于MySQL的數(shù)據(jù)庫實例，可以是基于現(xiàn)有proxy的，也可以直接基于MySQL實例的。第14頁/共43頁DRDS介紹-架構(gòu)與原理第15頁/共43頁DRDS介紹-架構(gòu)與原理?流程

?AST–抽象語法樹–標記SQL的組成方式?執(zhí)行計劃–告知執(zhí)行器如何高效的利用K-V第16頁/共43頁DRDS介紹-架構(gòu)與原理

?Join的執(zhí)行計劃

–表A在機器mA,表B在機器mB

–select*fromAujoinBoonu.id=o.buyer_idwhere ='sun‘Join

leftColumns:[U.ID] rightColumns:[O.BUYER_ID] type:innerjoin strategy:INDEX_NEST_LOOP executeOn:mA

left:

,u.address,u.idfromAwherename=sun

right:

selectb.id,buyer_id,seller_idfromB

Join Onu.id=o.buyer_idQueryAasu Name=sunQueryBaso Name=sun第17頁/共43頁DRDS介紹-架構(gòu)與原理

?全表avg的執(zhí)行計劃

–表A分庫分表3個Merge avg（id)subQuery

Q1:selectcount(id),sum(id)A_0 Q2:selectcount(id),sum(id)A_1 Q3:selectcount(id),sum(id)A_2–selectavg(id)fromA

avg(id)

Querysum(id),count( id)fromA_0

Querysum(id),count( id)fromA_1

Querysum(id),count( id)fromA_2第18頁/共43頁Merge distinctid,groupbyidsubQuery

Q1:selectidfromA_0orderbyidQ2:selectidfromA_1orderbyidQ2:selectidfromA_2orderbyidDRDS介紹-架構(gòu)與原理

?全表distinctgroupby的執(zhí)行計劃

–表A分庫分表3個

–SelectdistinctidfromAgroupbyA

DistinctidGroupbyidQueryidfrom A_0orderby idQueryidfrom A_1orderby idQueryidfrom A_2orderby id第19頁/共43頁DRDS介紹-小結(jié)?起源–Alibabacobra+taobaoTDDL+面向終端用戶的運維體系?應(yīng)用場景–單個數(shù)據(jù)庫不足以滿足用戶的需要?核心價值–用戶體驗基本與mysql一致，有適當限制?架構(gòu)與原理–使用了proxy架構(gòu)第20頁/共43頁在線數(shù)據(jù)遷移原理與應(yīng)用第21頁/共43頁在線數(shù)據(jù)遷移原理與應(yīng)用?核心價值與目標場景?基本原理?操作方法第22頁/共43頁核心價值與目標場景?用戶可以持續(xù)的將數(shù)據(jù)從一組機器復(fù)制到另外一組–源機器可以不停止服務(wù)–目標機器與原始機器只有很小的數(shù)據(jù)復(fù)制延遲?常見場景–外部Oracle、mysql快速遷移至RDS服務(wù)器內(nèi)–內(nèi)部RDSfororacle遷移至單機mysql–內(nèi)部RDSfororacle

遷移至drds–自動擴容縮容第23頁/共43頁基本原理?流程第24頁/共43頁操作方法????準備一臺機器，裝好java環(huán)境進行簡單配置，并開啟任務(wù)程序會進行全量復(fù)制+增量追趕提示“catchup”狀態(tài)時，可以認為數(shù)據(jù)的搬遷

已經(jīng)完畢，并且針對原庫的所有寫操作也會被 持續(xù)的重放到目標庫?進行必要驗證?停原庫寫幾秒鐘，讓備庫與原庫一致?進行切換第25頁/共43頁在線應(yīng)用數(shù)據(jù)拆分經(jīng)驗第26頁/共43頁主要限制原因分析與解決思路?主要限制?通用的分布式解決思路和實際場景例子第27頁/共43頁主要限制原因分析與解決思路?分布式事務(wù)限制–單次提交延遲從<20ms=>200ms左右–記錄更多的log因此需要更多資源–針對同一個數(shù)據(jù)的多次更新，因為鎖持有時間變長而出現(xiàn)tps降低–如果一個數(shù)據(jù)是熱點，那么系統(tǒng)整體tps不升反降第28頁/共43頁表A表B事務(wù)2

事務(wù)4

事務(wù)3事務(wù)1事務(wù)5事務(wù)時間序分布式

事務(wù)表A表B事務(wù)1事務(wù)2事務(wù)3事務(wù)4主要限制原因分析與解決思路

?分布式事務(wù)限制

事務(wù)5事務(wù)時間序第29頁/共43頁主要限制原因分析與解決思路

?分布式事務(wù)的一般性解決思路

–半事務(wù)-減錢加錢模型

–Bob給smith100塊??BegintransactionBobhas100????Bob-100Smith+100Transactioncommit一個事務(wù)事務(wù)沒有結(jié)束的時候，下一個更新不能進行第30頁/共43頁主要限制原因分析與解決思路?分布式事務(wù)的一般性解決思路–支付寶賬務(wù)支付場景–淘寶交易成交場景–Ebaypaypal賬務(wù)支付場景第31頁/共43頁主要限制原因分析與解決思路

?分布式事務(wù)的一般性解決思路

–半事務(wù)-減錢加錢模型

–Bob給smith100塊

?Begintransaction一個事務(wù) 另個事務(wù)?Bobhas100??Bob-100

異步消

息?Smith+100?Transactioncommit第32頁/共43頁主要限制原因分析與解決思路?分布式j(luò)oin限制==基于內(nèi)存join->基于網(wǎng)絡(luò)的join–千兆網(wǎng)卡吞吐量100mb/s–內(nèi)存吞吐量800mb/s–通過網(wǎng)絡(luò)傳輸，額外的解碼和編碼操作開銷–額外的一致性讀問題第33頁/共43頁DRDS介紹-應(yīng)用場景?主要限制原因分析與解決思路–分布式j(luò)oin常見解決方案–核心思路就是讓join盡可能發(fā)生在本機?小表廣播–如果一個小表與其他切分后大表放在一起，則將小表廣播到所有服務(wù)器上–這樣就可以進行本地join。?相同切分條件join–用戶，交易，評價，都按照相同的方法切分–一個用戶的數(shù)據(jù)物理上就在一個庫，因此可以直接本地join第34頁/共43頁主要限制原因分析與解決思路?數(shù)據(jù)庫的索引Select*fromtabwhereuser_id=?第35頁/共43頁主要限制原因分析與解決思路?主要限制原因分析與解決思路–網(wǎng)絡(luò)延遲導(dǎo)致索引讀一致性開銷變大?一致性的本質(zhì)就是讓快的等慢的?單機索引讀一致性與現(xiàn)在的數(shù)據(jù)庫一致性一致?多機索引讀一致性–方案1，當所有的數(shù)據(jù)節(jié)點上的索引都成功，則返回成功。?代價是更多的寫入延遲<20ms->200ms+–方案2，解綁異步，先做完的先返回，后做完的后返回，相互不影響。?代價是沒有系統(tǒng)級別的方案來保證索引讀一致性，用戶可能按照某個條件查詢到的記錄不是最新的第36頁/共43頁主要限制原因分析與解決思路

?賣家買家問題，使用數(shù)據(jù)增量復(fù)制的方式 冗余數(shù)據(jù)進行查詢。這種冗余從本質(zhì)來 說，就是索引。bizOrderID

0 1 2 3 4 5 6 7 8buyerID

0 0 0 0 0 1 2 3 4sellerID

1 2 3 4 5 0 0 0 0

content

床上用品 路上用品銷售路由器 中文書籍 電腦

ipad

筆記本 鉛筆 桌面第37頁/共43頁主要限制原因分析與解決思路buyerID%4sellerID%4異構(gòu)復(fù)制510ipadbizOrderID

0 1 2 3buyerID

0 0 0 0sellerID

1 2 3 4

content床上用品路上用品銷售路由 器中文書籍405電腦

8bizOrderID

4buyerID

0sellerID

桌面contentbizOrderID

6buyerID

2sellerID

0content

筆記本bizOrderID

7buyerID

3sellerID

0content

鉛筆bizOrderID

5 6 7 8 3buyerID

1 2 3 4 0sellerI