阿里巴巴分布式數(shù)據(jù)庫(kù)服務(wù)DRDS研發(fā)歷程

來源：CSDN 時(shí)間：2017-01-19 15:56:03 作者：艾樂強(qiáng)

　　淘寶TDDL研發(fā)歷史和背景

　　淘寶DRDS/TDDL是阿里巴巴自主研發(fā)的分布式數(shù)據(jù)庫(kù)服務(wù)。DRDS脫胎于阿里巴巴開源的Cobar分布式數(shù)據(jù)庫(kù)引擎，吸收了Cobar核心的Cobar-Proxy源碼，實(shí)現(xiàn)了一套獨(dú)立的類似MySQL-Proxy協(xié)議的解析端，能夠?qū)魅氲腟QL進(jìn)行解析和處理，對(duì)應(yīng)用程序屏蔽各種復(fù)雜的底層DB拓?fù)浣Y(jié)構(gòu)，獲得單機(jī)數(shù)據(jù)庫(kù)一樣的使用體驗(yàn)，同時(shí)借鑒了淘寶TDDL豐富的分布式數(shù)據(jù)庫(kù)實(shí)踐經(jīng)驗(yàn)，實(shí)現(xiàn)了對(duì)分布式Join支持，SUM、MAX、COUNT、AVG等聚合函數(shù)支持以及排序等函數(shù)支持，通過異構(gòu)索引、小表廣播等解決分布式數(shù)據(jù)庫(kù)使用場(chǎng)景下衍生出的一系列問題，最終形成了完整的分布式數(shù)據(jù)庫(kù)方案。

　　使用場(chǎng)景

　　分布式數(shù)據(jù)庫(kù)核心訴求在于解決單機(jī)數(shù)據(jù)庫(kù)的瓶頸，單機(jī)數(shù)據(jù)庫(kù)在使用過程中不可避免會(huì)遇到數(shù)據(jù)庫(kù)容量、連接數(shù)、事務(wù)數(shù)、讀性能瓶頸，突破這些瓶頸的兩種通用的解決模型是單機(jī)垂直擴(kuò)展scale up模型和水平擴(kuò)展scale out模型。

　　單機(jī)擴(kuò)展模型和硬件資源強(qiáng)綁定，普遍采用升級(jí)單機(jī)硬件能力的方式，實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)能力擴(kuò)展，比如原來采用MySQL單機(jī)數(shù)據(jù)庫(kù)，遇到訪問瓶頸時(shí)更換磁盤，訪問量更高時(shí)就需要考慮使用Oracle的商用解決方案、高端的存儲(chǔ)設(shè)備、高端小型機(jī)，也就是IOE架構(gòu)，甚至升級(jí)IOE設(shè)備，以換取更高的擴(kuò)展和服務(wù)能力，這個(gè)過程就會(huì)存在設(shè)備升級(jí)和數(shù)據(jù)遷移的成本。

　　多機(jī)器用水平擴(kuò)展模型使用大量廉價(jià)的PC-Server，通過陣列的方式來實(shí)現(xiàn)數(shù)據(jù)庫(kù)的水平擴(kuò)容，優(yōu)勢(shì)在于成本更低，因?yàn)椴恍枰蕴显O(shè)備和系統(tǒng)，不需要頻繁遷移數(shù)據(jù)，需要時(shí)，只需擴(kuò)容服務(wù)集群規(guī)模。

　　使用分布式多機(jī)模型也需要付出一定成本，分布式數(shù)據(jù)庫(kù)的架構(gòu)與單機(jī)數(shù)據(jù)庫(kù)的邏輯和物理分布存在比較大差異，因此需要將單機(jī)數(shù)據(jù)庫(kù)的數(shù)據(jù)遷移到分布式架構(gòu)模型之下，也就是Sharding的數(shù)據(jù)分片過程，這個(gè)過程涉及數(shù)據(jù)的分布式邏輯設(shè)計(jì)、數(shù)據(jù)庫(kù)遷移和SQL的優(yōu)化改造，當(dāng)然這個(gè)遷移一次性的，當(dāng)架構(gòu)遷移完成之后，就無需再關(guān)心數(shù)據(jù)庫(kù)擴(kuò)容和數(shù)據(jù)遷移問題，因?yàn)榉植际綌?shù)據(jù)庫(kù)的服務(wù)層已經(jīng)集成了擴(kuò)容功能，架構(gòu)上支持水平能力擴(kuò)展。

