來自 | 阿里云云棲社區(qū)

8 月 24 日，阿里云數(shù)據(jù)庫技術(shù)峰會(huì)到來，本次技術(shù)峰會(huì)邀請(qǐng)到了阿里集團(tuán)和阿里云數(shù)據(jù)庫老司機(jī)們，為大家分享了一線數(shù)據(jù)庫實(shí)踐經(jīng)驗(yàn)和技術(shù)干貨。在本次峰會(huì)上，阿里云數(shù)據(jù)庫高級(jí)產(chǎn)品專家蕭少聰（鐵庵）介紹了全體系阿里云數(shù)據(jù)庫產(chǎn)品并對(duì)于阿里云數(shù)據(jù)庫產(chǎn)品的實(shí)現(xiàn)架構(gòu)進(jìn)行了分享，幫助大家了解了阿里云全數(shù)據(jù)庫產(chǎn)品體系能解決哪些實(shí)用場(chǎng)景的問題，同時(shí)幫助大家了解其解決的原理。** 以下內(nèi)容根據(jù)演講嘉賓現(xiàn)場(chǎng)視頻以及 PPT 整理而成。** 本次分享將主要介紹阿里云是如何設(shè)計(jì)云數(shù)據(jù)庫產(chǎn)品的架構(gòu)的，以及在云數(shù)據(jù)庫產(chǎn)品的架構(gòu)設(shè)計(jì)背后的故事。本次的分享將不會(huì)非常深入技術(shù)底層細(xì)節(jié)，而是希望通過分享使得大家了解在使用云數(shù)據(jù)庫時(shí)應(yīng)該如何去規(guī)劃，以及阿里云在設(shè)計(jì)云數(shù)據(jù)庫產(chǎn)品的時(shí)候存在什么樣的思考。

一、云數(shù)據(jù)庫的市場(chǎng)背景

多產(chǎn)品類型混合

在市場(chǎng)上面，大家可以看到類型非常多樣的數(shù)據(jù)庫產(chǎn)品。如果大家今天還是在使用像 SQL Server 或者 MySQL 這樣單獨(dú)的關(guān)系型數(shù)據(jù)庫，那么可能業(yè)務(wù)所覆蓋的場(chǎng)景還是比較有限的。而往往在一家中型或者比較大型的公司里面，已經(jīng)開始用到很多不同的數(shù)據(jù)庫產(chǎn)品了。

系統(tǒng)架構(gòu)越發(fā)復(fù)雜如上圖所示，通常情況下，在業(yè)務(wù)剛開始的時(shí)候使用的是一個(gè) SQL 數(shù)據(jù)庫或者 NoSQL 數(shù)據(jù)庫，但是隨著業(yè)務(wù)慢慢的發(fā)展就會(huì)用到 Key-Value 的緩存數(shù)據(jù)庫，再之后可能就會(huì)發(fā)展到數(shù)據(jù)倉庫，同時(shí)也可能發(fā)展到大數(shù)據(jù)的系統(tǒng)。接下來為大家介紹一家公司從小型企業(yè)逐步成長為大型企業(yè)的過程中的數(shù)據(jù)庫架構(gòu)設(shè)計(jì)的發(fā)展步驟以及在運(yùn)作過程中每個(gè)階段的數(shù)據(jù)庫演化情況。如下圖所示，在初始階段，整個(gè)數(shù)據(jù)庫架構(gòu)的結(jié)構(gòu)是比較簡單的，圖中僅有 3 臺(tái)服務(wù)器，這意味著公司在剛剛開始的時(shí)候可能只有幾臺(tái)數(shù)據(jù)庫服務(wù)器，它們可能是 SQL 的系統(tǒng)，也可能是 NoSQL 的系統(tǒng)。此時(shí) DBA 以及管理人員不需要去做過多的結(jié)構(gòu)使用分析。然而，在進(jìn)行管理的過程中，DBA 往往會(huì)身兼多職，在這個(gè)時(shí)候的 DBA 可能在管理數(shù)據(jù)庫的同時(shí)也在做開發(fā)以及對(duì)于操作系統(tǒng)的運(yùn)維工作。

更進(jìn)一步，當(dāng)企業(yè)發(fā)展到初具規(guī)模的時(shí)候，數(shù)據(jù)庫往往就不能夠以單節(jié)點(diǎn)的方式去運(yùn)行了，此時(shí)往往需要配合一些集群以及一些其他的數(shù)據(jù)庫。例如在剛剛開始的時(shí)候，只用到了單獨(dú)的 SQL 數(shù)據(jù)庫以及 NoSQL 數(shù)據(jù)庫，但是在系統(tǒng)初具規(guī)模的時(shí)候，可能兩方面的數(shù)據(jù)庫都會(huì)用到，同時(shí)還可能會(huì)用到像 Key-Value 緩存數(shù)據(jù)庫等進(jìn)行混合來實(shí)現(xiàn)整體的數(shù)據(jù)庫業(yè)務(wù)效果。在這個(gè)過程之中，DBA 扮演著非常神奇的角色，此時(shí)的 DBA 不只需要去做普通的 SQL 系統(tǒng)管理，而且還需要管理 NoSQL 以及 Key-Value 數(shù)據(jù)庫，而且很多時(shí)候整體系統(tǒng)監(jiān)控以及系統(tǒng)維護(hù)都需要由 DBA 進(jìn)行完整地支撐，此時(shí)的 DBA 可以稱之為“神奇的 DBA”，因?yàn)樗裁炊夹枰堋?/p>

