引言

近幾年，隨著云計(jì)算相關(guān)技術(shù)的發(fā)展，各種不同類型的云層出不窮，服務(wù)越來(lái)越多不同類型的企業(yè)業(yè)務(wù)，傳統(tǒng)企業(yè)也漸漸開(kāi)始探索上云的道路。在云上，作為業(yè)務(wù)最核心的數(shù)據(jù)庫(kù)，相比之前的傳統(tǒng)方案會(huì)有哪些變化呢？在正式聊云時(shí)代的數(shù)據(jù)庫(kù)特點(diǎn)之前，我們需要了解一下目前云時(shí)代架構(gòu)發(fā)生的變化。暢想一下，未來(lái)的服務(wù)都跑在云端，任何的服務(wù)資源都可以像水電煤一樣按需選購(gòu)。從IaaS層的容器/虛擬機(jī)，到PaaS層的數(shù)據(jù)庫(kù)，緩存和計(jì)算單元，再到SaaS層的不同類型的應(yīng)用，我們只需要根據(jù)自身業(yè)務(wù)特點(diǎn)進(jìn)行資源選配，再也不用擔(dān)心應(yīng)用服務(wù)支撐不住高速的業(yè)務(wù)增長(zhǎng)，因?yàn)樵谠粕弦磺卸际菑椥陨炜s的。

有了可靠的基礎(chǔ)軟件架構(gòu)，我們就可以把更多精力放到新業(yè)務(wù)的探索，新模式的創(chuàng)新，就有可能產(chǎn)生更多不一樣的新場(chǎng)景，從而催生更強(qiáng)大能力的云端服務(wù)，這是一件多么cool的事情。

當(dāng)然，理想要一步一步實(shí)現(xiàn)，未來(lái)的基礎(chǔ)軟件棧到底會(huì)怎樣呢？社區(qū)在這方面正在進(jìn)行積極地探索，其中最有代表性的就是基于容器（以Docker為代表）的虛擬化技術(shù)和微服務(wù)（microservice）。

在云時(shí)代，一切都應(yīng)該是可伸縮的，使用k8s（Kubernetes）在保證資源平衡的前提下，通過(guò)Docker部署我們依托于容器的微服務(wù)模塊，我們不用關(guān)心服務(wù)到底跑在哪里，只需要關(guān)心我們需要多少服務(wù)資源。Docker提供了極大的便利性，一次構(gòu)建，到處運(yùn)行，我們可以很好地解決開(kāi)發(fā)、測(cè)試和上線的環(huán)境一致性問(wèn)題。（如果不能很好地保證測(cè)試和實(shí)際上線環(huán)境的一致性，則很有可能需要花費(fèi)遠(yuǎn)超過(guò)開(kāi)發(fā)的時(shí)間去發(fā)現(xiàn)和修復(fù)問(wèn)題。）

k8s更是在Docker構(gòu)建的基礎(chǔ)上增加了更多的云特性，包括Docker的升級(jí)，高可用和彈性伸縮等等。 關(guān)于Docker/k8s相關(guān)的討論已經(jīng)很多了，因?yàn)闀r(shí)間關(guān)系，關(guān)于具體的細(xì)節(jié)就不再展開(kāi)。我們只需要了解，有了它，可以很輕松地解決服務(wù)的安裝和部署。

下面再聊聊微服務(wù)，微服務(wù)將一個(gè)服務(wù)拆分成相對(duì)獨(dú)立的更小的子服務(wù)單元，不同的子服務(wù)單元之間通過(guò)統(tǒng)一的接口（HTTP/RPC等）進(jìn)行數(shù)據(jù)交互。

相比于傳統(tǒng)的解決方案，這種架構(gòu)有很多的優(yōu)點(diǎn)。

1.更好的開(kāi)發(fā)效率和可維護(hù)性。微服務(wù)將一個(gè)單獨(dú)的服務(wù)進(jìn)行更細(xì)力度的拆分，每一個(gè)子服務(wù)單元專注于更小的功能模塊，可以更好地根據(jù)業(yè)務(wù)建立對(duì)應(yīng)的數(shù)據(jù)模型，降低復(fù)雜度，使得開(kāi)發(fā)變得更輕松，維護(hù)和部署變得更加友好。