　　2006年之前我們的核心應(yīng)用普遍采用Oracle數(shù)據(jù)庫(kù)，但隨著業(yè)務(wù)快速發(fā)展，淘寶的數(shù)據(jù)量和訪問量急劇增加，數(shù)據(jù)庫(kù)出現(xiàn)嚴(yán)重訪問性能問題，導(dǎo)致數(shù)據(jù)庫(kù)頻繁宕機(jī)、業(yè)務(wù)停滯，即使當(dāng)時(shí)已經(jīng)使用Oracle亞洲最大的RAC集群，單機(jī)數(shù)據(jù)庫(kù)的擴(kuò)展能力已經(jīng)達(dá)到極限，且需要付出巨大的資金和運(yùn)維成本，因此我們基于自己的實(shí)際情況，逐步開始去IOE，研發(fā)分布式關(guān)系型數(shù)據(jù)庫(kù)服務(wù)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的高擴(kuò)展和成本可控，目前DRDS已經(jīng)成為我們內(nèi)部分布式數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)，并且對(duì)外服務(wù)于金融、制造、政府機(jī)構(gòu)、電商、社交等各行業(yè)。

　　DRDS的整體架構(gòu)

　　DRDS/TDDL是典型的水平擴(kuò)展分布式數(shù)據(jù)庫(kù)模型，區(qū)別于傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù)share anything架構(gòu)，DRDS/TDDL采用share nothing架構(gòu)，share nothing架構(gòu)核心思路利用普通的服務(wù)器，將單機(jī)數(shù)據(jù)拆分到底層的多個(gè)數(shù)據(jù)庫(kù)實(shí)例上，通過統(tǒng)一的Proxy集群進(jìn)行SQL解析優(yōu)化、路由和結(jié)果聚合，對(duì)外暴露簡(jiǎn)單唯一的數(shù)據(jù)庫(kù)鏈接。整體架構(gòu)如圖1所示，包含DRDS服務(wù)模塊、DRDS管控模塊、配置中心、監(jiān)控運(yùn)維、數(shù)據(jù)庫(kù)服務(wù)集群、域名服務(wù)模塊。

圖 1

　　通過分布式集群管理模塊實(shí)現(xiàn)對(duì)集群節(jié)點(diǎn)的管控。在數(shù)據(jù)安全和服務(wù)可用性方面，通過高效的數(shù)據(jù)同步系統(tǒng)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的擴(kuò)容和數(shù)據(jù)庫(kù)實(shí)例的主備數(shù)據(jù)同步。同時(shí)依賴實(shí)例監(jiān)控模塊和HA模塊實(shí)現(xiàn)主備的監(jiān)控和自動(dòng)化容災(zāi)切換。作為成熟的分布式數(shù)據(jù)庫(kù)產(chǎn)品，TDDL也具備完善的運(yùn)維管控系統(tǒng)，能夠?qū)崿F(xiàn)分布式數(shù)據(jù)庫(kù)多實(shí)例之間的配置管理、變更，以及各種數(shù)據(jù)同步、擴(kuò)容等任務(wù)管理，降低運(yùn)維成本。

　　DRDS/TDDL的功能特性

　　數(shù)據(jù)分片

　　DRDS的基礎(chǔ)原理就是Sharding，也就是數(shù)據(jù)分片。將單機(jī)數(shù)據(jù)庫(kù)的數(shù)據(jù)拆分到多個(gè)單機(jī)數(shù)據(jù)庫(kù)上，對(duì)外保持邏輯的一致性。后端拆分的數(shù)據(jù)庫(kù)為分庫(kù)，對(duì)應(yīng)的表稱為分表，每個(gè)分庫(kù)負(fù)責(zé)一份數(shù)據(jù)的讀寫操作，分散整體訪問壓力。在系統(tǒng)擴(kuò)容時(shí)，只需水平增加分庫(kù)數(shù)量，并遷移相關(guān)數(shù)據(jù)，即可提高DRDS系統(tǒng)總體容量。