當(dāng)業(yè)務(wù)進(jìn)一步發(fā)展到下一個(gè)階段時(shí)又會(huì)是什么情況呢？其實(shí)很多公司在剛剛起步時(shí)往往只有一個(gè)項(xiàng)目，當(dāng)公司的業(yè)務(wù)發(fā)展到一定規(guī)模的時(shí)候，項(xiàng)目也會(huì)逐步地增加。因此，每一個(gè)項(xiàng)目都將會(huì)使用一整套數(shù)據(jù)庫結(jié)構(gòu)，而在這個(gè)時(shí)候項(xiàng)目也會(huì)不斷地提升和增長，每個(gè)項(xiàng)目會(huì)使用單獨(dú)整體數(shù)據(jù)庫結(jié)構(gòu)，這時(shí)候的數(shù)據(jù)庫管理員 DBA 就不再是單個(gè)人了，往往會(huì)有 2 到 3 個(gè) DBA，而且他們每個(gè)人應(yīng)該都能夠獨(dú)當(dāng)一面，并且應(yīng)該具有完整的架構(gòu)經(jīng)驗(yàn)。正是在這個(gè)時(shí)候才是對(duì)于企業(yè)的比較大的挑戰(zhàn)，大家都知道在技術(shù)人員的職業(yè)發(fā)展生涯當(dāng)中，技術(shù)人員都是希望能夠承載更多的工作或者讓自己的職業(yè)生涯獲得更大的發(fā)展，所以在這個(gè)過程之中往往能夠形成企業(yè)與技術(shù)人員本身之間認(rèn)知差異的博弈。很多時(shí)候如果企業(yè)發(fā)展的速度跟不上技術(shù)人員的技術(shù)成長速度，技術(shù)人員就很可能嘗試跳槽或者尋找其他的工作，當(dāng)技術(shù)專家離開企業(yè)的時(shí)候，就會(huì)使得企業(yè)的進(jìn)一步發(fā)展受到阻礙。

數(shù)據(jù)庫容災(zāi)：兩地 N 中心在系統(tǒng)架構(gòu)越發(fā)復(fù)雜的情況下，企業(yè)所遇到的不僅是人員的問題，在進(jìn)行數(shù)據(jù)庫架構(gòu)發(fā)展演變的過程當(dāng)中，企業(yè)還會(huì)遇到另外的一個(gè)問題：在業(yè)務(wù)發(fā)展到一定階段之后，往往需要產(chǎn)生更多的數(shù)據(jù)架構(gòu)的邏輯，包括在業(yè)務(wù)要求之下以及在監(jiān)管部門的要求之下，可能需要實(shí)現(xiàn)像兩地三中心等等一系列復(fù)雜的架構(gòu)，這也會(huì)使得業(yè)務(wù)的運(yùn)行成本成倍地提高。因?yàn)樵趩为?dú)的機(jī)房之下進(jìn)行數(shù)據(jù)庫集群的搭建會(huì)是比較方便的，而在實(shí)現(xiàn)像兩地三中心這樣的架構(gòu)的時(shí)候，還需要去購買同城光纖以及異地光纖等等基礎(chǔ)設(shè)施，這部分大量的費(fèi)用也往往使得很多的企業(yè)在這樣的位置上處于停步狀態(tài)。

如果企業(yè)希望能夠進(jìn)一步地突破發(fā)展瓶頸往往還需要使用更多的數(shù)據(jù)庫架構(gòu)，例如需要使用到 OLAP 的數(shù)據(jù)庫倉庫以及大數(shù)據(jù)的海量分析等。在這樣的情況下，DBA 團(tuán)隊(duì)以及整體系統(tǒng)的構(gòu)建成本都將會(huì)更大地提升。

阿里云 云數(shù)據(jù)庫：產(chǎn)品理念前面為大家介紹了一個(gè)企業(yè)從小型到中型或者說是到達(dá)爆發(fā)期以及更進(jìn)一步的上升期的過程之中，對(duì)于數(shù)據(jù)庫可能會(huì)出現(xiàn)什么樣的要求。接下來為大家分享在阿里云的云數(shù)據(jù)庫中希望為大家提供什么樣的產(chǎn)品理念。

• 首先，大家可以看到在業(yè)務(wù)各個(gè)不同的發(fā)展過程當(dāng)中需要使用到不同的數(shù)據(jù)庫、數(shù)據(jù)庫的組合以及不同的數(shù)據(jù)庫產(chǎn)品的層級(jí)，因此阿里云會(huì)設(shè)計(jì)自己的數(shù)據(jù)庫產(chǎn)品讓不同的層級(jí)都可以適用。

• 第二點(diǎn)，阿里云會(huì)盡可能地去幫助企業(yè)提高自身的發(fā)展效率，也就是讓企業(yè)非常方便地?cái)U(kuò)展自己的資源，讓這些資源為用戶直接提升生產(chǎn)效率。