2.更好的可擴(kuò)展性。每個(gè)不同的子服務(wù)單元相互獨(dú)立，彼此之間沒(méi)有任何依賴，所以可以根據(jù)業(yè)務(wù)的具體需要，靈活地部署多個(gè)子服務(wù)單元進(jìn)行水平擴(kuò)展。

3.更強(qiáng)的容錯(cuò)性。當(dāng)其中一個(gè)子服務(wù)出現(xiàn)故障的時(shí)候，可以通過(guò)輔助的負(fù)載均衡工具，自動(dòng)路由到其他的子服務(wù)，不會(huì)影響整體服務(wù)的可用性。

當(dāng)然，微服務(wù)也不是一個(gè)銀彈，相對(duì)來(lái)說(shuō)，這種方案會(huì)使整體系統(tǒng)的設(shè)計(jì)更加復(fù)雜，同時(shí)也加大了網(wǎng)絡(luò)的延遲，對(duì)整個(gè)系統(tǒng)測(cè)試的復(fù)雜度也會(huì)更高。

Docker提供的隔離型和可移植性，與微服務(wù)是一種天然的契合，微服務(wù)將整個(gè)軟件進(jìn)行拆分和解耦，而通過(guò)Docker/k8s可以很自然地做到獨(dú)立的部署，高可用和容錯(cuò)性，似乎一切都可以完美地運(yùn)轉(zhuǎn)起來(lái)。但是真的是這樣么？我們是不是忽略了什么？

是的，我們?cè)谟懻撉懊娴膯?wèn)題的時(shí)候忽略了一個(gè)很重要的東西：狀態(tài)。

從整個(gè)技術(shù)發(fā)展的角度來(lái)看，微服務(wù)是一個(gè)非常有意義的探索。每個(gè)人都期望著每個(gè)微服務(wù)的子服務(wù)都是無(wú)狀態(tài)的，這樣我可以自由地啟停和伸縮，沒(méi)有任何的心智負(fù)擔(dān)，但是現(xiàn)實(shí)的業(yè)務(wù)情況是什么樣的呢？

比如一個(gè)電商網(wǎng)站，用戶正在下單購(gòu)買(mǎi)一件商品，此時(shí)平臺(tái)是通過(guò)訂單子服務(wù)的A應(yīng)用來(lái)提供服務(wù)的，突然，因?yàn)闄C(jī)器故障，訂單子服務(wù)的A應(yīng)用不可用了，改由訂單子服務(wù)的B應(yīng)用提供服務(wù)，那么它是必須要知道剛才用戶的訂單信息的，否則正在訪問(wèn)自己訂單頁(yè)面的用戶會(huì)發(fā)現(xiàn)自己的訂單信息突然不見(jiàn)了。

雖然我們盡量想把子服務(wù)設(shè)計(jì)成無(wú)狀態(tài)的，但是很多時(shí)候狀態(tài)都是不可避免的，我們不得不通過(guò)存儲(chǔ)層保存狀態(tài)，業(yè)界最主要的還是各種數(shù)據(jù)庫(kù)，包括RDBMS和NoSQL，比如使用MySQL、MongoDB、HBase、Cassandra等，特別是有些場(chǎng)景還要考慮數(shù)據(jù)一致性問(wèn)題的時(shí)候，更加重了對(duì)存儲(chǔ)層的依賴。

由此可見(jiàn)，云計(jì)算時(shí)代系統(tǒng)的架構(gòu)發(fā)生了巨大的變化，這一方面為用戶提供了更優(yōu)秀的特性，另一方面也對(duì)云計(jì)算的組件提出了更高的要求。數(shù)據(jù)庫(kù)作為云計(jì)算最基礎(chǔ)的組件之一，也需要適應(yīng)這種架構(gòu)的變化。（這里我們主要關(guān)注SQL數(shù)據(jù)庫(kù)，云時(shí)代的數(shù)據(jù)庫(kù)以下簡(jiǎn)稱云數(shù)據(jù)庫(kù)。）

