編者按：本文來(lái)自微信公眾號(hào)“阿里技術(shù)”（ID：ali_tech），36氪經(jīng)授權(quán)發(fā)布。
寫(xiě)在前面
在京舉行的2017中國(guó)數(shù)據(jù)庫(kù)技術(shù)大會(huì)上，來(lái)自阿里巴巴集團(tuán)研究員張瑞發(fā)表了題為《面向未來(lái)的數(shù)據(jù)庫(kù)體系架構(gòu)的思考》的主題演講，主要介紹了阿里數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì)正在建設(shè)阿里下一代數(shù)據(jù)庫(kù)技術(shù)體系的想法和經(jīng)驗(yàn)，希望能夠把阿里的成果、踩過(guò)的坑以及面向未來(lái)思考介紹給與會(huì)者，為中國(guó)數(shù)據(jù)庫(kù)技術(shù)的發(fā)展出一份力。
如下：
我先介紹一下我自己，我2005年加入阿里一直在做數(shù)據(jù)庫(kù)方面的工作，今天這個(gè)主題是我最近在思考阿里巴巴下一代數(shù)據(jù)庫(kù)體系方面的一些想法，在這里分享給大家，希望能夠拋磚引玉。大家如果能夠在我今天分享后，結(jié)合自己面對(duì)的實(shí)際場(chǎng)景，得到一些體會(huì)，有點(diǎn)想法的話，我今天分享的目的就達(dá)到了。
今天我會(huì)講以下幾方面內(nèi)容：首先講一下我們?cè)趦?nèi)核上的一點(diǎn)創(chuàng)新、數(shù)據(jù)庫(kù)怎么實(shí)現(xiàn)彈性調(diào)度、關(guān)于智能化的思考、最后是曾經(jīng)踩過(guò)的坑和看到未來(lái)的方向。
阿里場(chǎng)景下數(shù)據(jù)庫(kù)所面臨的問(wèn)題
我覺(jué)得是這樣的，因?yàn)榻裉斓陌⒗锇桶彤吘故且粋€(gè)技術(shù)的公司，所以很多時(shí)候我們會(huì)看比如說(shuō)Google或者是一些互聯(lián)網(wǎng)的大的公司，他們?cè)诩夹g(shù)上創(chuàng)新點(diǎn)來(lái)自于哪里？來(lái)自于問(wèn)題。就是說(shuō)今天在座的各位和我是一樣的，你所面對(duì)場(chǎng)景下的問(wèn)題是什么、你看問(wèn)題深度如何決定了你今天創(chuàng)造的創(chuàng)新有多大。
所以今天我們重新看一下阿里面臨的問(wèn)題是什么，相信在座的各位一定也有這樣的想法，阿里所面臨的問(wèn)題不一定是你們的問(wèn)題，但我想說(shuō)今天通過(guò)阿里面臨的問(wèn)題，以及我們看到這些問(wèn)題后所做的事情，期待能夠給大家?guī)?lái)參考，希望大家也能夠看到自己所面臨的問(wèn)題是什么，你將如何思考。
今天數(shù)據(jù)的高可用和強(qiáng)一致是非常重要的，數(shù)據(jù)不一致帶來(lái)的問(wèn)題是非常非常巨大的，大家也用淘寶，也是阿里巴巴一些服務(wù)的用戶，數(shù)據(jù)不一致帶來(lái)的問(wèn)題，每一個(gè)用戶、甚至我的父母都會(huì)關(guān)注這些事情。
第二，今天存儲(chǔ)成本是非常高的，所有的數(shù)據(jù)中心已經(jīng)在用SSD，但數(shù)據(jù)的存儲(chǔ)成本依然是一個(gè)大型企業(yè)面臨的一個(gè)非常大的問(wèn)題，這都是實(shí)實(shí)在在錢(qián)的問(wèn)題。
另外剛才也提到了，數(shù)據(jù)都是有生命周期的，那么數(shù)據(jù)尤其是交易數(shù)據(jù)是有非常明顯的冷和熱的狀態(tài)，大家一定很少看自己一年前在淘寶的購(gòu)買(mǎi)記錄，但是當(dāng)下的購(gòu)買(mǎi)記錄會(huì)去看，那系統(tǒng)就需要經(jīng)常會(huì)去讀它、更新它。
還有一個(gè)特點(diǎn)是今天阿里的業(yè)務(wù)還是相對(duì)簡(jiǎn)單的，比如我們要在OLTP性能上做到極致性。還有一個(gè)阿里巴巴特有的點(diǎn)就是雙十一，雙十一本質(zhì)上是什么，本質(zhì)上就是制造了一個(gè)技術(shù)上非常大的熱點(diǎn)效應(yīng)。這對(duì)我們提出什么樣的需求呢？需求就是一個(gè)極致彈性的能力，數(shù)據(jù)庫(kù)實(shí)際上在這個(gè)方向是非常欠缺的，數(shù)據(jù)庫(kù)怎么樣去做到彈性伸縮是非常難的事情。
最后我想說(shuō)說(shuō)DBA，今天在座的很多人可能都是DBA，我想說(shuō)一下阿里在智能化這個(gè)方向上得到的思考是什么樣的，我們有海量的數(shù)據(jù)，我們也有很多經(jīng)驗(yàn)很豐富的DBA，但這些DBA怎么樣去完成下一步的轉(zhuǎn)型、怎么樣不成為業(yè)務(wù)的瓶頸？數(shù)據(jù)庫(kù)怎么樣做到自診斷、自優(yōu)化。這是我們看到的問(wèn)題，最后我也會(huì)來(lái)分享一下我在這方面的思考。
阿里在數(shù)據(jù)庫(kù)內(nèi)核方向上的思考
我先講一下我們?cè)跀?shù)據(jù)庫(kù)內(nèi)核上的思考。首先我很尊敬做國(guó)產(chǎn)數(shù)據(jù)庫(kù)的廠商，凡是在內(nèi)核上改進(jìn)的人都知道，其實(shí)每個(gè)功能都是要一行行代碼寫(xiě)出來(lái)都是非常不容易的，我想表達(dá)對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商包括這些技術(shù)人的尊敬。今天我要講的內(nèi)容是我第一次在國(guó)內(nèi)的會(huì)議上來(lái)講，首先我會(huì)講一下AliSQL X-Cluster。X-Cluster是在AliSQL上做的一個(gè)三節(jié)點(diǎn)集群，這是我們?cè)谝肓薖axos一致性協(xié)議，保證MySQL變成一個(gè)集群，并且這個(gè)集群具有數(shù)據(jù)強(qiáng)一致、面向異地部署，且能夠容忍網(wǎng)絡(luò)高延遲等一系列特性。
所以說(shuō)現(xiàn)在的數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)上Paxos的應(yīng)用非常廣泛，今天外面很多展商包括Goolge Spanser也都在用Paxos協(xié)議和數(shù)據(jù)庫(kù)結(jié)合在一起來(lái)做。所以AliSQL的三節(jié)點(diǎn)集群也是一樣，就是利用Paxos協(xié)議變成一個(gè)數(shù)據(jù)強(qiáng)一致的集群。下面我大概解釋一下Paxos協(xié)議在數(shù)據(jù)庫(kù)里的作用是什么。
我們的目標(biāo)是什么？首先沒(méi)有辦法抗拒物理時(shí)延，過(guò)去在數(shù)據(jù)庫(kù)上的操作只要提交到本地，但現(xiàn)在數(shù)據(jù)庫(kù)全球部署、異地部署，甚至跨網(wǎng)絡(luò)，這個(gè)時(shí)延特性是沒(méi)有辦法克服的，但是在這種情況下我們能做到什么？在時(shí)延增長(zhǎng)情況下盡可能保證吞吐不下降，原來(lái)做多少Q(mào)PS、TPS，這一點(diǎn)是可以保證的，只要工程做的好是可以保證的，但是時(shí)延一定會(huì)提升。
這也是大家經(jīng)常在Goolgle Spanser論文里看到的“我的時(shí)延很高”的描述，在這種時(shí)延很高的情況下，怎么樣寫(xiě)一個(gè)好的應(yīng)用來(lái)保證可用、高吞吐，這是另外一個(gè)話題。大家很長(zhǎng)一段時(shí)間里已經(jīng)習(xí)慣一個(gè)概念，那就是數(shù)據(jù)庫(kù)一定是時(shí)延很低的，時(shí)延高就會(huì)導(dǎo)致應(yīng)用出問(wèn)題，實(shí)際上這個(gè)問(wèn)題要花另外一個(gè)篇幅去講，那就是應(yīng)用程序必須要去適應(yīng)這種時(shí)延高的數(shù)據(jù)庫(kù)系統(tǒng)。當(dāng)然用了Batching和Pipelining技術(shù)，本質(zhì)上是通用的工程優(yōu)化，讓跨網(wǎng)絡(luò)多復(fù)本同步變的高效，但是時(shí)延一定會(huì)增加。
實(shí)際上大家知道數(shù)據(jù)庫(kù)要做三副本或者三節(jié)點(diǎn)，本質(zhì)上就是為了實(shí)現(xiàn)數(shù)據(jù)強(qiáng)一致，而且大家都在這個(gè)方向上做努力，比如Oracle前一段時(shí)間推出的Group replication，也是三節(jié)點(diǎn)技術(shù)，X-Cluster和它的區(qū)別是，我們一開(kāi)始的目標(biāo)就是跨城市，最開(kāi)始設(shè)計(jì)的時(shí)候就認(rèn)為這個(gè)節(jié)點(diǎn)一定要跨非常遠(yuǎn)的距離來(lái)部署的，設(shè)計(jì)之初提出這個(gè)目標(biāo)造成我們?cè)O(shè)計(jì)上、工程實(shí)踐上、包括最終的性能上有比較大的差異。
這里我們也做了一些X-Cluster和Oracle的Group replication的對(duì)比，同城的環(huán)境下我們要比他們好一些；在異地場(chǎng)景下這個(gè)差異就更大了，因?yàn)槲覀儽緛?lái)設(shè)計(jì)的時(shí)候就是面向異地的場(chǎng)景。可能大家也知道，阿里一直在講異地多活的概念，就是IDC之間做異地多活怎么樣能夠做到，所以最開(kāi)始我們?cè)O(shè)計(jì)的就是面向異地的場(chǎng)景做的。
這是一個(gè)典型的X-Cluster在異地多活的場(chǎng)景下怎么做的架構(gòu)圖，這是一個(gè)典型的3城市4份數(shù)據(jù)5份日志架構(gòu)，如果要簡(jiǎn)化且考慮數(shù)據(jù)存儲(chǔ)成本的話，實(shí)際上可以做到3份數(shù)據(jù)5份日志，這樣的話就可以保證城市級(jí)、機(jī)房機(jī)、包括單機(jī)任何的故障都可以避免，并且是零數(shù)據(jù)丟失的，在今天我們可以這么做，且能保證數(shù)據(jù)是零丟失、強(qiáng)一致的。在任何一個(gè)點(diǎn)上的數(shù)據(jù)至少會(huì)被寫(xiě)到另一個(gè)城市的數(shù)據(jù)中心的數(shù)據(jù)庫(kù)里面，這是我們X-Cluster設(shè)計(jì)之初的目標(biāo)，這也是一個(gè)典型的異地多活的架構(gòu)。
那就是很多場(chǎng)景下不需要緩存了，因?yàn)閿?shù)據(jù)庫(kù)+緩存結(jié)構(gòu)基本上是所有業(yè)務(wù)通用的場(chǎng)景，但是緩存的問(wèn)題在于緩存和數(shù)據(jù)庫(kù)里的數(shù)據(jù)永遠(yuǎn)是不一致的，需要一個(gè)同步或者失效機(jī)制來(lái)做這個(gè)事情。使用X-KV后讀的問(wèn)題基本上就能解決掉。這是因?yàn)橐环輸?shù)據(jù)只要通過(guò)這個(gè)接口訪問(wèn)就基本上做到和原來(lái)訪問(wèn)緩存差不多的能力，或者說(shuō)在大部分情況下其實(shí)就不需要緩存了。
第三個(gè)事情我想講一下怎么樣解決冷熱數(shù)據(jù)分離的，我們天然地利用了MySQL的框架，這里就直接拿了MySQL的大圖來(lái)展示，大家可以看到MySQL本質(zhì)上來(lái)說(shuō)就是上面有個(gè)Client，中間有個(gè)Server，底下有個(gè)存儲(chǔ)層，在存儲(chǔ)層里面可以有各種各樣的引擎，所以通過(guò)不同的引擎可以實(shí)現(xiàn)不同的特性。大家今天最常用的就是InnoDB引擎，每個(gè)存儲(chǔ)引擎的特性本質(zhì)上是由其結(jié)構(gòu)造成的。比如InnoDB采用B+ Tree的結(jié)構(gòu)，它帶來(lái)的特性就是相對(duì)來(lái)說(shuō)讀和寫(xiě)都比較均衡，因?yàn)榘l(fā)展了這么多年確實(shí)是比較成熟的。
尤其在穩(wěn)定數(shù)據(jù)庫(kù)的背景下，用戶今天怎么樣才能對(duì)自己的數(shù)據(jù)的冷熱沒(méi)有太多的感覺(jué)，因?yàn)榇蠹铱赡芤仓溃銈円郧耙灿幸恍?shù)據(jù)的分離，但是對(duì)應(yīng)用方來(lái)說(shuō)，需要把數(shù)據(jù)從某個(gè)存儲(chǔ)倒到某個(gè)存儲(chǔ)里，然后再刪掉；或者動(dòng)不動(dòng)DBA去找業(yè)務(wù)開(kāi)發(fā)方說(shuō)你的存儲(chǔ)空間不夠了，占用很多空間，能不能刪一些數(shù)據(jù)或者把這些數(shù)據(jù)導(dǎo)入到成本更低的存儲(chǔ)引擎里。我們經(jīng)常這么干，這里說(shuō)的直白一點(diǎn)，我相信大家都這么干過(guò)。
但是用這種雙引擎結(jié)構(gòu)的話，RocksDB壓縮率高的特性，特別是OLTP行存儲(chǔ)的場(chǎng)景下，能夠給我們帶來(lái)比較大的收益。所以我們可以把這兩個(gè)引擎在MySQL特性下面把它結(jié)合起來(lái)，并且可以利用到比較廉價(jià)的架構(gòu)，尤其是LSM Tree這種架構(gòu)，他對(duì)廉價(jià)的存儲(chǔ)介質(zhì)是比較友好的，因?yàn)樗膶?xiě)都是順序?qū)懙摹＿@就是我們今天在數(shù)據(jù)庫(kù)內(nèi)核上面的一些思考。
數(shù)據(jù)庫(kù)為什么要實(shí)現(xiàn)彈性調(diào)度
第二部分，我想說(shuō)一下數(shù)據(jù)庫(kù)彈性調(diào)度這個(gè)事，大家都知道阿里雙十一，雙十一對(duì)我們來(lái)說(shuō)最大的挑戰(zhàn)就是應(yīng)用程序可能已經(jīng)很容易去做彈性調(diào)度，包括上云、彈性擴(kuò)容和縮容，但是數(shù)據(jù)庫(kù)確實(shí)比較難，我們也在這上面也探索了一段時(shí)間，今天會(huì)把我們的思考分享給大家。
我們先去想數(shù)據(jù)庫(kù)要像應(yīng)用一樣非常簡(jiǎn)單的彈性調(diào)度，那么數(shù)據(jù)庫(kù)要做到什么？我覺(jué)得有兩大前提是必須要做的：1、它必須要放到一個(gè)容器里；2、計(jì)算和存儲(chǔ)必須分離。因?yàn)槿绻?jì)算和存儲(chǔ)本質(zhì)上不分離的話，數(shù)據(jù)庫(kù)基本上沒(méi)有辦法彈性調(diào)度。大家知道計(jì)算資源是很容易被移動(dòng)的，但是存儲(chǔ)資源基本很難在短時(shí)間內(nèi)移動(dòng)它，所以做彈性是非常非常困難的。所以這是兩大基礎(chǔ)條件。
在我們的場(chǎng)景下如果你也碰到這種問(wèn)題的話，那就不是偽命題，我覺(jué)得這個(gè)東西合不合理，更多時(shí)候不是技術(shù)有沒(méi)有正確性，而是在你的場(chǎng)景下是否需要它，所以今天我們就做了兩件事情，第一是把它放到容器里面，我們目前物理機(jī)，VM和Docker都在支持，有一層會(huì)把容器的復(fù)雜性屏蔽掉，數(shù)據(jù)庫(kù)一定要放到容器里。應(yīng)用程序放到容器里很多時(shí)候是為了部署，但是我們把數(shù)據(jù)庫(kù)放容器里就是為了做調(diào)度，因?yàn)閿?shù)據(jù)庫(kù)本身沒(méi)有特別多的發(fā)布，不需要像應(yīng)用一樣做頻繁發(fā)布。做了容器化之后，數(shù)據(jù)庫(kù)在一個(gè)物理機(jī)上可以和其他的容器做混部。
我們做DBA的都有一些傳統(tǒng)的觀點(diǎn)，比如數(shù)據(jù)庫(kù)服務(wù)器上肯定不能跑應(yīng)用，數(shù)據(jù)庫(kù)肯定是不能用容器的。不知道在座的各位，每當(dāng)有人或者你的老板問(wèn)你這個(gè)問(wèn)題的時(shí)候，你是不是從來(lái)都是馬上回絕他說(shuō)“數(shù)據(jù)庫(kù)肯定不能這么做”，但是今天你也許可以告訴你的老板可以試一試。
存儲(chǔ)計(jì)算分離，最早做數(shù)據(jù)庫(kù)的時(shí)候，存儲(chǔ)和計(jì)算其實(shí)就是分離的，用一個(gè)Oracle的數(shù)據(jù)庫(kù)，用一個(gè)SAN網(wǎng)絡(luò)，底下接一個(gè)存儲(chǔ)，存儲(chǔ)和計(jì)算本身就是分離的，中間用SAN網(wǎng)絡(luò)連起來(lái)。然后演進(jìn)到用Local的盤(pán)，用SSD盤(pán)，用PC做服務(wù)器。，那未來(lái)重新要回到存儲(chǔ)和計(jì)算分離的結(jié)構(gòu)下，今天的網(wǎng)絡(luò)技術(shù)的發(fā)展，不說(shuō)專有網(wǎng)絡(luò)，就說(shuō)通用的25G網(wǎng)絡(luò)，還有RDMA和SPDK等新技術(shù)的使用，讓我們具備了存儲(chǔ)計(jì)算分離的能力，讓數(shù)據(jù)庫(kù)存儲(chǔ)計(jì)算分離的條件已經(jīng)具備。
今天在數(shù)據(jù)庫(kù)上已經(jīng)看到大量?jī)?yōu)化的特性可以減少I(mǎi)O，可以把離散的IO變成順序的IO，可以對(duì)下層的存儲(chǔ)做的很友好。從存儲(chǔ)成本上來(lái)說(shuō)，共享存儲(chǔ)會(huì)極大的降低成本，是因?yàn)榇鎯?chǔ)碎片會(huì)被極大地壓縮，因?yàn)樵瓉?lái)每個(gè)機(jī)器上都空閑30%、50%的空間，其他的機(jī)器是很難利用到的，當(dāng)你今天把這些碎片變成一個(gè)Pool的時(shí)候是有很大收益的。
還有數(shù)據(jù)庫(kù)未來(lái)如果采用存儲(chǔ)和計(jì)算分離的話，就會(huì)打破目前主流的數(shù)據(jù)庫(kù)一主一備的架構(gòu)，這個(gè)架構(gòu)至少有一半的計(jì)算資源是被完全浪費(fèi)的，不管你的備庫(kù)是否用來(lái)做報(bào)表或者其他的應(yīng)用，但是基本是浪費(fèi)的。如果可以做到共享存儲(chǔ)，那這將是一個(gè)巨大的收益。這是我們?cè)谡{(diào)度上的思考，明天分會(huì)場(chǎng)上也會(huì)有一個(gè)阿里同學(xué)就這個(gè)主題給大家做容器和存儲(chǔ)資源上的細(xì)節(jié)介紹，我今天只講了一個(gè)大概。
DBA未來(lái)的工作內(nèi)容是什么？
最后講一下DBA的事情，剛才也在說(shuō)，我這里說(shuō)從自動(dòng)化走向智能化，我們內(nèi)部講從自助化走向智能化，不知道大家是不是受到一個(gè)困擾，業(yè)務(wù)發(fā)展的速度遠(yuǎn)遠(yuǎn)大于DBA人數(shù)的增長(zhǎng)，如果你沒(méi)有后面的這些我可以不講了，但是如果你有，你可以聽(tīng)一下我們?cè)谶@方面的思考，我們也碰到同樣的問(wèn)題，DBA要怎么樣的發(fā)展，自動(dòng)化的下一步應(yīng)該做什么，很多人說(shuō)DBA是不是會(huì)被淘汰掉，至少我們想清楚了這些問(wèn)題之后，阿里的DBA不糾結(jié)這個(gè)事情，所以我今天跟大家分享一下這個(gè)思考。
首先我們今天做了一個(gè)事情，我們放棄了原來(lái)的思路，原來(lái)的思路是什么呢？最早的時(shí)候我們每個(gè)上線的SQL都需要DBA看一下；第二個(gè)階段，我們做了一個(gè)系統(tǒng)，在每個(gè)SQL上線之前系統(tǒng)都要預(yù)估一下它的性能好不好，如果好才上線。所有我們今天覺(jué)得最大的變化和思考是什么？所有基于單條語(yǔ)句的優(yōu)化都是沒(méi)有特別多意義的，因?yàn)橹挥谢诖蟮臄?shù)據(jù)和計(jì)算，才有可能變成一個(gè)智能化的東西，否則都是基于規(guī)則的。
基于規(guī)則的系統(tǒng)是很難有特別長(zhǎng)久的生命力，因?yàn)橛杏肋h(yuǎn)寫(xiě)不完的規(guī)則。我們也曾經(jīng)做過(guò)這樣的嘗試，一些SQL進(jìn)來(lái)的時(shí)候，系統(tǒng)要對(duì)它進(jìn)行一些判斷，最后發(fā)現(xiàn)永遠(yuǎn)寫(xiě)不完的規(guī)則。所以后來(lái)我們就找到了另外一個(gè)方向，我相信今天在座的所有人，你所在的公司不論大小都都有一個(gè)監(jiān)控系統(tǒng)，我們就從這個(gè)監(jiān)控系統(tǒng)出發(fā)，怎么樣把一個(gè)監(jiān)控系統(tǒng)變成一個(gè)智能的優(yōu)化引擎，我們?cè)谶@里也不說(shuō)是大腦，就說(shuō)是引擎好了。這個(gè)引擎會(huì)做什么？
就像Facebook在做監(jiān)控產(chǎn)品時(shí)產(chǎn)生的時(shí)序數(shù)據(jù)庫(kù)一樣，今天我們產(chǎn)生的副產(chǎn)品也是在時(shí)序數(shù)據(jù)庫(kù)方面帶來(lái)壓力，這個(gè)具體的我今天先不展開(kāi)。我們采集每一條SQL的運(yùn)行情況，因?yàn)槲覀冊(cè)趦?nèi)核里做了改進(jìn)，可以把每條SQL的來(lái)源、路徑、以及它在數(shù)據(jù)庫(kù)里所有的信息全部采集下來(lái)。把監(jiān)控指標(biāo)壓到秒級(jí)，所有監(jiān)控項(xiàng)的指標(biāo)必須最小達(dá)到秒級(jí)，這是我們現(xiàn)有的技術(shù)能夠做到的。
另外，我們把應(yīng)用端日志和數(shù)據(jù)庫(kù)結(jié)合在一起。原來(lái)做數(shù)據(jù)庫(kù)的時(shí)候，應(yīng)用方吼一嗓子說(shuō)“數(shù)據(jù)庫(kù)有沒(méi)有問(wèn)題啊”DBA說(shuō)沒(méi)有問(wèn)題。但是從應(yīng)用那端看，其實(shí)看到數(shù)據(jù)庫(kù)有很多問(wèn)題，包括應(yīng)用報(bào)錯(cuò)，包括響應(yīng)時(shí)間，把應(yīng)用端報(bào)錯(cuò)也要和數(shù)據(jù)庫(kù)結(jié)合在一起，尤其是應(yīng)用里面報(bào)數(shù)據(jù)庫(kù)的錯(cuò)誤，以及這一整條鏈路。
響應(yīng)時(shí)間，只有應(yīng)用端的響應(yīng)時(shí)間才是真正意義上可以衡量一個(gè)數(shù)據(jù)庫(kù)是不是好的指標(biāo)，而不是數(shù)據(jù)庫(kù)本身怎么樣，什么Load低啊，CPU利用率多少。當(dāng)把這些數(shù)據(jù)全部采集下來(lái)之后，這些大量的時(shí)序數(shù)據(jù)我們叫做副產(chǎn)品，這對(duì)我們整個(gè)鏈路產(chǎn)生了一個(gè)巨大的壓力。我們做整個(gè)監(jiān)控系統(tǒng)平臺(tái)的同學(xué)覺(jué)得日子要活不下去了，因?yàn)樵瓉?lái)的存儲(chǔ)系統(tǒng)支撐不了、分析系統(tǒng)支撐不了、原來(lái)的平臺(tái)計(jì)算不出來(lái)。所以先從這個(gè)目標(biāo)考慮，基于鏈路做了巨大的改進(jìn)，包括怎么樣實(shí)現(xiàn)廉價(jià)存儲(chǔ)、怎么樣實(shí)時(shí)分析，這是存儲(chǔ)和計(jì)算的要求。
我們今天這個(gè)目標(biāo)是在阿里內(nèi)部明確提的，我們希望兩到三年內(nèi)希望大部分把DBA的工作替換掉，我不知道兩到三年能不能做到，我希望能做到。其實(shí)今天DBA是這樣的，DBA的工作本質(zhì)上分為兩類，第一類就是運(yùn)維，但運(yùn)維本質(zhì)上來(lái)說(shuō)是比較好解決的，不管是用云，小公司用云全搞定，大公司基本上都有一些自動(dòng)化運(yùn)維的系統(tǒng)。
但是最難解決的就是剛才我說(shuō)的診斷和優(yōu)化。我也了解過(guò)很多公司，比如說(shuō)Google、facebook，我說(shuō)你們?yōu)槭裁礇](méi)有DBA呢？他們說(shuō)我們沒(méi)有DBA，沒(méi)有像國(guó)內(nèi)這種特別傳統(tǒng)的針對(duì)診斷和性能優(yōu)化的DBA，這種職責(zé)很少。所以這個(gè)東西希望能夠做到。
最后我們有了數(shù)據(jù)、有了計(jì)算，我們覺(jué)得未來(lái)的方向可能就是現(xiàn)在比較火的機(jī)器學(xué)習(xí)，這個(gè)主題明天也有一個(gè)阿里同學(xué)會(huì)來(lái)分享，機(jī)器學(xué)習(xí)這里我就不多講了，因?yàn)槲矣X(jué)得我們也在入門(mén)，所以沒(méi)有什么值得講的，但是我們覺(jué)得這個(gè)設(shè)計(jì)挺有戲的，你只要積累足夠的數(shù)據(jù)和計(jì)算的話這個(gè)事情還是挺有戲的。
我們對(duì)數(shù)據(jù)庫(kù)未來(lái)的其他思考
最后一頁(yè)P(yáng)PT我用大白話講一下我對(duì)整個(gè)數(shù)據(jù)庫(kù)體系的一些理解。
這就回到之前的問(wèn)題，我們也走過(guò)一些彎路，數(shù)據(jù)存儲(chǔ)類型越來(lái)越多，今天用這個(gè)明天用那個(gè)，怎么辦？我們的運(yùn)維沒(méi)法搞定，這個(gè)支持很痛苦。
所以今天我們建議建立兩個(gè)平臺(tái)：1、建立一個(gè)支撐的平臺(tái)，這個(gè)支撐的平臺(tái)盡可能把下層存儲(chǔ)的復(fù)雜性屏蔽掉，對(duì)上層提供統(tǒng)一的接口和服務(wù)；2、建立一個(gè)服務(wù)的平臺(tái)，明確面向研發(fā)的平臺(tái)，研發(fā)人員可以直接通過(guò)這個(gè)平臺(tái)來(lái)用數(shù)據(jù)庫(kù)的服務(wù)。我看到很多公司把運(yùn)維平臺(tái)和DBA開(kāi)發(fā)的平臺(tái)混在一起，但阿里的思路是，支撐平臺(tái)和服務(wù)平臺(tái)是兩個(gè)分層的平臺(tái)，支撐平臺(tái)在下面，上層服務(wù)平臺(tái)為所有的開(kāi)發(fā)人員服務(wù)，開(kāi)發(fā)人員上了這個(gè)平臺(tái)就能看到我用了什么數(shù)據(jù)庫(kù)，性能怎么樣，在上面可以做什么事情，這樣就可以大量節(jié)省DBA的人力。
我們內(nèi)部有句開(kāi)玩笑的話叫“不節(jié)省人力的平臺(tái)、不節(jié)省成本的技術(shù)都是耍流氓”，這句話怎么講？就是說(shuō)我們的自動(dòng)化系統(tǒng)，尤其是大公司越建越多，最后的結(jié)果就是人沒(méi)有能力了，我不知道大家有沒(méi)有這個(gè)問(wèn)題，這就是我最后講的一點(diǎn)，自動(dòng)化系統(tǒng)的悖論。每個(gè)公司每個(gè)人今天你們?cè)谧鲎詣?dòng)化系統(tǒng)的過(guò)程中有沒(méi)有發(fā)生一件事情？反正在阿里是發(fā)生了，就是人的能力弱化了。
這個(gè)自動(dòng)化系統(tǒng)的悖論是我們無(wú)意中看到的，在講飛機(jī)的自動(dòng)駕駛的時(shí)候，因?yàn)樽詣?dòng)駕駛做的足夠好，當(dāng)出現(xiàn)緊急問(wèn)題的時(shí)候，飛機(jī)駕駛員反而沒(méi)有足夠的能力去處理緊急的情況，這就是自動(dòng)化系統(tǒng)的悖論。
可以對(duì)比看一下，我們今天做了很多自動(dòng)化系統(tǒng)，結(jié)果人只會(huì)點(diǎn)系統(tǒng)，系統(tǒng)一卡殼就完蛋，很多次生故障都是出現(xiàn)在系統(tǒng)卡殼，卡殼人搞不定，怎么辦？這是今天要去想的問(wèn)題，在這個(gè)過(guò)程中今天所有帶團(tuán)隊(duì)的或者今天在這個(gè)體系的人都要思考的問(wèn)題，我們也在直面這個(gè)問(wèn)題，讓人的能力和系統(tǒng)的能力能夠結(jié)合在一起，這是另外一個(gè)話題，我今天不能給出答案，但是要特別重視這些問(wèn)題。
不要相信那些已經(jīng)過(guò)期的神話，數(shù)據(jù)庫(kù)存儲(chǔ)和計(jì)算是可以分離的，數(shù)據(jù)庫(kù)也是可以放在容器里的，但你真的要去看一下，原來(lái)那些神話或者是那個(gè)背后它的問(wèn)題到底是什么，其實(shí)現(xiàn)在可能都已經(jīng)有解法了，所以在座的各位，當(dāng)你的老板、CTO或者什么人來(lái)問(wèn)你“能不能做到這樣？”我希望你能告訴他“我能！”
我們內(nèi)部有一句話原來(lái)我們的DBA哪里看過(guò)一篇文章，說(shuō)DBA的概念是什么？我印象特別深，有一個(gè)開(kāi)發(fā)的同學(xué)在底下的回復(fù)是說(shuō)“DBA就是一群永遠(yuǎn)在說(shuō)不的人”就是不能這樣不能那樣，我們今天我覺(jué)得未來(lái)我們變成一群永遠(yuǎn)可以說(shuō)“yes”，說(shuō)“可以”的人，謝謝！
張瑞，阿里集團(tuán)數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì)負(fù)責(zé)人，阿里巴巴研究員，Oracle ACE。雙十一數(shù)據(jù)庫(kù)技術(shù)總負(fù)責(zé)人，曾兩次擔(dān)任雙十一技術(shù)保障總負(fù)責(zé)人。自2005年加入阿里巴巴以來(lái)，一直主導(dǎo)整個(gè)阿里數(shù)據(jù)庫(kù)技術(shù)的不斷革新。
編者按：本文來(lái)自微信公眾號(hào)“阿里技術(shù)”（ID：ali_tech），36氪經(jīng)授權(quán)發(fā)布。
寫(xiě)在前面
在京舉行的2017中國(guó)數(shù)據(jù)庫(kù)技術(shù)大會(huì)上，來(lái)自阿里巴巴集團(tuán)研究員張瑞發(fā)表了題為《面向未來(lái)的數(shù)據(jù)庫(kù)體系架構(gòu)的思考》的主題演講，主要介紹了阿里數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì)正在建設(shè)阿里下一代數(shù)據(jù)庫(kù)技術(shù)體系的想法和經(jīng)驗(yàn)，希望能夠把阿里的成果、踩過(guò)的坑以及面向未來(lái)思考介紹給與會(huì)者，為中國(guó)數(shù)據(jù)庫(kù)技術(shù)的發(fā)展出一份力。
如下：
我先介紹一下我自己，我2005年加入阿里一直在做數(shù)據(jù)庫(kù)方面的工作，今天這個(gè)主題是我最近在思考阿里巴巴下一代數(shù)據(jù)庫(kù)體系方面的一些想法，在這里分享給大家，希望能夠拋磚引玉。大家如果能夠在我今天分享后，結(jié)合自己面對(duì)的實(shí)際場(chǎng)景，得到一些體會(huì)，有點(diǎn)想法的話，我今天分享的目的就達(dá)到了。
今天我會(huì)講以下幾方面內(nèi)容：首先講一下我們?cè)趦?nèi)核上的一點(diǎn)創(chuàng)新、數(shù)據(jù)庫(kù)怎么實(shí)現(xiàn)彈性調(diào)度、關(guān)于智能化的思考、最后是曾經(jīng)踩過(guò)的坑和看到未來(lái)的方向。
阿里場(chǎng)景下數(shù)據(jù)庫(kù)所面臨的問(wèn)題
首先說(shuō)一下，阿里巴巴最早一代使用的數(shù)據(jù)庫(kù)技術(shù)是Oracle，后面大家也知道一件事情就是去IOE，去IOE過(guò)程中我們邁向了使用開(kāi)源數(shù)據(jù)庫(kù)的時(shí)代，這個(gè)時(shí)代今天已經(jīng)過(guò)去，這個(gè)過(guò)程大概持續(xù)了五六年，整個(gè)阿里巴巴有一個(gè)大家都知道的開(kāi)源MYSQL分支--AliSQL，我們?cè)谏厦孀隽舜罅康母倪M(jìn)，所以我這里列了一下在AliSQL上的一些改進(jìn)，但今天我實(shí)際上并不想講這個(gè)，我想講一下面向未來(lái)的下一代數(shù)據(jù)庫(kù)技術(shù)、數(shù)據(jù)庫(kù)架構(gòu)會(huì)往哪個(gè)方向走。
我覺(jué)得是這樣的，因?yàn)榻裉斓陌⒗锇桶彤吘故且粋€(gè)技術(shù)的公司，所以很多時(shí)候我們會(huì)看比如說(shuō)Google或者是一些互聯(lián)網(wǎng)的大的公司，他們?cè)诩夹g(shù)上創(chuàng)新點(diǎn)來(lái)自于哪里？來(lái)自于問(wèn)題。就是說(shuō)今天在座的各位和我是一樣的，你所面對(duì)場(chǎng)景下的問(wèn)題是什么、你看問(wèn)題深度如何決定了你今天創(chuàng)造的創(chuàng)新有多大。
所以今天我們重新看一下阿里面臨的問(wèn)題是什么，相信在座的各位一定也有這樣的想法，阿里所面臨的問(wèn)題不一定是你們的問(wèn)題，但我想說(shuō)今天通過(guò)阿里面臨的問(wèn)題，以及我們看到這些問(wèn)題后所做的事情，期待能夠給大家?guī)?lái)參考，希望大家也能夠看到自己所面臨的問(wèn)題是什么，你將如何思考。
可以看到其實(shí)阿里巴巴的應(yīng)用和Facebook、Google的還是有很大區(qū)別的，我們也找他們做了交流，發(fā)現(xiàn)跟他們的業(yè)務(wù)場(chǎng)景真的不一樣，首先我們的主要應(yīng)用是交易型的，這些應(yīng)用會(huì)有些什么要求，你會(huì)看到有這些點(diǎn)（見(jiàn)圖片），下面主要講一下我們的思考。
今天數(shù)據(jù)的高可用和強(qiáng)一致是非常重要的，數(shù)據(jù)不一致帶來(lái)的問(wèn)題是非常非常巨大的，大家也用淘寶，也是阿里巴巴一些服務(wù)的用戶，數(shù)據(jù)不一致帶來(lái)的問(wèn)題，每一個(gè)用戶、甚至我的父母都會(huì)關(guān)注這些事情。
第二，今天存儲(chǔ)成本是非常高的，所有的數(shù)據(jù)中心已經(jīng)在用SSD，但數(shù)據(jù)的存儲(chǔ)成本依然是一個(gè)大型企業(yè)面臨的一個(gè)非常大的問(wèn)題，這都是實(shí)實(shí)在在錢(qián)的問(wèn)題。
另外剛才也提到了，數(shù)據(jù)都是有生命周期的，那么數(shù)據(jù)尤其是交易數(shù)據(jù)是有非常明顯的冷和熱的狀態(tài)，大家一定很少看自己一年前在淘寶的購(gòu)買(mǎi)記錄，但是當(dāng)下的購(gòu)買(mǎi)記錄會(huì)去看，那系統(tǒng)就需要經(jīng)常會(huì)去讀它、更新它。
還有一個(gè)特點(diǎn)是今天阿里的業(yè)務(wù)還是相對(duì)簡(jiǎn)單的，比如我們要在OLTP性能上做到極致性。還有一個(gè)阿里巴巴特有的點(diǎn)就是雙十一，雙十一本質(zhì)上是什么，本質(zhì)上就是制造了一個(gè)技術(shù)上非常大的熱點(diǎn)效應(yīng)。這對(duì)我們提出什么樣的需求呢？需求就是一個(gè)極致彈性的能力，數(shù)據(jù)庫(kù)實(shí)際上在這個(gè)方向是非常欠缺的，數(shù)據(jù)庫(kù)怎么樣去做到彈性伸縮是非常難的事情。
最后我想說(shuō)說(shuō)DBA，今天在座的很多人可能都是DBA，我想說(shuō)一下阿里在智能化這個(gè)方向上得到的思考是什么樣的，我們有海量的數(shù)據(jù)，我們也有很多經(jīng)驗(yàn)很豐富的DBA，但這些DBA怎么樣去完成下一步的轉(zhuǎn)型、怎么樣不成為業(yè)務(wù)的瓶頸？數(shù)據(jù)庫(kù)怎么樣做到自診斷、自優(yōu)化。這是我們看到的問(wèn)題，最后我也會(huì)來(lái)分享一下我在這方面的思考。
阿里在數(shù)據(jù)庫(kù)內(nèi)核方向上的思考
我先講一下我們?cè)跀?shù)據(jù)庫(kù)內(nèi)核上的思考。首先我很尊敬做國(guó)產(chǎn)數(shù)據(jù)庫(kù)的廠商，凡是在內(nèi)核上改進(jìn)的人都知道，其實(shí)每個(gè)功能都是要一行行代碼寫(xiě)出來(lái)都是非常不容易的，我想表達(dá)對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商包括這些技術(shù)人的尊敬。今天我要講的內(nèi)容是我第一次在國(guó)內(nèi)的會(huì)議上來(lái)講，首先我會(huì)講一下AliSQL X-Cluster。X-Cluster是在AliSQL上做的一個(gè)三節(jié)點(diǎn)集群，這是我們?cè)谝肓薖axos一致性協(xié)議，保證MySQL變成一個(gè)集群，并且這個(gè)集群具有數(shù)據(jù)強(qiáng)一致、面向異地部署，且能夠容忍網(wǎng)絡(luò)高延遲等一系列特性。
今天很多數(shù)據(jù)庫(kù)都會(huì)和Paxos聯(lián)系在一起，比如大家都知道的Google的Spanser數(shù)據(jù)庫(kù)，但是以前大家沒(méi)有特別想過(guò)數(shù)據(jù)庫(kù)和Paxos會(huì)有什么關(guān)系，其實(shí)以前確實(shí)沒(méi)有什么關(guān)系的，但是今天的數(shù)據(jù)庫(kù)在幾個(gè)地方是需要用到Paxos協(xié)議的，第一個(gè)我們需要用Paxos來(lái)選舉，尤其在高可用的場(chǎng)景下需要唯一地選舉出一個(gè)節(jié)點(diǎn)作為主節(jié)點(diǎn)，這就需要用到Paxos；第二是用Paxos協(xié)議來(lái)保證數(shù)據(jù)庫(kù)在沒(méi)有共享存儲(chǔ)的前提下數(shù)據(jù)的強(qiáng)一致，就是數(shù)據(jù)怎么樣在多個(gè)節(jié)點(diǎn)間保證是強(qiáng)一致，且保證高可用。
所以說(shuō)現(xiàn)在的數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)上Paxos的應(yīng)用非常廣泛，今天外面很多展商包括Goolge Spanser也都在用Paxos協(xié)議和數(shù)據(jù)庫(kù)結(jié)合在一起來(lái)做。所以AliSQL的三節(jié)點(diǎn)集群也是一樣，就是利用Paxos協(xié)議變成一個(gè)數(shù)據(jù)強(qiáng)一致的集群。下面我大概解釋一下Paxos協(xié)議在數(shù)據(jù)庫(kù)里的作用是什么。
本質(zhì)上來(lái)說(shuō)Paxos也是現(xiàn)在通用的技術(shù)，大家都是搞數(shù)據(jù)庫(kù)的，簡(jiǎn)單來(lái)說(shuō)，Paxos協(xié)議用在我們數(shù)據(jù)庫(kù)里面，就是一個(gè)事務(wù)組的提交在一個(gè)節(jié)點(diǎn)并落地后，必須在多個(gè)節(jié)點(diǎn)同時(shí)落地，也就是說(shuō)原來(lái)寫(xiě)入只需要寫(xiě)入一個(gè)節(jié)點(diǎn)上，但是現(xiàn)在需要跨網(wǎng)絡(luò)寫(xiě)到另外一個(gè)節(jié)點(diǎn)上，這個(gè)節(jié)點(diǎn)可能是異地的，也可能是全球的另外一個(gè)城市，中間需要經(jīng)過(guò)非常漫長(zhǎng)的網(wǎng)絡(luò)時(shí)延，這時(shí)候需要有一些核心技術(shù)。
我們的目標(biāo)是什么？首先沒(méi)有辦法抗拒物理時(shí)延，過(guò)去在數(shù)據(jù)庫(kù)上的操作只要提交到本地，但現(xiàn)在數(shù)據(jù)庫(kù)全球部署、異地部署，甚至跨網(wǎng)絡(luò)，這個(gè)時(shí)延特性是沒(méi)有辦法克服的，但是在這種情況下我們能做到什么？在時(shí)延增長(zhǎng)情況下盡可能保證吞吐不下降，原來(lái)做多少Q(mào)PS、TPS，這一點(diǎn)是可以保證的，只要工程做的好是可以保證的，但是時(shí)延一定會(huì)提升。
這也是大家經(jīng)常在Goolgle Spanser論文里看到的“我的時(shí)延很高”的描述，在這種時(shí)延很高的情況下，怎么樣寫(xiě)一個(gè)好的應(yīng)用來(lái)保證可用、高吞吐，這是另外一個(gè)話題。大家很長(zhǎng)一段時(shí)間里已經(jīng)習(xí)慣一個(gè)概念，那就是數(shù)據(jù)庫(kù)一定是時(shí)延很低的，時(shí)延高就會(huì)導(dǎo)致應(yīng)用出問(wèn)題，實(shí)際上這個(gè)問(wèn)題要花另外一個(gè)篇幅去講，那就是應(yīng)用程序必須要去適應(yīng)這種時(shí)延高的數(shù)據(jù)庫(kù)系統(tǒng)。當(dāng)然用了Batching和Pipelining技術(shù)，本質(zhì)上是通用的工程優(yōu)化，讓跨網(wǎng)絡(luò)多復(fù)本同步變的高效，但是時(shí)延一定會(huì)增加。
實(shí)際上大家知道數(shù)據(jù)庫(kù)要做三副本或者三節(jié)點(diǎn)，本質(zhì)上就是為了實(shí)現(xiàn)數(shù)據(jù)強(qiáng)一致，而且大家都在這個(gè)方向上做努力，比如Oracle前一段時(shí)間推出的Group replication，也是三節(jié)點(diǎn)技術(shù)，X-Cluster和它的區(qū)別是，我們一開(kāi)始的目標(biāo)就是跨城市，最開(kāi)始設(shè)計(jì)的時(shí)候就認(rèn)為這個(gè)節(jié)點(diǎn)一定要跨非常遠(yuǎn)的距離來(lái)部署的，設(shè)計(jì)之初提出這個(gè)目標(biāo)造成我們?cè)O(shè)計(jì)上、工程實(shí)踐上、包括最終的性能上有比較大的差異。
這里我們也做了一些X-Cluster和Oracle的Group replication的對(duì)比，同城的環(huán)境下我們要比他們好一些；在異地場(chǎng)景下這個(gè)差異就更大了，因?yàn)槲覀儽緛?lái)設(shè)計(jì)的時(shí)候就是面向異地的場(chǎng)景。可能大家也知道，阿里一直在講異地多活的概念，就是IDC之間做異地多活怎么樣能夠做到，所以最開(kāi)始我們?cè)O(shè)計(jì)的就是面向異地的場(chǎng)景做的。
這是一個(gè)典型的X-Cluster在異地多活的場(chǎng)景下怎么做的架構(gòu)圖，這是一個(gè)典型的3城市4份數(shù)據(jù)5份日志架構(gòu)，如果要簡(jiǎn)化且考慮數(shù)據(jù)存儲(chǔ)成本的話，實(shí)際上可以做到3份數(shù)據(jù)5份日志，這樣的話就可以保證城市級(jí)、機(jī)房機(jī)、包括單機(jī)任何的故障都可以避免，并且是零數(shù)據(jù)丟失的，在今天我們可以這么做，且能保證數(shù)據(jù)是零丟失、強(qiáng)一致的。在任何一個(gè)點(diǎn)上的數(shù)據(jù)至少會(huì)被寫(xiě)到另一個(gè)城市的數(shù)據(jù)中心的數(shù)據(jù)庫(kù)里面，這是我們X-Cluster設(shè)計(jì)之初的目標(biāo)，這也是一個(gè)典型的異地多活的架構(gòu)。
再講一個(gè)小的，但是非常實(shí)用的創(chuàng)新點(diǎn)，可能大家都比較感興趣，這就是X-KV。這里還要說(shuō)一下，我們所有的下一代技術(shù)組件都是以X開(kāi)頭的。這個(gè)X-KV是基于原來(lái)MYSQL的Memcached plugin做的改進(jìn)，做到非常高的性能，大家可能都了解MySQL的Memcached plugin，可以通過(guò)Memcached plugin的接口直接訪問(wèn)InnoDB buffer 里的數(shù)據(jù)，讀的性能可以做到非常高，這對(duì)于大家來(lái)說(shuō)，或者對(duì)于所謂的架構(gòu)師，或者設(shè)計(jì)的過(guò)程中意義在什么地方呢？
那就是很多場(chǎng)景下不需要緩存了，因?yàn)閿?shù)據(jù)庫(kù)+緩存結(jié)構(gòu)基本上是所有業(yè)務(wù)通用的場(chǎng)景，但是緩存的問(wèn)題在于緩存和數(shù)據(jù)庫(kù)里的數(shù)據(jù)永遠(yuǎn)是不一致的，需要一個(gè)同步或者失效機(jī)制來(lái)做這個(gè)事情。使用X-KV后讀的問(wèn)題基本上就能解決掉。這是因?yàn)橐环輸?shù)據(jù)只要通過(guò)這個(gè)接口訪問(wèn)就基本上做到和原來(lái)訪問(wèn)緩存差不多的能力，或者說(shuō)在大部分情況下其實(shí)就不需要緩存了。
第二是說(shuō)它降低了應(yīng)用的響應(yīng)時(shí)間，原來(lái)用SQL訪問(wèn)的話響應(yīng)時(shí)間會(huì)比較高，我們?cè)谶@上面做了一些改進(jìn)，本來(lái)Memcached plugin插件有一些支持?jǐn)?shù)據(jù)的類型限制，包括對(duì)一些索引類型支持不太好，所以我們做了改進(jìn)，這個(gè)大家都可以用的，如果用這個(gè)方式的話基本上很多緩存系統(tǒng)是不需要的。
第三個(gè)事情我想講一下怎么樣解決冷熱數(shù)據(jù)分離的，我們天然地利用了MySQL的框架，這里就直接拿了MySQL的大圖來(lái)展示，大家可以看到MySQL本質(zhì)上來(lái)說(shuō)就是上面有個(gè)Client，中間有個(gè)Server，底下有個(gè)存儲(chǔ)層，在存儲(chǔ)層里面可以有各種各樣的引擎，所以通過(guò)不同的引擎可以實(shí)現(xiàn)不同的特性。大家今天最常用的就是InnoDB引擎，每個(gè)存儲(chǔ)引擎的特性本質(zhì)上是由其結(jié)構(gòu)造成的。比如InnoDB采用B+ Tree的結(jié)構(gòu)，它帶來(lái)的特性就是相對(duì)來(lái)說(shuō)讀和寫(xiě)都比較均衡，因?yàn)榘l(fā)展了這么多年確實(shí)是比較成熟的。
比如我們現(xiàn)在選擇RocksDB，這是因?yàn)槲覀兒虵acebook在RocksDB上有一些合作，就是把它引入到MySQL上面，它本質(zhì)的結(jié)構(gòu)是LSM Tree，這個(gè)結(jié)構(gòu)就帶來(lái)的好處包括寫(xiě)入比較友好、壓縮的特性好等。把它引入進(jìn)來(lái)對(duì)我們的改革還不僅僅是引入了一個(gè)結(jié)構(gòu)，而是今天我們用這兩種引擎解決我們今天數(shù)據(jù)分離的問(wèn)題。我們也跟Facebook有過(guò)一些交流，RocksDB今天并沒(méi)有那么穩(wěn)定、那么好，但是作為InnoDB存儲(chǔ)引擎的補(bǔ)充的話，是非常有效的。
尤其在穩(wěn)定數(shù)據(jù)庫(kù)的背景下，用戶今天怎么樣才能對(duì)自己的數(shù)據(jù)的冷熱沒(méi)有太多的感覺(jué)，因?yàn)榇蠹铱赡芤仓溃銈円郧耙灿幸恍?shù)據(jù)的分離，但是對(duì)應(yīng)用方來(lái)說(shuō)，需要把數(shù)據(jù)從某個(gè)存儲(chǔ)倒到某個(gè)存儲(chǔ)里，然后再刪掉；或者動(dòng)不動(dòng)DBA去找業(yè)務(wù)開(kāi)發(fā)方說(shuō)你的存儲(chǔ)空間不夠了，占用很多空間，能不能刪一些數(shù)據(jù)或者把這些數(shù)據(jù)導(dǎo)入到成本更低的存儲(chǔ)引擎里。我們經(jīng)常這么干，這里說(shuō)的直白一點(diǎn)，我相信大家都這么干過(guò)。
但是用這種雙引擎結(jié)構(gòu)的話，RocksDB壓縮率高的特性，特別是OLTP行存儲(chǔ)的場(chǎng)景下，能夠給我們帶來(lái)比較大的收益。所以我們可以把這兩個(gè)引擎在MySQL特性下面把它結(jié)合起來(lái)，并且可以利用到比較廉價(jià)的架構(gòu)，尤其是LSM Tree這種架構(gòu)，他對(duì)廉價(jià)的存儲(chǔ)介質(zhì)是比較友好的，因?yàn)樗膶?xiě)都是順序?qū)懙摹＿@就是我們今天在數(shù)據(jù)庫(kù)內(nèi)核上面的一些思考。
數(shù)據(jù)庫(kù)為什么要實(shí)現(xiàn)彈性調(diào)度
第二部分，我想說(shuō)一下數(shù)據(jù)庫(kù)彈性調(diào)度這個(gè)事，大家都知道阿里雙十一，雙十一對(duì)我們來(lái)說(shuō)最大的挑戰(zhàn)就是應(yīng)用程序可能已經(jīng)很容易去做彈性調(diào)度，包括上云、彈性擴(kuò)容和縮容，但是數(shù)據(jù)庫(kù)確實(shí)比較難，我們也在這上面也探索了一段時(shí)間，今天會(huì)把我們的思考分享給大家。
我之前聽(tīng)好多人說(shuō)數(shù)據(jù)庫(kù)容器化是個(gè)偽命題，為什么要做容器化，為什么要把數(shù)據(jù)庫(kù)放到容器里呢？第二也有一些新技術(shù)，比如剛才的分享嘉賓也提到的，把存儲(chǔ)放在遠(yuǎn)端通過(guò)網(wǎng)絡(luò)訪問(wèn)是可能的。但是我們從正向來(lái)思考，先別想數(shù)據(jù)庫(kù)彈性調(diào)度可能不可能，數(shù)據(jù)庫(kù)如果要實(shí)現(xiàn)彈性調(diào)度，它的前提是什么？
我們先去想數(shù)據(jù)庫(kù)要像應(yīng)用一樣非常簡(jiǎn)單的彈性調(diào)度，那么數(shù)據(jù)庫(kù)要做到什么？我覺(jué)得有兩大前提是必須要做的：1、它必須要放到一個(gè)容器里；2、計(jì)算和存儲(chǔ)必須分離。因?yàn)槿绻?jì)算和存儲(chǔ)本質(zhì)上不分離的話，數(shù)據(jù)庫(kù)基本上沒(méi)有辦法彈性調(diào)度。大家知道計(jì)算資源是很容易被移動(dòng)的，但是存儲(chǔ)資源基本很難在短時(shí)間內(nèi)移動(dòng)它，所以做彈性是非常非常困難的。所以這是兩大基礎(chǔ)條件。
在我們的場(chǎng)景下如果你也碰到這種問(wèn)題的話，那就不是偽命題，我覺(jué)得這個(gè)東西合不合理，更多時(shí)候不是技術(shù)有沒(méi)有正確性，而是在你的場(chǎng)景下是否需要它，所以今天我們就做了兩件事情，第一是把它放到容器里面，我們目前物理機(jī)，VM和Docker都在支持，有一層會(huì)把容器的復(fù)雜性屏蔽掉，數(shù)據(jù)庫(kù)一定要放到容器里。應(yīng)用程序放到容器里很多時(shí)候是為了部署，但是我們把數(shù)據(jù)庫(kù)放容器里就是為了做調(diào)度，因?yàn)閿?shù)據(jù)庫(kù)本身沒(méi)有特別多的發(fā)布，不需要像應(yīng)用一樣做頻繁發(fā)布。做了容器化之后，數(shù)據(jù)庫(kù)在一個(gè)物理機(jī)上可以和其他的容器做混部。
我們做DBA的都有一些傳統(tǒng)的觀點(diǎn)，比如數(shù)據(jù)庫(kù)服務(wù)器上肯定不能跑應(yīng)用，數(shù)據(jù)庫(kù)肯定是不能用容器的。不知道在座的各位，每當(dāng)有人或者你的老板問(wèn)你這個(gè)問(wèn)題的時(shí)候，你是不是從來(lái)都是馬上回絕他說(shuō)“數(shù)據(jù)庫(kù)肯定不能這么做”，但是今天你也許可以告訴你的老板可以試一試。
存儲(chǔ)計(jì)算分離，最早做數(shù)據(jù)庫(kù)的時(shí)候，存儲(chǔ)和計(jì)算其實(shí)就是分離的，用一個(gè)Oracle的數(shù)據(jù)庫(kù)，用一個(gè)SAN網(wǎng)絡(luò)，底下接一個(gè)存儲(chǔ)，存儲(chǔ)和計(jì)算本身就是分離的，中間用SAN網(wǎng)絡(luò)連起來(lái)。然后演進(jìn)到用Local的盤(pán)，用SSD盤(pán)，用PC做服務(wù)器。，那未來(lái)重新要回到存儲(chǔ)和計(jì)算分離的結(jié)構(gòu)下，今天的網(wǎng)絡(luò)技術(shù)的發(fā)展，不說(shuō)專有網(wǎng)絡(luò)，就說(shuō)通用的25G網(wǎng)絡(luò)，還有RDMA和SPDK等新技術(shù)的使用，讓我們具備了存儲(chǔ)計(jì)算分離的能力，讓數(shù)據(jù)庫(kù)存儲(chǔ)計(jì)算分離的條件已經(jīng)具備。
今天在數(shù)據(jù)庫(kù)上已經(jīng)看到大量?jī)?yōu)化的特性可以減少I(mǎi)O，可以把離散的IO變成順序的IO，可以對(duì)下層的存儲(chǔ)做的很友好。從存儲(chǔ)成本上來(lái)說(shuō)，共享存儲(chǔ)會(huì)極大的降低成本，是因?yàn)榇鎯?chǔ)碎片會(huì)被極大地壓縮，因?yàn)樵瓉?lái)每個(gè)機(jī)器上都空閑30%、50%的空間，其他的機(jī)器是很難利用到的，當(dāng)你今天把這些碎片變成一個(gè)Pool的時(shí)候是有很大收益的。
還有數(shù)據(jù)庫(kù)未來(lái)如果采用存儲(chǔ)和計(jì)算分離的話，就會(huì)打破目前主流的數(shù)據(jù)庫(kù)一主一備的架構(gòu)，這個(gè)架構(gòu)至少有一半的計(jì)算資源是被完全浪費(fèi)的，不管你的備庫(kù)是否用來(lái)做報(bào)表或者其他的應(yīng)用，但是基本是浪費(fèi)的。如果可以做到共享存儲(chǔ)，那這將是一個(gè)巨大的收益。這是我們?cè)谡{(diào)度上的思考，明天分會(huì)場(chǎng)上也會(huì)有一個(gè)阿里同學(xué)就這個(gè)主題給大家做容器和存儲(chǔ)資源上的細(xì)節(jié)介紹，我今天只講了一個(gè)大概。
DBA未來(lái)的工作內(nèi)容是什么？
最后講一下DBA的事情，剛才也在說(shuō)，我這里說(shuō)從自動(dòng)化走向智能化，我們內(nèi)部講從自助化走向智能化，不知道大家是不是受到一個(gè)困擾，業(yè)務(wù)發(fā)展的速度遠(yuǎn)遠(yuǎn)大于DBA人數(shù)的增長(zhǎng)，如果你沒(méi)有后面的這些我可以不講了，但是如果你有，你可以聽(tīng)一下我們?cè)谶@方面的思考，我們也碰到同樣的問(wèn)題，DBA要怎么樣的發(fā)展，自動(dòng)化的下一步應(yīng)該做什么，很多人說(shuō)DBA是不是會(huì)被淘汰掉，至少我們想清楚了這些問(wèn)題之后，阿里的DBA不糾結(jié)這個(gè)事情，所以我今天跟大家分享一下這個(gè)思考。
首先我們今天做了一個(gè)事情，我們放棄了原來(lái)的思路，原來(lái)的思路是什么呢？最早的時(shí)候我們每個(gè)上線的SQL都需要DBA看一下；第二個(gè)階段，我們做了一個(gè)系統(tǒng)，在每個(gè)SQL上線之前系統(tǒng)都要預(yù)估一下它的性能好不好，如果好才上線。所有我們今天覺(jué)得最大的變化和思考是什么？所有基于單條語(yǔ)句的優(yōu)化都是沒(méi)有特別多意義的，因?yàn)橹挥谢诖蟮臄?shù)據(jù)和計(jì)算，才有可能變成一個(gè)智能化的東西，否則都是基于規(guī)則的。
基于規(guī)則的系統(tǒng)是很難有特別長(zhǎng)久的生命力，因?yàn)橛杏肋h(yuǎn)寫(xiě)不完的規(guī)則。我們也曾經(jīng)做過(guò)這樣的嘗試，一些SQL進(jìn)來(lái)的時(shí)候，系統(tǒng)要對(duì)它進(jìn)行一些判斷，最后發(fā)現(xiàn)永遠(yuǎn)寫(xiě)不完的規(guī)則。所以后來(lái)我們就找到了另外一個(gè)方向，我相信今天在座的所有人，你所在的公司不論大小都都有一個(gè)監(jiān)控系統(tǒng)，我們就從這個(gè)監(jiān)控系統(tǒng)出發(fā)，怎么樣把一個(gè)監(jiān)控系統(tǒng)變成一個(gè)智能的優(yōu)化引擎，我們?cè)谶@里也不說(shuō)是大腦，就說(shuō)是引擎好了。這個(gè)引擎會(huì)做什么？
首先來(lái)說(shuō)，我們已經(jīng)放棄掉基于單條SQL的優(yōu)化，因?yàn)闆](méi)有意義，DBA也沒(méi)有審閱單條SQL，系統(tǒng)去看單條SQL的意義也不大。今天我們的第一個(gè)場(chǎng)景是說(shuō)大量的數(shù)據(jù)，大量的數(shù)據(jù)是什么？我們就從我們的監(jiān)控系統(tǒng)出發(fā)，提出了第一個(gè)目標(biāo)，把每一條運(yùn)行的SQL采集下來(lái)，不是采樣，是每一條。在規(guī)模比較大的系統(tǒng)來(lái)說(shuō)對(duì)存儲(chǔ)來(lái)說(shuō)是個(gè)巨大的壓力，因?yàn)檫@樣會(huì)產(chǎn)生大量的副產(chǎn)品。
就像Facebook在做監(jiān)控產(chǎn)品時(shí)產(chǎn)生的時(shí)序數(shù)據(jù)庫(kù)一樣，今天我們產(chǎn)生的副產(chǎn)品也是在時(shí)序數(shù)據(jù)庫(kù)方面帶來(lái)壓力，這個(gè)具體的我今天先不展開(kāi)。我們采集每一條SQL的運(yùn)行情況，因?yàn)槲覀冊(cè)趦?nèi)核里做了改進(jìn)，可以把每條SQL的來(lái)源、路徑、以及它在數(shù)據(jù)庫(kù)里所有的信息全部采集下來(lái)。把監(jiān)控指標(biāo)壓到秒級(jí)，所有監(jiān)控項(xiàng)的指標(biāo)必須最小達(dá)到秒級(jí)，這是我們現(xiàn)有的技術(shù)能夠做到的。
另外，我們把應(yīng)用端日志和數(shù)據(jù)庫(kù)結(jié)合在一起。原來(lái)做數(shù)據(jù)庫(kù)的時(shí)候，應(yīng)用方吼一嗓子說(shuō)“數(shù)據(jù)庫(kù)有沒(méi)有問(wèn)題啊”DBA說(shuō)沒(méi)有問(wèn)題。但是從應(yīng)用那端看，其實(shí)看到數(shù)據(jù)庫(kù)有很多問(wèn)題，包括應(yīng)用報(bào)錯(cuò)，包括響應(yīng)時(shí)間，把應(yīng)用端報(bào)錯(cuò)也要和數(shù)據(jù)庫(kù)結(jié)合在一起，尤其是應(yīng)用里面報(bào)數(shù)據(jù)庫(kù)的錯(cuò)誤，以及這一整條鏈路。
響應(yīng)時(shí)間，只有應(yīng)用端的響應(yīng)時(shí)間才是真正意義上可以衡量一個(gè)數(shù)據(jù)庫(kù)是不是好的指標(biāo)，而不是數(shù)據(jù)庫(kù)本身怎么樣，什么Load低啊，CPU利用率多少。當(dāng)把這些數(shù)據(jù)全部采集下來(lái)之后，這些大量的時(shí)序數(shù)據(jù)我們叫做副產(chǎn)品，這對(duì)我們整個(gè)鏈路產(chǎn)生了一個(gè)巨大的壓力。我們做整個(gè)監(jiān)控系統(tǒng)平臺(tái)的同學(xué)覺(jué)得日子要活不下去了，因?yàn)樵瓉?lái)的存儲(chǔ)系統(tǒng)支撐不了、分析系統(tǒng)支撐不了、原來(lái)的平臺(tái)計(jì)算不出來(lái)。所以先從這個(gè)目標(biāo)考慮，基于鏈路做了巨大的改進(jìn)，包括怎么樣實(shí)現(xiàn)廉價(jià)存儲(chǔ)、怎么樣實(shí)時(shí)分析，這是存儲(chǔ)和計(jì)算的要求。
我們今天這個(gè)目標(biāo)是在阿里內(nèi)部明確提的，我們希望兩到三年內(nèi)希望大部分把DBA的工作替換掉，我不知道兩到三年能不能做到，我希望能做到。其實(shí)今天DBA是這樣的，DBA的工作本質(zhì)上分為兩類，第一類就是運(yùn)維，但運(yùn)維本質(zhì)上來(lái)說(shuō)是比較好解決的，不管是用云，小公司用云全搞定，大公司基本上都有一些自動(dòng)化運(yùn)維的系統(tǒng)。
但是最難解決的就是剛才我說(shuō)的診斷和優(yōu)化。我也了解過(guò)很多公司，比如說(shuō)Google、facebook，我說(shuō)你們?yōu)槭裁礇](méi)有DBA呢？他們說(shuō)我們沒(méi)有DBA，沒(méi)有像國(guó)內(nèi)這種特別傳統(tǒng)的針對(duì)診斷和性能優(yōu)化的DBA，這種職責(zé)很少。所以這個(gè)東西希望能夠做到。
最后我們有了數(shù)據(jù)、有了計(jì)算，我們覺(jué)得未來(lái)的方向可能就是現(xiàn)在比較火的機(jī)器學(xué)習(xí)，這個(gè)主題明天也有一個(gè)阿里同學(xué)會(huì)來(lái)分享，機(jī)器學(xué)習(xí)這里我就不多講了，因?yàn)槲矣X(jué)得我們也在入門(mén)，所以沒(méi)有什么值得講的，但是我們覺(jué)得這個(gè)設(shè)計(jì)挺有戲的，你只要積累足夠的數(shù)據(jù)和計(jì)算的話這個(gè)事情還是挺有戲的。
我們對(duì)數(shù)據(jù)庫(kù)未來(lái)的其他思考
最后一頁(yè)P(yáng)PT我用大白話講一下我對(duì)整個(gè)數(shù)據(jù)庫(kù)體系的一些理解。
今天在一個(gè)公司里邊沒(méi)有一個(gè)存儲(chǔ)或者是數(shù)據(jù)庫(kù)可以解決所有問(wèn)題，今天越來(lái)越多的趨勢(shì)看到，數(shù)據(jù)存儲(chǔ)的多樣性是必然會(huì)存在的，因?yàn)樾写嬗行写娴膬?yōu)勢(shì)、列存有列存的優(yōu)勢(shì)、做計(jì)算有計(jì)算的優(yōu)勢(shì)、做分析有做分析的優(yōu)勢(shì)、做OLTP有OLTP的優(yōu)勢(shì)，不要指望，或者很難指望一個(gè)系統(tǒng)干所有的事情很，這個(gè)話我說(shuō)了可能不太好，但是確實(shí)比較難，但是我們看到的一點(diǎn)是什么？就是每個(gè)技術(shù)或產(chǎn)品在生產(chǎn)中干一件事情可以干到最好，你就用它做的最好的那件事解你的問(wèn)題就好了。
這就回到之前的問(wèn)題，我們也走過(guò)一些彎路，數(shù)據(jù)存儲(chǔ)類型越來(lái)越多，今天用這個(gè)明天用那個(gè)，怎么辦？我們的運(yùn)維沒(méi)法搞定，這個(gè)支持很痛苦。
所以今天我們建議建立兩個(gè)平臺(tái)：1、建立一個(gè)支撐的平臺(tái)，這個(gè)支撐的平臺(tái)盡可能把下層存儲(chǔ)的復(fù)雜性屏蔽掉，對(duì)上層提供統(tǒng)一的接口和服務(wù)；2、建立一個(gè)服務(wù)的平臺(tái)，明確面向研發(fā)的平臺(tái)，研發(fā)人員可以直接通過(guò)這個(gè)平臺(tái)來(lái)用數(shù)據(jù)庫(kù)的服務(wù)。我看到很多公司把運(yùn)維平臺(tái)和DBA開(kāi)發(fā)的平臺(tái)混在一起，但阿里的思路是，支撐平臺(tái)和服務(wù)平臺(tái)是兩個(gè)分層的平臺(tái)，支撐平臺(tái)在下面，上層服務(wù)平臺(tái)為所有的開(kāi)發(fā)人員服務(wù)，開(kāi)發(fā)人員上了這個(gè)平臺(tái)就能看到我用了什么數(shù)據(jù)庫(kù)，性能怎么樣，在上面可以做什么事情，這樣就可以大量節(jié)省DBA的人力。
我們內(nèi)部有句開(kāi)玩笑的話叫“不節(jié)省人力的平臺(tái)、不節(jié)省成本的技術(shù)都是耍流氓”，這句話怎么講？就是說(shuō)我們的自動(dòng)化系統(tǒng)，尤其是大公司越建越多，最后的結(jié)果就是人沒(méi)有能力了，我不知道大家有沒(méi)有這個(gè)問(wèn)題，這就是我最后講的一點(diǎn)，自動(dòng)化系統(tǒng)的悖論。每個(gè)公司每個(gè)人今天你們?cè)谧鲎詣?dòng)化系統(tǒng)的過(guò)程中有沒(méi)有發(fā)生一件事情？反正在阿里是發(fā)生了，就是人的能力弱化了。
這個(gè)自動(dòng)化系統(tǒng)的悖論是我們無(wú)意中看到的，在講飛機(jī)的自動(dòng)駕駛的時(shí)候，因?yàn)樽詣?dòng)駕駛做的足夠好，當(dāng)出現(xiàn)緊急問(wèn)題的時(shí)候，飛機(jī)駕駛員反而沒(méi)有足夠的能力去處理緊急的情況，這就是自動(dòng)化系統(tǒng)的悖論。
可以對(duì)比看一下，我們今天做了很多自動(dòng)化系統(tǒng)，結(jié)果人只會(huì)點(diǎn)系統(tǒng)，系統(tǒng)一卡殼就完蛋，很多次生故障都是出現(xiàn)在系統(tǒng)卡殼，卡殼人搞不定，怎么辦？這是今天要去想的問(wèn)題，在這個(gè)過(guò)程中今天所有帶團(tuán)隊(duì)的或者今天在這個(gè)體系的人都要思考的問(wèn)題，我們也在直面這個(gè)問(wèn)題，讓人的能力和系統(tǒng)的能力能夠結(jié)合在一起，這是另外一個(gè)話題，我今天不能給出答案，但是要特別重視這些問(wèn)題。
不要相信那些已經(jīng)過(guò)期的神話，數(shù)據(jù)庫(kù)存儲(chǔ)和計(jì)算是可以分離的，數(shù)據(jù)庫(kù)也是可以放在容器里的，但你真的要去看一下，原來(lái)那些神話或者是那個(gè)背后它的問(wèn)題到底是什么，其實(shí)現(xiàn)在可能都已經(jīng)有解法了，所以在座的各位，當(dāng)你的老板、CTO或者什么人來(lái)問(wèn)你“能不能做到這樣？”我希望你能告訴他“我能！”
我們內(nèi)部有一句話原來(lái)我們的DBA哪里看過(guò)一篇文章，說(shuō)DBA的概念是什么？我印象特別深，有一個(gè)開(kāi)發(fā)的同學(xué)在底下的回復(fù)是說(shuō)“DBA就是一群永遠(yuǎn)在說(shuō)不的人”就是不能這樣不能那樣，我們今天我覺(jué)得未來(lái)我們變成一群永遠(yuǎn)可以說(shuō)“yes”，說(shuō)“可以”的人，謝謝！
張瑞，阿里集團(tuán)數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì)負(fù)責(zé)人，阿里巴巴研究員，Oracle ACE。雙十一數(shù)據(jù)庫(kù)技術(shù)總負(fù)責(zé)人，曾兩次擔(dān)任雙十一技術(shù)保障總負(fù)責(zé)人。自2005年加入阿里巴巴以來(lái)，一直主導(dǎo)整個(gè)阿里數(shù)據(jù)庫(kù)技術(shù)的不斷革新。
京公網(wǎng)安備 11010502049343號(hào)