• 第三點(diǎn)，阿里云會(huì)直接降低整個(gè)架構(gòu)的構(gòu)建門檻，在傳統(tǒng)企業(yè)架構(gòu)之下，從單個(gè)機(jī)房變到多個(gè)機(jī)房或者從單個(gè)服務(wù)器變?yōu)槎鄠€(gè)服務(wù)器的時(shí)候，會(huì)存在很多技術(shù)以及生產(chǎn)成本的門檻限制，阿里云希望能夠通過云數(shù)據(jù)庫整體的底層架構(gòu)，包括飛天架構(gòu)將這些門檻降到最低。

• 最后要提到的也是本次中最希望分享的一點(diǎn)就是：在云數(shù)據(jù)庫之上，阿里云所希望達(dá)到的終極目標(biāo)是解放 DBA。其實(shí)通常情況下在一家公司里面，DBA 很多時(shí)候往往不會(huì)受到很大的重視，因?yàn)樵谄髽I(yè)中 DBA 日常所做的工作往往是像部署、備份等等一系列運(yùn)維工作，而這些工作將會(huì)占據(jù) DBA 50% 到 60% 的時(shí)間，而這些工作卻沒有辦法去為企業(yè)帶來直接的生產(chǎn)效率。而在云數(shù)據(jù)庫上面，通過云架構(gòu)的自動(dòng)化管理來完成所有的運(yùn)維工作，DBA 可以將自己更多的時(shí)間投入到業(yè)務(wù)架構(gòu)的優(yōu)化之中。什么是業(yè)務(wù)架構(gòu)的優(yōu)化呢？比如表結(jié)構(gòu)設(shè)計(jì)的不合理需要進(jìn)行優(yōu)化，一些 SQL 存在性能問題需要優(yōu)化，以及某些設(shè)計(jì)在業(yè)務(wù)發(fā)展的過程中已經(jīng)不合時(shí)宜需要優(yōu)化，所有的這些優(yōu)化都是 DBA 應(yīng)該去做的。而 DBA 也是最容易發(fā)展成為企業(yè)核心架構(gòu)師的一群人，他們的工作應(yīng)該更多地為企業(yè)真正地產(chǎn)能以及技術(shù)能力的輸出發(fā)揮貢獻(xiàn)，而不是去過多地關(guān)注每一天的部署、備份這樣繁瑣的運(yùn)維工作。

以上就是在設(shè)計(jì)云數(shù)據(jù)庫過程中，大家所看到的市場(chǎng)需求情況以及阿里云的云數(shù)據(jù)庫產(chǎn)品設(shè)計(jì)理念。

二、永恒不變的話題：需求

其實(shí)前面所講的長篇故事都是需求，每一個(gè)需求都需要得到滿足。那么面對(duì)這些需求，阿里云的云數(shù)據(jù)庫是如何一步一步解決的呢？分層：擴(kuò)展邊界覆蓋不同層級(jí)的用戶第一步就是進(jìn)行分層。之前使用過阿里云數(shù)據(jù)庫的朋友可能會(huì)有印象，阿里云最初推出的數(shù)據(jù)庫版本叫做高可用版本，這應(yīng)該也是當(dāng)前阿里云數(shù)據(jù)庫里面使用量最多的版本。在這個(gè)版本里面會(huì)有兩個(gè)數(shù)據(jù)庫服務(wù)器，一主一備，他們提供了非常好的性能并且能夠快速地進(jìn)行切換，然而在這樣的架構(gòu)之下，成本實(shí)際上翻了一倍。很多的用戶，特別是入門級(jí)別的剛開始使用云數(shù)據(jù)庫的用戶，往往不需要主備的數(shù)據(jù)庫系統(tǒng)，而是希望投入更低的成本，這個(gè)時(shí)候阿里云就推出了云數(shù)據(jù)庫的基礎(chǔ)版?；A(chǔ)版的架構(gòu)只有單個(gè)節(jié)點(diǎn)，基礎(chǔ)版的推出使得用戶的成本得以降低。同時(shí)需要注意的一點(diǎn)就是：在單節(jié)點(diǎn)或者說是基礎(chǔ)版之下，高可用到底是如何保障的。其實(shí)大家可以放心，在基礎(chǔ)版之下，阿里云同樣提供了高可用的保障，只不過沒有兩個(gè)節(jié)點(diǎn)的保障而是將整個(gè)數(shù)據(jù)庫運(yùn)行在飛天架構(gòu)之上，如果數(shù)據(jù)庫出現(xiàn)問題或者數(shù)據(jù)庫所在的主機(jī)出現(xiàn)了問題，飛天系統(tǒng)會(huì)自動(dòng)尋找新的主機(jī)、新的節(jié)點(diǎn)將整個(gè)系統(tǒng)運(yùn)行起來，只不過切換時(shí)間會(huì)稍微長一些，但是不會(huì)出現(xiàn)像系統(tǒng)長期斷開的情況。