圖 2

　　數(shù)據(jù)分片需要選擇一個(gè)分片的拆分緯度，也就是數(shù)據(jù)分布的依據(jù)。比如一個(gè)用戶訂單信息表，如果按照訂單ID做數(shù)據(jù)拆分，那么相同訂單ID的數(shù)據(jù)就會(huì)被拆分到同一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)節(jié)點(diǎn)，如果按照用戶ID做數(shù)據(jù)拆分，那么同一個(gè)用戶的訂單就會(huì)分布到同一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)實(shí)例的存儲(chǔ)節(jié)點(diǎn)。

　　拆分緯度的選擇非常重要，一般來說要根據(jù)實(shí)際業(yè)務(wù)的場(chǎng)景選擇拆分鍵，總體指導(dǎo)原則是盡量保證每一個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)量和負(fù)載更均衡，單條SQL操作盡量落到單個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)執(zhí)行，不同SQL的查詢落到不同的數(shù)據(jù)庫(kù)節(jié)點(diǎn)。這樣可以減少多個(gè)節(jié)點(diǎn)之間的網(wǎng)絡(luò)傳輸，保持分布式查詢的效率，均衡負(fù)載的同時(shí)也便于擴(kuò)展。

　　平滑擴(kuò)容

　　數(shù)據(jù)庫(kù)的擴(kuò)容是數(shù)據(jù)庫(kù)運(yùn)維的常見操作，當(dāng)數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)容量不足時(shí)，傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)需要提升單機(jī)的存儲(chǔ)空間來支持更大的數(shù)據(jù)寫入量，而隨著數(shù)據(jù)量膨脹，同樣的SQL查詢語句，查詢的基礎(chǔ)數(shù)據(jù)量增加必然會(huì)降低查詢效率；同時(shí)隨著數(shù)據(jù)量增加，數(shù)據(jù)庫(kù)的訪問壓力通常也會(huì)成倍提升，造成單機(jī)數(shù)據(jù)庫(kù)連接數(shù)到達(dá)極限，此時(shí)單機(jī)數(shù)據(jù)庫(kù)就需要通過升級(jí)硬件規(guī)格，使用磁盤陣列，使用高端的存儲(chǔ)介質(zhì)設(shè)備和更高端的小型機(jī)服務(wù)器來承載數(shù)據(jù)量和訪問量的增加，這個(gè)過程會(huì)伴隨大量的數(shù)據(jù)遷移，為了保證數(shù)據(jù)的一致性通常需要停機(jī)數(shù)據(jù)遷移，對(duì)業(yè)務(wù)影響較大。

圖 3

　　DRDS的分布式架構(gòu)采用平滑擴(kuò)容的方式來解決上述問題，通過增加更多的底層數(shù)據(jù)庫(kù)實(shí)例來完成整體集群擴(kuò)容。

　　平滑擴(kuò)容的前提是用戶需要按照前述的分庫(kù)分表邏輯，將邏輯數(shù)據(jù)庫(kù)拆分為多個(gè)物理分庫(kù)，不同的分庫(kù)落在不同的底層物理數(shù)據(jù)庫(kù)機(jī)器上。分庫(kù)分表的數(shù)量通常建議用戶預(yù)估未來3-5年的數(shù)據(jù)量增長(zhǎng)情況，按照這個(gè)數(shù)據(jù)量計(jì)算總體數(shù)據(jù)應(yīng)該拆分為多少個(gè)分庫(kù)，因?yàn)閱蝹€(gè)分庫(kù)的數(shù)據(jù)量通常會(huì)有一個(gè)建議值，超過這個(gè)閾值就會(huì)造成單個(gè)節(jié)點(diǎn)性能下降。有了具體的分庫(kù)數(shù)量后，就可以按照分庫(kù)的邏輯將數(shù)據(jù)拆分到不同的存儲(chǔ)實(shí)例節(jié)點(diǎn)上，當(dāng)承載分庫(kù)的物理數(shù)據(jù)庫(kù)機(jī)器出現(xiàn)容量和連接數(shù)不足等瓶頸問題時(shí)，就可以新增物理數(shù)據(jù)庫(kù)節(jié)點(diǎn)，將原有的分庫(kù)遷移到新的物理數(shù)據(jù)庫(kù)節(jié)點(diǎn)上，實(shí)現(xiàn)整體邏輯數(shù)據(jù)庫(kù)的擴(kuò)容。