那么云數(shù)據(jù)庫(kù)主要有一些什么樣的特點(diǎn)呢？我認(rèn)為主要有以下幾點(diǎn)。

彈性伸縮

傳統(tǒng)的數(shù)據(jù)庫(kù)方案，常見(jiàn)的會(huì)選用Oracle, MySQL,PostgreSQL。在云時(shí)代，數(shù)據(jù)量的規(guī)模有爆發(fā)性的增長(zhǎng)，傳統(tǒng)的數(shù)據(jù)庫(kù)很容易遇到單機(jī)的存儲(chǔ)瓶頸，不得不選用一些集群方案，常見(jiàn)的比如Oracle RAC、MySQL Sharding等，而這些集群方案或多或少都有一些不令人滿意的地方。

比如說(shuō)，Oracle RAC通過(guò)共享存儲(chǔ)的硬件方案解決集群?jiǎn)栴}，這種方式基本上只能通過(guò)停機(jī)換用更大的共享內(nèi)存硬件來(lái)解決擴(kuò)容問(wèn)題，RAC節(jié)點(diǎn)過(guò)多會(huì)帶來(lái)更多的并發(fā)問(wèn)題，同樣也會(huì)帶來(lái)更高的成本。

以MySQL Sharding為代表的數(shù)據(jù)分片方案，很多時(shí)候不得不提前對(duì)數(shù)據(jù)量進(jìn)行規(guī)劃，把擴(kuò)容作為很重要的一個(gè)計(jì)劃來(lái)做，從DBA到運(yùn)維到測(cè)試到開(kāi)發(fā)人員，很早之前就要做相關(guān)的準(zhǔn)備工作，真正擴(kuò)容的時(shí)候，為了保證數(shù)據(jù)安全，經(jīng)常會(huì)選擇停服務(wù)來(lái)保證沒(méi)有新的數(shù)據(jù)寫(xiě)入，新的分片數(shù)據(jù)同步后還要做數(shù)據(jù)的一致性校驗(yàn)。

當(dāng)然業(yè)界大公司有足夠雄厚的技術(shù)實(shí)力，可以采用更復(fù)雜的方案，將擴(kuò)容停機(jī)時(shí)間盡量縮短（但是很難縮減到0），但是對(duì)于大部分中小互聯(lián)網(wǎng)公司和傳統(tǒng)企業(yè)，依然無(wú)法避免較長(zhǎng)時(shí)間的停服務(wù)。

在云時(shí)代，理想中所有的資源都是根據(jù)用戶業(yè)務(wù)需求按需分配的，服務(wù)器資源，應(yīng)用容器資源，當(dāng)然也包括數(shù)據(jù)庫(kù)資源。添加或者減少新的數(shù)據(jù)庫(kù)資源，完全就像日常吃飯那樣稀疏平常，甚至用戶基本感知不到。

比如作為一個(gè)電商用戶，在雙11促銷活動(dòng)之前，可以通過(guò)增加數(shù)據(jù)庫(kù)節(jié)點(diǎn)的方式，擴(kuò)大更多的資源池，用來(lái)部署相應(yīng)的容器服務(wù)，當(dāng)活動(dòng)結(jié)束之后，再將多余的資源移除去支持其他的服務(wù)，這樣可以極大地提高資源的利用率，同樣可以彈性地支撐各種峰值業(yè)務(wù)。

高可用

傳統(tǒng)的MySQL方案，數(shù)據(jù)復(fù)制的時(shí)候默認(rèn)采用異步的方式，對(duì)于一個(gè)寫(xiě)入的請(qǐng)求，主庫(kù)寫(xiě)入成功后就會(huì)返回成功信息給客戶端，但是這個(gè)時(shí)候數(shù)據(jù)可能還沒(méi)有同步給從庫(kù)，一旦主庫(kù)這個(gè)時(shí)候掛掉了，啟動(dòng)從庫(kù)的時(shí)候就會(huì)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。