再進(jìn)一步，很多高級(jí)用戶，特別是在金融界中的用戶所要求的數(shù)據(jù)穩(wěn)定性以及對(duì)于數(shù)據(jù)故障時(shí)的 RPO 都會(huì)有更高的要求，這時(shí)候阿里云就提供了金融版數(shù)據(jù)庫。在兩節(jié)點(diǎn)的基礎(chǔ)之上可能會(huì)擴(kuò)展到三節(jié)點(diǎn)甚至更多節(jié)點(diǎn)的集群的應(yīng)用。在做了這樣的工作之后，阿里云實(shí)際上是拓展了云數(shù)據(jù)庫產(chǎn)品的邊界，從剛開始阿里云數(shù)據(jù)庫只有高可用雙節(jié)點(diǎn)版本，擴(kuò)展到單節(jié)點(diǎn)的基礎(chǔ)版以及多節(jié)點(diǎn)的金融版，使得不同需求的用戶可以獲取到他們所需要的各種不同規(guī)格的云數(shù)據(jù)庫服務(wù)。效率：化繁為簡，釋放工作量在有了數(shù)據(jù)庫的運(yùn)行環(huán)境之后，其實(shí)大家可以看到各個(gè)用戶往往都會(huì)有自己不同時(shí)段的類似于促銷、活動(dòng)等的一些業(yè)務(wù)，在這些業(yè)務(wù)之中，用戶的查詢要求往往是非常高的，會(huì)出現(xiàn)非常高的查詢峰值，這時(shí)可以通過只讀節(jié)點(diǎn)來進(jìn)行解決。在阿里云中就直接提供了只讀請(qǐng)求的實(shí)例，而不需要用戶自己再去搭建只讀實(shí)例了。如果大家自己搭建過數(shù)據(jù)庫，就可能對(duì)于這個(gè)過程有所體會(huì)，當(dāng)搭建一個(gè)只讀實(shí)例時(shí)往往需要去構(gòu)建或者配置 3 到 4 個(gè)配置文件，而且各個(gè)主機(jī)之間，包括用戶權(quán)限以及密碼的同步等都需要進(jìn)行規(guī)劃，這個(gè)過程對(duì)于初級(jí)的 DBA 而言是比較困難和麻煩的事情，而且與此同時(shí)還需要保障整個(gè)系統(tǒng)在業(yè)務(wù)發(fā)展的過程中的穩(wěn)定運(yùn)行。

在阿里云上面，實(shí)際上會(huì)將構(gòu)建只讀實(shí)例的過程更加簡化，因?yàn)榘⒗镌茢?shù)據(jù)庫本身的底層系統(tǒng)架構(gòu)會(huì)自動(dòng)化地進(jìn)行所有的配置以及業(yè)務(wù)確認(rèn)，用戶只需要在界面上面點(diǎn)擊按鈕并添加一個(gè)只讀實(shí)例就能夠?qū)⒅蛔x實(shí)例建立完成，而且允許用戶建立 5 個(gè)甚至 10 個(gè)只讀實(shí)例。在這個(gè)過程中，大家會(huì)發(fā)現(xiàn)雖然阿里云提供了直接添加只讀實(shí)例的功能，而且完成了其中的同步，但是業(yè)務(wù)方也就是如上圖所示的云服務(wù)器 ECS 上面的應(yīng)用還是需要通過把讀寫請(qǐng)求和只讀請(qǐng)求進(jìn)行業(yè)務(wù)分離，這對(duì)于數(shù)據(jù)庫的開發(fā)是存在入侵性的，也就是說原來開發(fā)的程序只需要一個(gè)數(shù)據(jù)庫進(jìn)行操作就可以了，而由于當(dāng)前使用了只讀實(shí)例，則需要將所有的只讀查詢都單獨(dú)地拎出來讓其去訪問其他節(jié)點(diǎn)，這一點(diǎn)對(duì)于程序的入侵性可能會(huì)是非常大的，這就可能會(huì)使得很多的開發(fā)者無法直接使用到阿里云的只讀實(shí)例了，或者有很多的工作需要重新進(jìn)行開發(fā)。效率： 化繁為簡，釋放工作量， 直接支持讀寫分離針對(duì)上述的問題，阿里云的數(shù)據(jù)庫在發(fā)展的過程中也會(huì)收到用戶的需求和報(bào)告，因此阿里云數(shù)據(jù)庫就進(jìn)行了進(jìn)一步的優(yōu)化。在只讀實(shí)例的運(yùn)行條件之下，阿里云數(shù)據(jù)庫還進(jìn)一步地提供了讀寫分離的 IP 訪問，其主要會(huì)在 Proxy 業(yè)務(wù)層底下實(shí)現(xiàn)所有 SQL 的收集，并且對(duì)于所有的收集到的 SQL 進(jìn)行分類，如果發(fā)現(xiàn) SQL 操作既有讀操作也有寫操作的時(shí)候，也就是讀寫操作在同一個(gè)事務(wù)里面的時(shí)候，會(huì)將這些操作自動(dòng)地提交到主節(jié)點(diǎn)。而如果當(dāng)發(fā)現(xiàn)事務(wù)中所有的操作都是讀操作的時(shí)候，Proxy 層就會(huì)將這些只讀的查詢平均地分配到各個(gè)只讀節(jié)點(diǎn)。這意味著應(yīng)用程序不需要改變本身的代碼，阿里云就能夠自動(dòng)地為用戶實(shí)現(xiàn)讀寫分離的工作，而業(yè)務(wù)方不需要去修改自己的業(yè)務(wù)代碼。通過這樣查詢的讀寫分離的功能，可以非常好地簡化本身開發(fā)以及維護(hù)的工作量。