　　擴(kuò)容過程實(shí)際是物理數(shù)據(jù)遷移的過程，引擎層按照分庫(kù)遷移后的邏輯先在物理節(jié)點(diǎn)上建立新的分庫(kù)，然后保留一個(gè)時(shí)間點(diǎn)進(jìn)行全量的數(shù)據(jù)遷移。完成全量遷移后，開始基于先前保留的時(shí)間點(diǎn)進(jìn)行增量的數(shù)據(jù)追趕。當(dāng)增量數(shù)據(jù)追趕到兩邊的數(shù)據(jù)幾乎一致時(shí)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行瞬時(shí)停寫，將最后的數(shù)據(jù)追平，引擎層進(jìn)行分庫(kù)邏輯的路由切換，路由規(guī)則切換完成后就完成了核心的擴(kuò)容邏輯，整個(gè)切換過程在毫秒級(jí)別完成。

　　為了保證數(shù)據(jù)本身的安全，便于擴(kuò)容回滾，在路由規(guī)格切換完成后，遷移前后的邏輯分庫(kù)數(shù)據(jù)還會(huì)進(jìn)行實(shí)時(shí)同步，直到業(yè)務(wù)確認(rèn)后，才可清理原有分庫(kù)數(shù)據(jù)。

　　整個(gè)擴(kuò)容過程對(duì)上層的業(yè)務(wù)訪問幾乎無感知，是完全平滑的擴(kuò)容，但仍需注意擴(kuò)容的操作盡量選擇在數(shù)據(jù)庫(kù)訪問，尤其是寫入的低谷期進(jìn)行，避免切換時(shí)過多的數(shù)據(jù)追趕時(shí)間。

　　分布式MySQL執(zhí)行引擎

　　分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)有規(guī)律地存儲(chǔ)在多個(gè)底層存儲(chǔ)實(shí)例上，數(shù)據(jù)物理存儲(chǔ)的變化會(huì)造成與原生的數(shù)據(jù)庫(kù)引擎不兼容，單機(jī)數(shù)據(jù)庫(kù)所有的數(shù)據(jù)讀取、寫入、計(jì)算都在單一的物理機(jī)上執(zhí)行，數(shù)據(jù)狀態(tài)維持在單機(jī)上，主要的性能消耗在于磁盤的數(shù)據(jù)讀??；而分布式架構(gòu)下，數(shù)據(jù)和狀態(tài)需要在多個(gè)數(shù)據(jù)庫(kù)實(shí)例之間以及底層實(shí)例和Proxy之間進(jìn)行傳輸，這會(huì)造成網(wǎng)絡(luò)I/O消耗，而網(wǎng)絡(luò)I/O對(duì)性能造成消耗相較于本地磁盤I/O和本地計(jì)算的性能開銷而言要大得多。

　　因此分布式SQL引擎主要目標(biāo)是實(shí)現(xiàn)與單機(jī)數(shù)據(jù)庫(kù)SQL引擎的完全兼容，實(shí)現(xiàn)SQL的智能下推。能夠智能分析SQL，解析出哪些SQL可以直接下發(fā)，哪些SQL需要進(jìn)行優(yōu)化改造，優(yōu)化成什么樣，以及路由到哪些實(shí)例節(jié)點(diǎn)上執(zhí)行，充分發(fā)揮數(shù)據(jù)庫(kù)實(shí)例的全部能力，減少網(wǎng)絡(luò)之間的數(shù)據(jù)傳輸量，最終對(duì)不同實(shí)例處理后的少量結(jié)果數(shù)據(jù)進(jìn)行聚合計(jì)算返回給應(yīng)用調(diào)用方。這就是分布式SQL引擎的智能下推功能。

　　分布式引擎的職責(zé)包含SQL解析、優(yōu)化、執(zhí)行和合并四個(gè)流程，如圖4所示。

圖 4