當(dāng)然，也有人會(huì)選擇半同步的復(fù)制方式，這種方式在正常情況下是同步的，但是在遇到數(shù)據(jù)壓力比較大的時(shí)候，依然會(huì)退化為異步的方式，所以本質(zhì)上來(lái)說(shuō)，同樣有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。其他也有一些多主的同步方案，比如在應(yīng)用層做數(shù)據(jù)同步，但是這種方式一是需要應(yīng)用層的配合，二是在對(duì)網(wǎng)絡(luò)超時(shí)的處理非常復(fù)雜，增加心智負(fù)擔(dān)。

在云時(shí)代，因?yàn)樗械臄?shù)據(jù)庫(kù)資源都是分布式存儲(chǔ)的，每個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)出現(xiàn)問(wèn)題都是很正常的事情，所以就必須有一種可以實(shí)現(xiàn)數(shù)據(jù)一致性的數(shù)據(jù)復(fù)制方式來(lái)保證服務(wù)的高可用，業(yè)界給出的答案就是：Paxos/Raft（關(guān)于Paxos和Raft的實(shí)現(xiàn)細(xì)節(jié)我們不在這里展開(kāi)）。

PingCAP在做的TiDB就是選擇了Raft協(xié)議，Raft協(xié)議看起來(lái)更像是一個(gè)多副本的自適應(yīng)的主從復(fù)制協(xié)議，對(duì)于每次寫(xiě)請(qǐng)求，Raft都會(huì)保證大多數(shù)寫(xiě)成功才會(huì)返回客戶端，即使Raft Group的Leader掛掉了，在一個(gè)有限的時(shí)間范圍內(nèi)，會(huì)很快地選出一個(gè)新的Leader出來(lái)，繼續(xù)提供服務(wù)。

同樣，對(duì)于一個(gè)3副本的Raft Group，只要2個(gè)寫(xiě)入成功，就可以保證成功，而大多數(shù)情況下，最先寫(xiě)入成功的往往是與Leader網(wǎng)絡(luò)情況最好的那個(gè)副本，所以這種Majority寫(xiě)的方式，可以很自然地選擇速度最快的副本進(jìn)行數(shù)據(jù)同步復(fù)制。另外，Raft協(xié)議本身支持Config Change，增加一個(gè)新的節(jié)點(diǎn)，可以很容易地做副本數(shù)據(jù)分布的變更，而不需要停止任何服務(wù)。

同樣，在云時(shí)代，數(shù)據(jù)庫(kù)的DDL操作也會(huì)是一個(gè)非常有趣的事情。以一個(gè)常見(jiàn)的Add Column操作為例，在表規(guī)模已經(jīng)很大的情況下，在傳統(tǒng)的實(shí)現(xiàn)方案中，比較有參考意義的是，通過(guò)一些工具，創(chuàng)建類似表級(jí)別的觸發(fā)器，將原表的數(shù)據(jù)同步到一個(gè)新的臨時(shí)表中，當(dāng)數(shù)據(jù)追平的時(shí)候，再進(jìn)行一個(gè)鎖表操作，將臨時(shí)表命名為原表，這樣一個(gè)Add Column操作就完成了。

但是在云時(shí)代，分布式的數(shù)據(jù)存儲(chǔ)方式?jīng)Q定了這種方案很難實(shí)現(xiàn)，因?yàn)槊總€(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)很難保證Schema狀態(tài)變更的一致性，而且當(dāng)數(shù)據(jù)規(guī)模增長(zhǎng)到幾十億，幾百億甚至更多的時(shí)候，很短的阻塞時(shí)間都有可能會(huì)導(dǎo)致很大的負(fù)載壓力變化，所以DDL操作必須是保證無(wú)阻塞的在線操作。值得欣慰的是，Google的F1給我們提供了很好的實(shí)現(xiàn)參考，TiDB即是根據(jù)F1的啟發(fā)進(jìn)行的研發(fā)，感興趣的同學(xué)可以看下相關(guān)的內(nèi)容。

易用透明