效率：新一代關(guān)系型數(shù)據(jù)庫演進(jìn)其實(shí)除了上面所說的這些，阿里云數(shù)據(jù)庫所做的工作還遠(yuǎn)沒有結(jié)束。如果大家留意了阿里云最近的新聞或者最新的產(chǎn)品動(dòng)向就會(huì)知道，在阿里云數(shù)據(jù)庫最新的版本中提供了關(guān)系型數(shù)據(jù)庫 PolarDB 的集群，這款產(chǎn)品預(yù)計(jì)將在十月份推出，在這款產(chǎn)品上面不單單解決了讀寫分離的問題，也會(huì)使用到最新的硬件技術(shù)去達(dá)到比較好的讀寫資源比。在讀寫分離的業(yè)務(wù)之下，當(dāng)主節(jié)點(diǎn)有數(shù)據(jù)寫入的時(shí)候，所有的數(shù)據(jù)需要同步到每一個(gè)只讀節(jié)點(diǎn)，而在主節(jié)點(diǎn)和只讀節(jié)點(diǎn)之間或許會(huì)存在網(wǎng)絡(luò)延遲，這些網(wǎng)絡(luò)延遲可能會(huì)導(dǎo)致從主節(jié)點(diǎn)讀出的數(shù)據(jù)和從只讀節(jié)點(diǎn)讀出的數(shù)據(jù)出現(xiàn)不一致的情況，而這是需要業(yè)務(wù)方或者開發(fā)人員知曉并通過業(yè)務(wù)進(jìn)行保障的。

而在 PolarDB 中，阿里云嘗試使用了一種新型的架構(gòu)，通過 RDMA 網(wǎng)絡(luò)會(huì)將下層的各個(gè)存儲(chǔ)節(jié)點(diǎn)進(jìn)行整合管理，通過分布式 Raft 協(xié)議實(shí)現(xiàn)完整的底層集群。這樣所能達(dá)到的效果就是當(dāng)主節(jié)點(diǎn)進(jìn)行數(shù)據(jù)寫入的過程中，底層的 Raft 協(xié)議的數(shù)據(jù)集群會(huì)把數(shù)據(jù)自動(dòng)打散到三個(gè)或者以上的存儲(chǔ)節(jié)點(diǎn)上面，同時(shí)這些數(shù)據(jù)一旦寫入，在其他的只讀節(jié)點(diǎn)上就可以讀到。因此可以看到在這樣的架構(gòu)之下，減少了多節(jié)點(diǎn)之間的數(shù)據(jù)復(fù)制，網(wǎng)絡(luò)帶寬的消耗會(huì)更低，同時(shí)主節(jié)點(diǎn)和只讀節(jié)點(diǎn)之間網(wǎng)絡(luò)數(shù)據(jù)延遲基本為零，也就是說只要數(shù)據(jù)寫入了，只讀節(jié)點(diǎn)就能夠讀取到，符合 ACID 的完整原則。所有的數(shù)據(jù)在存放的時(shí)候都不會(huì)少于三節(jié)點(diǎn)，任何一個(gè)節(jié)點(diǎn)或者數(shù)據(jù)模塊出現(xiàn)故障的時(shí)候，都不會(huì)造成數(shù)據(jù)丟失。在這樣的架構(gòu)之下，可以進(jìn)一步使得數(shù)據(jù)庫的使用者獲取更高的性價(jià)比。門檻： 綜合系統(tǒng)管理門檻高以上分享的是在數(shù)據(jù)庫關(guān)系的演進(jìn)中阿里云提供的一些思考和產(chǎn)品，而下面會(huì)分享另外一個(gè)問題。如下圖所示，當(dāng)一個(gè)業(yè)務(wù)發(fā)展到比較龐大的數(shù)據(jù)規(guī)模時(shí)，存下來的業(yè)務(wù)數(shù)據(jù)還需要進(jìn)行產(chǎn)品的分析，比如當(dāng)數(shù)據(jù)量已經(jīng)存放到兩三年的時(shí)候，企業(yè)主肯定希望能夠通過這兩三年沉淀的數(shù)據(jù)來進(jìn)行業(yè)務(wù)分析。這個(gè)時(shí)候，在傳統(tǒng)的架構(gòu)之下，往往會(huì)向如圖中所看到的把數(shù)據(jù)通過 ETL，也就是數(shù)據(jù)導(dǎo)入到數(shù)據(jù)倉庫，并在數(shù)據(jù)倉庫之上再去做 OLAP 的業(yè)務(wù)分析。同時(shí)由于數(shù)據(jù)量越來越大，因此也需要通過分布式的數(shù)據(jù)庫中間件實(shí)現(xiàn)一個(gè)動(dòng)作，也就是將整個(gè)的數(shù)據(jù)庫進(jìn)行分庫分表式的管理。當(dāng)然，這樣的功能在互聯(lián)網(wǎng)圈已經(jīng)使用的非常多了，但是大家會(huì)發(fā)現(xiàn)下圖中存在四個(gè)藍(lán)色的管理標(biāo)記，這是因?yàn)樵诿總€(gè)層級(jí)當(dāng)中都需要對(duì)于數(shù)據(jù)庫進(jìn)行一些單獨(dú)的人為操作和人為干預(yù)。