　　智能下核心原則有如下幾個(gè)：

　　1.減少網(wǎng)絡(luò)傳輸；

　　2.減少計(jì)算量，盡量將計(jì)算下推到下層的數(shù)據(jù)節(jié)點(diǎn)上，讓計(jì)算在數(shù)據(jù)所在的機(jī)器上執(zhí)行；

　　3.充分發(fā)揮下層存儲(chǔ)的全部能力。

　　基于以上原則實(shí)現(xiàn)的SQL引擎，就可以做到服務(wù)能力線性擴(kuò)展。比如一個(gè)簡(jiǎn)單的AVG操作，對(duì)于一些比較初級(jí)的分布式數(shù)據(jù)庫(kù)模型而言，常見做法是把AVG直接下發(fā)到所有的存儲(chǔ)節(jié)點(diǎn)，這樣造成的結(jié)果就是語法兼容，語意不兼容，最終拿到的是錯(cuò)誤結(jié)果。而DRDS的智能下推引擎，對(duì)SQL的語法做充分的語意兼容性適配，針對(duì)AVG操作，只能由引擎將邏輯AVG SQL解析優(yōu)化為SUM和COUNT的SQL然后進(jìn)行下推，由底層的數(shù)據(jù)庫(kù)實(shí)例節(jié)點(diǎn)完成SUM和COUNT計(jì)算，充分利用底層節(jié)點(diǎn)的計(jì)算能力，在引擎層將各個(gè)存儲(chǔ)節(jié)點(diǎn)的SUM和COUNT結(jié)果聚合計(jì)算，最終計(jì)算出AVG。這只是一個(gè)非常典型的案例，在分布式數(shù)據(jù)庫(kù)模型下，多數(shù)據(jù)表的Join操作，歸并排序的兼容性非常復(fù)雜，下文會(huì)針對(duì)典型的場(chǎng)景解析TDDL/DRDS如何解決分布式場(chǎng)景下的具體問題。

　　彈性擴(kuò)展

　　TDDL/DRDS采用服務(wù)和存儲(chǔ)分離的架構(gòu)，DRDS實(shí)例服務(wù)層通過集群方式部署，由多個(gè)服務(wù)節(jié)點(diǎn)構(gòu)成一個(gè)服務(wù)實(shí)例，通過負(fù)載均衡以及域名服務(wù)對(duì)外提供服務(wù)，多個(gè)服務(wù)節(jié)點(diǎn)之間無狀態(tài)同步，平均負(fù)載處理用戶請(qǐng)求。服務(wù)集群處理能力不足時(shí)，可隨時(shí)擴(kuò)充服務(wù)節(jié)點(diǎn)，增加服務(wù)處理能力。同樣，業(yè)務(wù)低谷期也可適當(dāng)降低集群規(guī)模，做到彈性的服務(wù)能力擴(kuò)展。

　　對(duì)于一些大數(shù)據(jù)量OLAP的場(chǎng)景，對(duì)于單個(gè)Server節(jié)點(diǎn)的內(nèi)存資源需求高時(shí)，也可通過提升單個(gè)Server節(jié)點(diǎn)的規(guī)格，做到垂直的能力擴(kuò)展。

圖 5

　　分布式Join和小表廣播

　　分布式場(chǎng)景下的Join操作和單機(jī)不同，單機(jī)數(shù)據(jù)的Jion操作發(fā)生在單機(jī)上，不存在內(nèi)部網(wǎng)絡(luò)數(shù)據(jù)傳輸。

　　在分布式架構(gòu)下的多個(gè)數(shù)據(jù)表Jion，如果參與Join的多表數(shù)據(jù)切分緯度不同，數(shù)據(jù)則按照不同的拆分緯度分散在不同的數(shù)據(jù)庫(kù)實(shí)例上，Join操作可能產(chǎn)生跨多個(gè)物理分庫(kù)的Join，就需要進(jìn)行多個(gè)底層實(shí)例的大量數(shù)據(jù)傳輸，SQL的執(zhí)行效率就得不到保證，因此要參與Join操作的數(shù)據(jù)表要盡量保持拆分緯度統(tǒng)一，讓Join操作盡量發(fā)生在單機(jī)上，減少跨庫(kù)Join。如果不能保持拆分緯度的統(tǒng)一，存在跨庫(kù)Join操作，那么原則就是盡量減少Join操作的輸出傳輸。