我們可以將云數(shù)據(jù)庫(kù)想象成一個(gè)提供無(wú)限大容量的數(shù)據(jù)庫(kù)，傳統(tǒng)數(shù)據(jù)庫(kù)遇到單機(jī)數(shù)據(jù)存儲(chǔ)瓶頸的問(wèn)題將不復(fù)存在。已有的程序基本上不怎么需要修改已有的代碼，就可以很自然地接入到云數(shù)據(jù)庫(kù)中來(lái)獲得無(wú)限Scale的能力。增減數(shù)據(jù)庫(kù)節(jié)點(diǎn)，或者節(jié)點(diǎn)的故障恢復(fù)，對(duì)于應(yīng)用層來(lái)說(shuō)完全透明。另外，云數(shù)據(jù)庫(kù)的監(jiān)控、運(yùn)維、部署、備份等等操作都可以在云端通過(guò)高效的自動(dòng)化工具來(lái)自動(dòng)完成，極大地降低了運(yùn)維成本。

多租戶

云數(shù)據(jù)庫(kù)本身應(yīng)該是可以彈性伸縮的，所以很自然的，從資源利用率的角度來(lái)考慮，多個(gè)不同用戶的數(shù)據(jù)庫(kù)服務(wù)底層會(huì)跑在一個(gè)共享的云數(shù)據(jù)庫(kù)中。因此多租戶技術(shù)會(huì)成為云數(shù)據(jù)庫(kù)的標(biāo)配。但是這里面就有一個(gè)不得不面對(duì)的問(wèn)題，如何做到不同用戶的隔離性？

用戶數(shù)據(jù)隔離是相對(duì)比較容易的，比如還是以電商用戶（這里說(shuō)的是電商企業(yè)，不是顧客客戶）為例，每個(gè)用戶都有一個(gè)唯一的ID，這樣在云數(shù)據(jù)庫(kù)的底層存儲(chǔ)中，可以保證每個(gè)用戶數(shù)據(jù)都帶有自己ID前綴，用戶登陸進(jìn)來(lái)的時(shí)候可以根據(jù)這個(gè)前綴規(guī)則，獲取他對(duì)應(yīng)的數(shù)據(jù)，同時(shí)他看不到其他用戶的數(shù)據(jù)。

在一個(gè)真實(shí)的多租戶環(huán)境下面，純粹的數(shù)據(jù)隔離往往是不夠的，你還需要做到資源公平性的隔離。比如有的用戶寫(xiě)一個(gè)SQL，這個(gè)SQL沒(méi)有做優(yōu)化，主要做的事情是一個(gè)全表描掃，這個(gè)表的數(shù)據(jù)量特別特別大，這樣他會(huì)吃掉很多的CPU、Memory、IO等資源，導(dǎo)致其他用戶很輕量級(jí)的SQL操作都可能會(huì)變得很慢，影響到其他用戶實(shí)際的體驗(yàn)。

那么針對(duì)這種情況怎么做隔離？與此類似的還有，網(wǎng)絡(luò)帶寬怎么做隔離？大家都是跑在一個(gè)云數(shù)據(jù)庫(kù)上面的，如果一個(gè)用戶存放的數(shù)據(jù)特別大，他把帶寬都吃掉了，別人就顯得非常慢了。

還有一種情況，如果我本身作為一個(gè)租戶，內(nèi)部又怎么做隔離，大家知道 MySQL可以建很多Database，不同的Database給不同的團(tuán)隊(duì)來(lái)用，那么他們之間內(nèi)部隔離又怎么做，這個(gè)問(wèn)題就進(jìn)一步更加復(fù)雜了。

目前來(lái)講沒(méi)有特別好的方法，在一個(gè)分布式的環(huán)境下面去做很好的隔離，有兩個(gè)方向可以考慮：

第一種是最簡(jiǎn)單也是有效的方法，制定一些規(guī)則，把某些用戶特別大的數(shù)據(jù)庫(kù)表遷移到獨(dú)享的服務(wù)器節(jié)點(diǎn)上面，這樣就不會(huì)影響其他用戶的服務(wù)，但是這里面就涉及到定制化的事情了，本身理念其實(shí)與云數(shù)據(jù)庫(kù)并不相符。