簡化分庫分表管理，一份數(shù)據(jù)實(shí)現(xiàn) OLTP+OLAP=HTAP可以看到在上圖的整個(gè)運(yùn)作流程中，每一個(gè)節(jié)點(diǎn)上面都需要進(jìn)行配置和規(guī)劃，而這些所有的配置和規(guī)劃都需要消耗時(shí)間。還有一點(diǎn)就是業(yè)務(wù)系統(tǒng)是 OLTP 的系統(tǒng)，所有的在線的業(yè)務(wù)都在上圖中左側(cè)的 OLTP 系統(tǒng)里面，當(dāng)需要進(jìn)行分析的時(shí)候并不能直接在業(yè)務(wù)系統(tǒng)進(jìn)行分析，因?yàn)檫@會(huì)影響業(yè)務(wù)系統(tǒng)本身的性能，因此需要再進(jìn)行一次數(shù)據(jù)的抽取，將數(shù)據(jù)抽取到 OLAP 的數(shù)據(jù)倉庫中，然后再去做查詢。這樣動(dòng)作使得數(shù)據(jù)多了冗余，而且所有的數(shù)據(jù)無法實(shí)現(xiàn)所謂的“T+0”的實(shí)時(shí)分析，在這種情況下，所有的操作以及運(yùn)維管理會(huì)消耗更多的使用資源。因此，在阿里云中也提供了 HybridDB for MySQL 的架構(gòu)。通過 HybridDB for MySQL 架構(gòu)的數(shù)據(jù)庫，可以實(shí)現(xiàn)將上圖中所看到的整個(gè)數(shù)據(jù)鏈路，包括分布式數(shù)據(jù)庫中間件以及數(shù)據(jù)倉庫都整合到一個(gè)數(shù)據(jù)庫中，這個(gè)數(shù)據(jù)庫可以直接實(shí)現(xiàn) OLTP 的事務(wù)操作，同時(shí)也接受 OLAP 的數(shù)據(jù)分析處理，而且整個(gè)系統(tǒng)也是分布式系統(tǒng)。

在這個(gè)系統(tǒng)之上最大的好處就是用戶不再需要去分別地管理兩個(gè)業(yè)務(wù)系統(tǒng)：OLTP 系統(tǒng)和 OLAP 系統(tǒng)。與此同時(shí)還可以實(shí)現(xiàn)計(jì)算和存儲(chǔ)的分離操作，如果計(jì)算資源不足還可以單獨(dú)地增加計(jì)算資源使得查詢速度更快。而且整個(gè)系統(tǒng)將會(huì)直接兼容 MySQL 的生態(tài)，因此用戶不需要過多地修改自己數(shù)據(jù)庫查詢的業(yè)務(wù)邏輯，可以直接使用 MySQL 的客戶端以及各種工具來連接到數(shù)據(jù)庫上面去進(jìn)行操作。因此，在 HybridDB for MySQL 數(shù)據(jù)庫中實(shí)現(xiàn)了一種新的形態(tài)叫做 HTAP，實(shí)際上就是在同一個(gè)數(shù)據(jù)庫里面不僅可以進(jìn)行 OLTP 操作，還可以進(jìn)行 OLAP 操作，而且其空間可以擴(kuò)展到超過 PB 的級(jí)別。釋放：安心原于透明，主動(dòng)的提醒阿里云的數(shù)據(jù)庫產(chǎn)品除了提供了以上的功能以外，為了使得 DBA 更加省心和安心，絕對(duì)離不開的就是對(duì)于各種資源的監(jiān)控以及對(duì)于引擎的監(jiān)控。在這里不做過多的解析，因?yàn)樵诋a(chǎn)品上大家可以看到，阿里云已經(jīng)把自己原來在天貓、淘寶等的各方面的經(jīng)驗(yàn)進(jìn)行了整體的輸出，會(huì)提供非常深度的包括 TPS、QPS 以及緩存命中率等等一系列的監(jiān)控，而且可以產(chǎn)生直接的圖表。在報(bào)警方面，可以通過云監(jiān)控設(shè)置所需要的報(bào)警，當(dāng)水位超過了一定的范圍之后可以直接發(fā)送短信、郵件甚至通過電話的告警來提醒 DBA 進(jìn)行擴(kuò)容或者及時(shí)地發(fā)現(xiàn)問題。更進(jìn)一步，阿里云還將會(huì)提供云 DBA 的協(xié)助工具，甚至還會(huì)為用戶提供 Index 推薦以及像告警錯(cuò)誤業(yè)務(wù)分析等服務(wù)。