圖 6

　　DRDS通常使用的Join算法基于Nested Loop，對(duì)于Join的左右兩個(gè)表，首先從Join的左表（驅(qū)動(dòng)表）取出數(shù)據(jù)，然后將所取出數(shù)據(jù)中Join列的值放到右表并進(jìn)行IN查詢，從而完成Join過程。因此，Join的左表數(shù)據(jù)量越少，DRDS對(duì)右表做IN查詢就次數(shù)就越少，如果右表的數(shù)據(jù)量也很少或建有索引，則Join的速度更快。故而在DRDS中，Join驅(qū)動(dòng)表的選擇對(duì)于Join的優(yōu)化非常重要。

　　而在實(shí)際數(shù)據(jù)庫(kù)場(chǎng)景中，經(jīng)常有一些源信息表，數(shù)據(jù)量較小，更新頻度也很低，這些表無需拆分，類似這些源信息表通常采用單表模式，單表模式下一個(gè)邏輯表的數(shù)據(jù)統(tǒng)一存儲(chǔ)在一個(gè)分庫(kù)中，通常存儲(chǔ)在“0”庫(kù)，將這些表定義為“小表”，而其他業(yè)務(wù)數(shù)據(jù)量大、更新頻率高的表仍舊采用分庫(kù)分表的拆分模式。那這些“小表”和分庫(kù)分表進(jìn)行Join時(shí)，基于Nested Loop算法的原則，小表作為Join的驅(qū)動(dòng)表會(huì)大大減少右表的IN查詢次數(shù)，同時(shí)DRDS提供的小表廣播功能，通過數(shù)據(jù)實(shí)時(shí)復(fù)制，將“小表”的全量數(shù)據(jù)和增量變更實(shí)時(shí)復(fù)制到分庫(kù)分表上，將跨庫(kù)的Join轉(zhuǎn)化為單機(jī)Join操作，減少Server節(jié)點(diǎn)的計(jì)算，降低數(shù)據(jù)在多個(gè)底層實(shí)例之間的傳輸，Jion的效率提升會(huì)非常明顯。

　　異構(gòu)索引

　　異構(gòu)索引是DRDS提升分布式查詢效率的解決方案之一，能夠解決分布式場(chǎng)景下數(shù)據(jù)拆分緯度和數(shù)據(jù)查詢使用緯度不一致導(dǎo)致的低效問題。

圖 7

　　當(dāng)數(shù)據(jù)表被拆分為多個(gè)分庫(kù)分表時(shí)，數(shù)據(jù)在分庫(kù)分表的分布規(guī)則就固定了。但是通常數(shù)據(jù)的業(yè)務(wù)使用場(chǎng)景非常復(fù)雜，如果數(shù)據(jù)的查詢緯度和數(shù)據(jù)拆分分布的規(guī)則一致，單條SQL會(huì)在一個(gè)分庫(kù)分表上執(zhí)行；如果數(shù)據(jù)的查詢使用緯度和數(shù)據(jù)拆分分布的規(guī)格不一致，單條SQL就很有可能在多個(gè)分庫(kù)分表上執(zhí)行，出現(xiàn)跨庫(kù)查詢，跨庫(kù)查詢會(huì)增加網(wǎng)絡(luò)I/O的成本，查詢效率必然下降。

　　解決這個(gè)問題的思路還是分布式數(shù)據(jù)庫(kù)的一貫原則，讓SQL執(zhí)行在單庫(kù)上完成，實(shí)際采用的方式就是用“空間換效率”的方案，也就是將同一份數(shù)據(jù)表，冗余存儲(chǔ)多份，按照不同的業(yè)務(wù)使用場(chǎng)景進(jìn)行拆分，保持拆分緯度和使用緯度統(tǒng)一，而多份數(shù)據(jù)之間會(huì)實(shí)時(shí)數(shù)據(jù)復(fù)制以解決數(shù)據(jù)一致性問題，這就是“異構(gòu)索引”方案。當(dāng)然異構(gòu)索引表不能無限制濫用，過多的異構(gòu)索引表會(huì)影響同步效率，對(duì)源數(shù)據(jù)表造成同步壓力。