第二種就是依靠統(tǒng)計(jì)信息，做資源隔離和調(diào)度，但是這里面對(duì)技術(shù)的要求就比較高了。因?yàn)樵茢?shù)據(jù)庫(kù)是分布式的，所以一般的統(tǒng)計(jì)都要橫跨很多的機(jī)器，因?yàn)榫W(wǎng)絡(luò)原因，不可能做到完全準(zhǔn)確的統(tǒng)計(jì)，所有統(tǒng)計(jì)都是有延遲的。

比如說(shuō)對(duì)于某個(gè)用戶，現(xiàn)在統(tǒng)計(jì)到的流量是1個(gè)G，他可能突然就有一次峰值的網(wǎng)絡(luò)訪問(wèn)，可能下一次統(tǒng)計(jì)消耗的流量是5個(gè)G（這里面只是舉例說(shuō)明問(wèn)題），如果你給他流量限制是1個(gè)G，中間統(tǒng)計(jì)的間隔是多少比較合適，如果間隔比較小，那么這個(gè)對(duì)整個(gè)系統(tǒng)的壓力就比較大，可能影響正常的用戶SQL訪問(wèn)，另外本身這個(gè)流量限制的系統(tǒng)也是很復(fù)雜的系統(tǒng)。

調(diào)度算法一直是整個(gè)分布式系統(tǒng)領(lǐng)域很困難的一個(gè)問(wèn)題，如何做到隔離性和公平調(diào)度也是未來(lái)云數(shù)據(jù)庫(kù)非常有挑戰(zhàn)的一個(gè)事情。

低成本

低成本應(yīng)該是云時(shí)代基礎(chǔ)設(shè)施最明顯的特點(diǎn)。首先，云數(shù)據(jù)庫(kù)的高可用和容錯(cuò)能力，使得我們不再需要昂貴的硬件設(shè)備，只需要普通的X86服務(wù)器就可以提供服務(wù)。然后，受益于Docker的虛擬化技術(shù)，使得不同類型的應(yīng)用容器可以跑在同一個(gè)物理機(jī)上，這樣可以極大地提高資源的利用率。

其次，多租戶的支持，使得不同的用戶可以共用一套底層的數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)，在數(shù)據(jù)庫(kù)層面再一次提高了資源的利用效率。再次，云數(shù)據(jù)庫(kù)的自動(dòng)化運(yùn)維工具，降低了整個(gè)核心數(shù)據(jù)庫(kù)的運(yùn)維成本。最后，云數(shù)據(jù)庫(kù)資源是按需分配的，用戶完全可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，選購(gòu)合適的服務(wù)資源。

高吞吐

云數(shù)據(jù)庫(kù)雖然可以做到彈性擴(kuò)容，但是本身是分布式存儲(chǔ)的，雖然可以通過(guò)Batch Write、Pipeline和Router Cache等方式加快訪問(wèn)SQL請(qǐng)求的數(shù)據(jù)，但是相對(duì)傳統(tǒng)單機(jī)的數(shù)據(jù)庫(kù)來(lái)說(shuō)，在數(shù)據(jù)訪問(wèn)鏈路上至少也要多走一次網(wǎng)絡(luò)，所以大部分并發(fā)量不大的小數(shù)據(jù)量請(qǐng)求，都會(huì)比單機(jī)延遲要高一些。

也就是說(shuō)，當(dāng)沒(méi)有足夠高的并發(fā)SQL訪問(wèn)的話，其實(shí)不能完全體現(xiàn)云數(shù)據(jù)庫(kù)的性能優(yōu)勢(shì)，所以這也是我們?cè)谶x用云數(shù)據(jù)庫(kù)的時(shí)候需要認(rèn)識(shí)到的問(wèn)題，云數(shù)據(jù)庫(kù)更多的是追求高吞吐，而不是低延遲。

當(dāng)并發(fā)大到一定規(guī)模，云數(shù)據(jù)庫(kù)高吞吐特性就顯現(xiàn)出來(lái)了，即使在很高的并發(fā)下，依然可以維持相當(dāng)穩(wěn)定的延遲，而不會(huì)像單機(jī)數(shù)據(jù)庫(kù)那樣，延遲線性增長(zhǎng)。當(dāng)然，延遲的問(wèn)題，在合理的架構(gòu)設(shè)計(jì)方案下，可以通過(guò)緩存的方式得到極大的緩解。