釋放用戶成本：中小企業(yè)也可以獲得高端服務(wù)在企業(yè)發(fā)展的過程中，隨著業(yè)務(wù)不斷地發(fā)展，需要更好地保障業(yè)務(wù)的連續(xù)穩(wěn)定性。對(duì)于很多企業(yè)而言，數(shù)據(jù)庫中心里面往往只有一個(gè) IDC 的機(jī)房，然而如果這個(gè) IDC 機(jī)房出現(xiàn)斷電或者故障的時(shí)候，就沒有辦法進(jìn)行更進(jìn)一步的業(yè)務(wù)操作。阿里云在數(shù)據(jù)庫體系之下已經(jīng)完成如下圖所示的整體架構(gòu)。當(dāng)大家看到阿里云數(shù)據(jù)庫產(chǎn)品購買頁的時(shí)候會(huì)發(fā)現(xiàn)阿里云不僅提供了單中心的雙節(jié)點(diǎn)模型，還在很多地域中提供了多可用區(qū)的模型。多可用區(qū)模型就是把主節(jié)點(diǎn)和備用節(jié)點(diǎn)放在一個(gè)城市的兩個(gè)不同的可用區(qū)上，也就是說用戶的實(shí)例只購買了一個(gè)，但是在部署的時(shí)候卻部署在了一個(gè)城市的兩個(gè)中心，一旦主中心出現(xiàn)整體故障的時(shí)候，用戶的業(yè)務(wù)依然可以通過切換到備用中心繼續(xù)提供服務(wù)。大家可以想象，如果沒有云架構(gòu)的支撐，依靠自己搭建多可用區(qū)模型的時(shí)候，可能會(huì)需要非常高的業(yè)務(wù)成本，這是因?yàn)橥侵g光纖搭建的費(fèi)用是非常昂貴的。

除此之外，阿里云還會(huì)為企業(yè)提供跨數(shù)據(jù)中心的訪問。很多用戶可能會(huì)說現(xiàn)在自己的企業(yè)還不大，還不需要到這樣的業(yè)務(wù)保護(hù)，但是在這里想告訴大家的是這樣的觀點(diǎn)往往是不正確的。如上圖所示，當(dāng)前在同城雙中心災(zāi)備里面不需要增加用戶的成本，那么就完全可以在企業(yè)發(fā)展之初就使用這樣的架構(gòu)，因?yàn)樵谄髽I(yè)發(fā)展的過程中，任何一個(gè)技術(shù)上的故障或者服務(wù)的宕機(jī)往往會(huì)造成后續(xù)更大的損失。所以如果能夠提前在不增加過多成本的情況下實(shí)現(xiàn)企業(yè)同城容災(zāi)以及跨地域業(yè)務(wù)，往往能夠?qū)τ谄髽I(yè)業(yè)務(wù)的發(fā)展提供更大的幫助。在阿里云上，其實(shí)基于阿里云本身的技術(shù)架構(gòu)就可以為用戶更好地釋放這部分成本，而用戶不需要自己搭建光纖就可以復(fù)用所有現(xiàn)有的網(wǎng)絡(luò)，這使得企業(yè)在初始階段就可以像大企業(yè)一樣使用到所有的數(shù)據(jù)庫的高端服務(wù)。大家可以看到，在阿里云數(shù)據(jù)庫業(yè)務(wù)中比較注重的就是如下圖所示的五點(diǎn)：如何幫助用戶節(jié)省成本，如何使數(shù)據(jù)庫的性能達(dá)到更高，如何維護(hù)業(yè)務(wù)的連續(xù)性，以及業(yè)務(wù)擴(kuò)展能力和數(shù)據(jù)容災(zāi)等。而這一切的能力都是通過云托管平臺(tái)進(jìn)行規(guī)劃和賦能的。

三、生態(tài)的力量

在以上的內(nèi)容中為大家分享了云數(shù)據(jù)庫上的產(chǎn)品驅(qū)動(dòng)、阿里云數(shù)據(jù)庫提供了什么樣的保護(hù)以及阿里云數(shù)據(jù)庫是如何承載用戶需求的。接下來為大家分享數(shù)據(jù)庫生態(tài)的力量。阿里云 MySQL 生態(tài)體系當(dāng)阿里云最初去規(guī)劃數(shù)據(jù)庫產(chǎn)品的時(shí)候，首先做的產(chǎn)品就是 MySQL，因?yàn)樵诋?dāng)時(shí) MySQL 也是使用最為廣泛的數(shù)據(jù)庫，特別是在互聯(lián)網(wǎng)業(yè)界。但是在不斷的發(fā)展過程中也發(fā)現(xiàn)不斷有更多的互聯(lián)網(wǎng)業(yè)務(wù)以及企業(yè)客戶會(huì)進(jìn)入到阿里云體系上來，所以阿里云需要有更多的數(shù)據(jù)庫類型來對(duì)這些用戶進(jìn)行支撐。很多的用戶不僅僅需要使用 SQL 的數(shù)據(jù)庫，還會(huì)需要做緩存并且需要進(jìn)行數(shù)據(jù)分析。在下圖中，大家可以看到阿里云逐步地增加更多的引擎，按照 DB-Engines 的統(tǒng)計(jì)，目前阿里云數(shù)據(jù)庫已經(jīng)能夠覆蓋 70% 的數(shù)據(jù)庫產(chǎn)品，這也是由市場(chǎng)所決定的。而這些產(chǎn)品中的部分產(chǎn)品已經(jīng)開始走上了阿里云自研的道路，像之前提到的 HybridDB for MySQL 以及 PolarBD 等。當(dāng)然，除了自研產(chǎn)品之外，阿里云也會(huì)兼顧到市場(chǎng)上面其他用戶的需求，也會(huì)提供像 SQL Server、HBase、MongoDB 以及 Redis 等一系列的數(shù)據(jù)庫產(chǎn)品，這就是阿里云目前的數(shù)據(jù)庫產(chǎn)品整體大生態(tài)。