　　最佳實(shí)踐

　　分布式SQL優(yōu)化

　　SQL優(yōu)化是數(shù)據(jù)庫(kù)使用和運(yùn)維的日常操作，分布式數(shù)據(jù)庫(kù)針對(duì)SQL的優(yōu)化不僅要考慮磁盤I/O的開銷，更要關(guān)注網(wǎng)絡(luò)I/O開銷。為了優(yōu)化SQL執(zhí)行，其核心的優(yōu)化思想就是減少網(wǎng)絡(luò)I/O。為此，DRDS會(huì)盡量將原本DRDS這一層的工作均衡下發(fā)到其底層的各個(gè)分庫(kù)（如RDS 等）來做。這樣就可以將原本需要走網(wǎng)絡(luò)的I/O開銷轉(zhuǎn)換為單機(jī)的磁盤I/O開銷，從而提升查詢執(zhí)行效率。因此，我們?cè)谑褂肈RDS時(shí)若遇到了慢SQL，則需針對(duì)DRDS的特點(diǎn)將適當(dāng)改寫SQL。

　　首先是條件查詢優(yōu)化，DRDS的數(shù)據(jù)按拆分鍵進(jìn)行水平切分，查詢中若帶上拆分鍵對(duì)于減少SQL在DRDS的執(zhí)行時(shí)間很有意義。查詢條件盡量帶分庫(kù)鍵，就可以讓DRDS根據(jù)分庫(kù)鍵的值將查詢直接路由到特定的分庫(kù)，這有助于避免DRDS做全庫(kù)掃描。含分庫(kù)鍵的條件精度越高，越有助于提高查詢速度，也只有這樣的優(yōu)化才能充分發(fā)揮分布式架構(gòu)查詢的優(yōu)勢(shì)，便于后續(xù)查詢能力的擴(kuò)展。

　　其次針對(duì)Join的優(yōu)化，選擇條件查詢數(shù)據(jù)量少的Join表作為左表（驅(qū)動(dòng)表），降低右表IN查詢的次數(shù)；在數(shù)據(jù)量少且變更量少的“廣播表”參與的Jion操作，將“廣播表”作為驅(qū)動(dòng)表。

　　針對(duì)LIMIT OFFSET、COUNT語句，DRDS實(shí)際SQL執(zhí)行是依次將OFFSET之前的記錄數(shù)據(jù)讀取出來，并丟棄，只保留OFFSET之后的數(shù)據(jù)，這樣當(dāng)OFFSET非常大時(shí)，讀取的數(shù)據(jù)記錄數(shù)很少，效率也很低，因?yàn)镺FFSET之前的數(shù)據(jù)讀取需要執(zhí)行大量的磁盤I/O讀取操作。優(yōu)化方式是將SQL優(yōu)化為對(duì)key的OFFSET讀取和IN操作兩個(gè)步驟，先讀取OFFSET之后的記錄key，內(nèi)存中緩存這些key，然后再通過IN查詢獲取完整的記錄信息，這樣會(huì)大大減少磁盤I/O，效率提升非常明顯。

　　分布式事務(wù)優(yōu)化

　　分布式數(shù)據(jù)庫(kù)的事務(wù)和SQL查詢優(yōu)化的邏輯是一樣的原則，盡量讓事務(wù)在單庫(kù)中執(zhí)行，只有在單庫(kù)中執(zhí)行，才可以在保持事務(wù)ACID特性的同時(shí)，還能線性地?cái)U(kuò)展事務(wù)能力。這種單庫(kù)事務(wù)通常稱為“強(qiáng)事務(wù)”。

　　實(shí)際業(yè)務(wù)也經(jīng)常會(huì)面臨分布式數(shù)據(jù)庫(kù)架構(gòu)下，數(shù)據(jù)庫(kù)事務(wù)不可避免出現(xiàn)跨庫(kù)執(zhí)行?？鐜?kù)事務(wù)必然涉及到一個(gè)事務(wù)在多個(gè)分庫(kù)上進(jìn)行事務(wù)分支的執(zhí)行和狀態(tài)同步，相比單機(jī)事務(wù)，分布式跨庫(kù)事務(wù)的吞吐量和延遲會(huì)大大增加。而事務(wù)涉及的分庫(kù)越多，事務(wù)邊界越大，事務(wù)的延遲也會(huì)相應(yīng)增加，性能就會(huì)出現(xiàn)線性衰減。