數(shù)據(jù)安全

云數(shù)據(jù)庫(kù)的物理服務(wù)器分布在多個(gè)機(jī)房，這就為跨數(shù)據(jù)庫(kù)中心的數(shù)據(jù)安全提供了最基礎(chǔ)的硬件支持。談到金融業(yè)務(wù)，大家耳熟能詳?shù)目赡芫褪莾傻厝行?，比如北京有兩個(gè)機(jī)房，上海有一個(gè)。未來(lái)一切服務(wù)都跑在云上，金融類的業(yè)務(wù)當(dāng)然也不例外。相比其他業(yè)務(wù)，金融類業(yè)務(wù)對(duì)數(shù)據(jù)安全要求就要高得多。

當(dāng)然，每個(gè)公司內(nèi)部都有核心的業(yè)務(wù)，所以如果上云的話，也會(huì)有同樣的強(qiáng)烈需要。這樣，對(duì)云數(shù)據(jù)庫(kù)來(lái)說(shuō)，數(shù)據(jù)的一致性、分布式事務(wù)、跨數(shù)據(jù)中心的數(shù)據(jù)安全等更高端的需求有可能會(huì)日益強(qiáng)烈。常見(jiàn)的數(shù)據(jù)備份也有可能會(huì)被其他新的模式所取代或者弱化，比如基于Paxos/Raft的多副本方案，本身就保證了會(huì)有多份備份。

自動(dòng)負(fù)載平衡

對(duì)于云數(shù)據(jù)庫(kù)來(lái)說(shuō)，負(fù)載平衡是一個(gè)很重要的問(wèn)題，它直接決定了整個(gè)云數(shù)據(jù)庫(kù)系統(tǒng)性能的好壞，如果一個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)訪問(wèn)過(guò)熱的話，就需要考慮把數(shù)據(jù)遷移到其他的數(shù)據(jù)庫(kù)節(jié)點(diǎn)來(lái)分擔(dān)負(fù)載，不然就很容易出現(xiàn)性能瓶頸。整個(gè)負(fù)載平衡是一個(gè)動(dòng)態(tài)的過(guò)程，調(diào)度算法需要保證資源配比的最大平衡，還有保證數(shù)據(jù)遷移的過(guò)程對(duì)系統(tǒng)整體的負(fù)載影響最小。這在未來(lái)也是云數(shù)據(jù)庫(kù)需要解決的一個(gè)核心問(wèn)題。

小結(jié)

從目前已有的SQL數(shù)據(jù)庫(kù)實(shí)現(xiàn)方案來(lái)看，NewSQL應(yīng)該是最貼近于云數(shù)據(jù)庫(kù)理念的實(shí)現(xiàn)。NewSQL本身具有SQL、ACID和Scale的能力，天然就具備了云數(shù)據(jù)庫(kù)的一些特點(diǎn)。但是，從NewSQL到云數(shù)據(jù)庫(kù)，依然有很多需要挑戰(zhàn)的難題，比如多租戶、性能等。

上面提到的一些云數(shù)據(jù)庫(kù)的特點(diǎn)，也是PingCAP目前在著力實(shí)現(xiàn)的部分，TiDB 作為國(guó)內(nèi)第一個(gè)NewSQL的開(kāi)源項(xiàng)目，在與社區(qū)的共同努力下，我們?cè)谏显碌讋倓偘l(fā)布了beta版本，歡迎各位上Github了解我們。

隨著整個(gè)社區(qū)技術(shù)水平的發(fā)展和云時(shí)代新的業(yè)務(wù)需求的驅(qū)動(dòng)，除了PingCAP 的TiDB，相信會(huì)有更多的團(tuán)隊(duì)在這方面進(jìn)行探索，期待早日看到云數(shù)據(jù)庫(kù)成熟的那一天。

來(lái)源：InfoQ