當(dāng)然我們也可以看到另外一個(gè)生態(tài)模型，舉個(gè)例子就是目前很多的用戶都在使用 MySQL 的數(shù)據(jù)庫，在 MySQL 數(shù)據(jù)庫之下，阿里云會(huì)提供多種不同的數(shù)據(jù)庫形態(tài)和模式，讓用戶可以完全沉浸在 MySQL 整體生態(tài)鏈路之中。如下圖左側(cè)所示，RDS for MySQL 提供了基礎(chǔ)版、高可用版以及金融版，使得用戶可以快速地進(jìn)行業(yè)務(wù)的使用，進(jìn)一步在未來阿里云數(shù)據(jù)庫將會(huì)發(fā)布的 PolarDB 也會(huì)率先地支持 MySQL 的引擎，讓具有幾十 TB 數(shù)據(jù)或者上百 TB 數(shù)據(jù)的并且想要使用更加穩(wěn)定的數(shù)據(jù)庫系統(tǒng)的大型客戶能夠非常好地解決遇到的問題。同時(shí)，很多人會(huì)認(rèn)為 MySQL 上面并不適合去做 OLAP 業(yè)務(wù)分析工作，但是如果所有的開發(fā)人員都是熟悉 MySQL 的并且不希望跳出 MySQL 的框架而且希望去基于 MySQL 實(shí)現(xiàn)業(yè)務(wù)分析操作，這樣通過 HybridDB for MySQL 就能夠繼續(xù)去承載這樣的業(yè)務(wù)，而且在這個(gè)系統(tǒng)上面還可以同時(shí)整合 OLTP 和 OLAP。因此，在數(shù)據(jù)庫產(chǎn)品的規(guī)劃過程之中，阿里云會(huì)充分地考慮用戶本身的感情因素，當(dāng)用戶特別傾向于某一數(shù)據(jù)庫的時(shí)候，阿里云就會(huì)針對(duì)于這個(gè)數(shù)據(jù)庫做出一系列的產(chǎn)品，使得用戶可以通過統(tǒng)一的技術(shù)去完成所有的技術(shù)工作，而沒必要將所有的工作分散到不同的數(shù)據(jù)庫并使用不同的 SQL 模型進(jìn)行重新開發(fā)。

阿里云 PostgreSQL 生態(tài)系統(tǒng)除了 MySQL 生態(tài)之外，近年 PostgreSQL 生態(tài)系統(tǒng)也是非?；馃岬?，阿里云數(shù)據(jù)庫團(tuán)隊(duì)在 PostgreSQL 生態(tài)上也沿用了和 MySQL 生態(tài)中相同的思路。阿里云不只是為用戶提供一個(gè)單獨(dú)的 RDS for PostgreSQL 的系統(tǒng)，因?yàn)?PostgreSQL 和 Oracle 比較相似，所以還會(huì)針對(duì)基于 PostgreSQL 的增強(qiáng)版本——RDS for PPS 來協(xié)助 Oracle 用戶來進(jìn)行數(shù)據(jù)遷移。同時(shí)阿里云也會(huì)推出針對(duì)于數(shù)據(jù)倉庫的 HybridDB for PostgreSQL 來實(shí)現(xiàn)數(shù)據(jù)分析。而且所有的這些體系都可以通過外部表的形式去操作 OSS，甚至在 OSS 上面放一份數(shù)據(jù)，各個(gè)不同的 OLTP、OLAP 數(shù)據(jù)庫產(chǎn)品都可以對(duì)于 OSS 上的數(shù)據(jù)進(jìn)行讀寫操作和分析應(yīng)用來實(shí)現(xiàn)整體生態(tài)鏈的運(yùn)行過程。

四、SQL+NoSQL+Big Data 一站式解決數(shù)據(jù)打通

除了上述提到的阿里云為拆分的 MySQL 和 PostgreSQL 生態(tài)鏈打造的獨(dú)特的方案之外，阿里云數(shù)據(jù)庫還會(huì)與阿里云的各種數(shù)據(jù)鏈路的軟件進(jìn)行整合規(guī)劃。在下面這張圖中，大家可以看到，通過阿里云的 DTS 以及 CDP 這樣數(shù)據(jù)工具，可以將前端的 Key-Value 的緩存層、OLTP、NoSQL、分析