　　遇到跨庫(kù)事務(wù)，通常的實(shí)踐優(yōu)化方式是通過“最終一致”事務(wù)保證事務(wù)執(zhí)行的吞吐量?！白罱K一致”事務(wù)的原理是優(yōu)先保證核心事務(wù)分支的正向執(zhí)行，然后保存事務(wù)中間狀態(tài)，其他事務(wù)分支異步執(zhí)行，執(zhí)行完成后達(dá)到最終的事務(wù)一致，避免跨庫(kù)事務(wù)時(shí)間序列執(zhí)行阻塞，提升事務(wù)吞吐量。如圖8所示，事務(wù)3和事務(wù)5是跨庫(kù)事務(wù)，事務(wù)分支先在左邊庫(kù)進(jìn)行，異步的事務(wù)分支在右邊分庫(kù)執(zhí)行，分別在自己所在的分庫(kù)順序執(zhí)行，最終達(dá)到事務(wù)一致性。

　　單機(jī)數(shù)據(jù)庫(kù)遷移到DRDS的流程

　　單機(jī)數(shù)據(jù)庫(kù)遷移到分布式數(shù)據(jù)庫(kù)要保證的就是業(yè)務(wù)正常運(yùn)轉(zhuǎn)、平滑過渡、減少運(yùn)維，整個(gè)遷移分為三個(gè)步驟。

　　第一步，讀寫保持在原有的數(shù)據(jù)庫(kù)上，數(shù)據(jù)通過復(fù)制機(jī)制寫入分布式數(shù)據(jù)庫(kù)，前提是分布式目標(biāo)庫(kù)表已經(jīng)建好；

　　第二步，驗(yàn)證云上數(shù)據(jù)是否正確，切部分讀取流量到目標(biāo)的分布式數(shù)據(jù)庫(kù)上讀取線上壓力驗(yàn)證（測(cè)試環(huán)境提前驗(yàn)證也可保證）；

　　第三步，業(yè)務(wù)聽寫幾分鐘，讀寫的流量切換到目標(biāo)庫(kù)，數(shù)據(jù)反向復(fù)制到源單機(jī)數(shù)據(jù)庫(kù)，保證隨時(shí)可切換回單機(jī)數(shù)據(jù)庫(kù)，同時(shí)也可做云下數(shù)據(jù)備份。

圖 8

　　未來的發(fā)展

　　DRDS作為分布式數(shù)據(jù)體系中的數(shù)據(jù)庫(kù)服務(wù)中間層，未來會(huì)適配更多底層存儲(chǔ)引擎，在充分利用底存儲(chǔ)節(jié)點(diǎn)的計(jì)算能力的同時(shí)，優(yōu)化本身服務(wù)的計(jì)算能力，解決OLAP場(chǎng)景，成為能夠完整覆蓋OLTP和OLAP以及其他一些數(shù)據(jù)庫(kù)服務(wù)場(chǎng)景的完備的分布式數(shù)據(jù)庫(kù)服務(wù)體系。同時(shí)完備分布式數(shù)據(jù)庫(kù)邏輯層的運(yùn)維支持和分布式強(qiáng)一致事務(wù)的支持。

　　作者：艾樂強(qiáng)，阿里巴巴中間件(Aliware)產(chǎn)品經(jīng)理，2009年加入公司，前期主要負(fù)責(zé)淘寶分布式session框架和淘寶垂直市場(chǎng)的系統(tǒng)設(shè)計(jì)研發(fā)，目前主要負(fù)責(zé)分布式數(shù)據(jù)庫(kù)服務(wù)DRDS的產(chǎn)品設(shè)計(jì)和研發(fā)。

?點(diǎn)此進(jìn)入 阿里云 在數(shù)據(jù)觀的企業(yè)欄目>>>

責(zé)任編輯：王培