雲數據庫是一種全新的數據庫技術?引言暢想一下，未來的服務都跑在雲端，任何的服務資源都可以像水電煤一樣按需選購從IaaS層的容器/虛拟機，到PaaS層的數據庫，緩存和計算單元，再到SaaS層的不同類型的應用，我們隻需要根據自身業務特點進行資源選配，再也不用擔心應用服務支撐不住高速的業務增長，因為在雲上一切都是彈性伸縮的，下面我們就來聊聊關于雲數據庫是一種全新的數據庫技術?接下來我們就一起去了解一下吧!

雲數據庫是一種全新的數據庫技術

引言

最近幾年，随着雲計算相關技術的發展，各種不同類型的雲層出不窮，服務越來越多不同類型的企業業務，傳統企業也漸漸開始探索上雲的道路。在雲上，作為業務最核心的數據庫，相比之前的傳統方案會有哪些變化呢？在正式聊雲時代的數據庫特點之前，我們需要了解一下目前雲時代架構發生的變化。

暢想一下，未來的服務都跑在雲端，任何的服務資源都可以像水電煤一樣按需選購。從IaaS層的容器/虛拟機，到PaaS層的數據庫，緩存和計算單元，再到SaaS層的不同類型的應用，我們隻需要根據自身業務特點進行資源選配，再也不用擔心應用服務支撐不住高速的業務增長，因為在雲上一切都是彈性伸縮的。

有了可靠的基礎軟件架構，我們就可以把更多精力放到新業務的探索，新模式的創新，就有可能産生更多不一樣的新場景，從而催生更強大能力的雲端服務，這是一件多麼cool的事情。

當然，理想要一步一步實現，未來的基礎軟件棧到底會怎樣呢？社區在這方面正在進行積極地探索，其中最有代表性的就是基于容器（以Docker為代表）的虛拟化技術和微服務（microservice）。

在雲時代，一切都應該是可伸縮的，使用 k8s（Kubernetes）在保證資源平衡的前提下，通過Docker部署我們依托于容器的微服務模塊，我們不用關心服務到底跑在哪裡，隻需要關心我們需要多少服務資源。Docker提供了極大的便利性，一次構建，到處運行，我們可以很好地解決開發、測試和上線的環境一緻性問題。（如果不能很好地保證測試和實際上線環境的一緻性，則很有可能需要花費遠超過開發的時間去發現和修複問題。）

k8s 更是在 Docker 構建的基礎上增加了更多的雲特性，包括Docker的升級，高可用和彈性伸縮等等。 關于Docker/k8s相關的讨論已經很多了，因為時間關系，關于具體的細節就不再展開。我們隻需要了解，有了它，可以很輕松地解決服務的安裝和部署。

下面再聊聊微服務，微服務将一個服務拆分成相對獨立的更小的子服務單元，不同的子服務單元之間通過統一的接口 （HTTP/RPC等）進行數據交互。

相比于傳統的解決方案，這種架構有很多的優點。

1. 更好的開發效率和可維護性。微服務将一個單獨的服務進行更細力度的拆分，每一個子服務單元專注于更小的功能模塊，可以更好地根據業務建立對應的數據模型，降低複雜度，使得開發變得更輕松，維護和部署變得更加友好。

2. 更好的可擴展性。每個不同的子服務單元相互獨立，彼此之間沒有任何依賴，所以可以根據業務的具體需要，靈活地部署多個子服務單元進行水平擴展。

3. 更強的容錯性。當其中一個子服務出現故障的時候，可以通過輔助的負載均衡工具，自動路由到其他的子服務，不會影響整體服務的可用性。

當然，微服務也不是一個銀彈，相對來說，這種方案會使整體系統的設計更加複雜，同時也加大了網絡的延遲，對整個系統測試的複雜度也會更高。

Docker提供的隔離型和可移植性，與微服務是一種天然的契合，微服務将整個軟件進行拆分和解耦，而通過Docker/k8s可以很自然地做到獨立的部署，高可用和容錯性，似乎一切都可以完美地運轉起來。但是真的是這樣麼？我們是不是忽略了什麼？

是的，我們在讨論前面的問題的時候忽略了一個很重要的東西：狀态。

從整個技術發展的角度來看，微服務是一個非常有意義的探索。每個人都期望着每個微服務的子服務都是無狀态的，這樣我可以自由地啟停和伸縮，沒有任何的心智負擔，但是現實的業務情況是什麼樣的呢？

比如一個電商網站，用戶正在下單購買一件商品，此時平台是通過訂單子服務的A應用來提供服務的，突然，因為機器故障，訂單子服務的A應用不可用了，改由訂單子服務的B應用提供服務，那麼它是必須要知道剛才用戶的訂單信息的，否則正在訪問自己訂單頁面的用戶會發現自己的訂單信息突然不見了。

雖然我們盡量想把子服務設計成無狀态的，但是很多時候狀态都是不可避免的，我們不得不通過存儲層保存狀态，業界最主要的還是各種數據庫，包括RDBMS和NoSQL，比如使用MySQL、MongoDB、HBase、Cassandra等，特别是有些場景還要考慮數據一緻性問題的時候，更加重了對存儲層的依賴。

由此可見，雲計算時代系統的架構發生了巨大的變化，這一方面為用戶提供了更優秀的特性，另一方面也對雲計算的組件提出了更高的要求。數據庫作為雲計算最基礎的組件之一，也需要适應這種架構的變化。（這裡我們主要關注 SQL 數據庫，雲時代的數據庫以下簡稱雲數據庫。）

那麼雲數據庫主要有一些什麼樣的特點呢？我認為主要有以下幾點。

彈性伸縮

傳統的數據庫方案，常見的會選用Oracle, MySQL,PostgreSQL。在雲時代，數據量的規模有爆發性的增長，傳統的數據庫很容易遇到單機的存儲瓶頸，不得不選用一些集群方案，常見的比如 Oracle RAC、 MySQL Sharding等，而這些集群方案或多或少都有一些不令人滿意的地方。

比如說，Oracle RAC通過共享存儲的硬件方案解決集群問題，這種方式基本上隻能通過停機換用更大的共享内存硬件來解決擴容問題，RAC節點過多會帶來更多的并發問題，同樣也會帶來更高的成本。

以MySQL Sharding為代表的數據分片方案，很多時候不得不提前對數據量進行規劃，把擴容作為很重要的一個計劃來做，從DBA到運維到測試到開發人員，很早之前就要做相關的準備工作，真正擴容的時候，為了保證數據安全，經常會選擇停服務來保證沒有新的數據寫入，新的分片數據同步後還要做數據的一緻性校驗。

當然業界大公司有足夠雄厚的技術實力，可以采用更複雜的方案，将擴容停機時間盡量縮短（但是很難縮減到0），但是對于大部分中小互聯網公司和傳統企業，依然無法避免較長時間的停服務。

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

比如作為一個電商用戶，在雙11促銷活動之前，可以通過增加數據庫節點的方式，擴大更多的資源池，用來部署相應的容器服務，當活動結束之後，再将多餘的資源移除去支持其他的服務，這樣可以極大地提高資源的利用率，同樣可以彈性地支撐各種峰值業務。

高可用

傳統的MySQL方案，數據複制的時候默認采用異步的方式，對于一個寫入的請求，主庫寫入成功後就會返回成功信息給客戶端，但是這個時候數據可能還沒有同步給從庫，一旦主庫這個時候挂掉了，啟動從庫的時候就會有丢失數據的風險。

當然，也有人會選擇半同步的複制方式，這種方式在正常情況下是同步的，但是在遇到數據壓力比較大的時候，依然會退化為異步的方式，所以本質上來說，同樣有丢失數據的風險。其他也有一些多主的同步方案，比如在應用層做數據同步，但是這種方式一是需要應用層的配合，二是在對網絡超時的處理非常複雜，增加心智負擔。

在雲時代，因為所有的數據庫資源都是分布式存儲的，每個數據庫節點出現問題都是很正常的事情，所以就必須有一種可以實現數據一緻性的數據複制方式來保證服務的高可用，業界給出的答案就是：Paxos/Raft（關于Paxos和Raft的實現細節我們不在這裡展開）。

PingCAP在做的TiDB就是選擇了Raft協議，Raft協議看起來更像是一個多副本的自适應的主從複制協議，對于每次寫請求，Raft都會保證大多數寫成功才會返回客戶端，即使Raft Group的Leader挂掉了，在一個有限的時間範圍内，會很快地選出一個新的Leader出來，繼續提供服務。

同樣，對于一個3副本的Raft Group，隻要2個寫入成功，就可以保證成功，而大多數情況下，最先寫入成功的往往是與Leader網絡情況最好的那個副本，所以這種Majority寫的方式，可以很自然地選擇速度最快的副本進行數據同步複制。另外，Raft協議本身支持Config Change，增加一個新的節點，可以很容易地做副本數據分布的變更，而不需要停止任何服務。

同樣，在雲時代，數據庫的DDL操作也會是一個非常有趣的事情。以一個常見的Add Column操作為例，在表規模已經很大的情況下，在傳統的實現方案中，比較有參考意義的是，通過一些工具，創建類似表級别的觸發器，将原表的數據同步到一個新的臨時表中，當數據追平的時候，再進行一個鎖表操作，将臨時表命名為原表，這樣一個Add Column操作就完成了。

但是在雲時代，分布式的數據存儲方式決定了這種方案很難實現，因為每個數據庫節點很難保證Schema狀态變更的一緻性，而且當數據規模增長到幾十億，幾百億甚至更多的時候，很短的阻塞時間都有可能會導緻很大的負載壓力變化，所以DDL操作必須是保證無阻塞的在線操作。值得欣慰的是，Google的F1給我們提供了很好的實現參考，TiDB即是根據F1的啟發進行的研發，感興趣的同學可以看下相關的内容。

易用透明

我們可以将雲數據庫想象成一個提供無限大容量的數據庫，傳統數據庫遇到單機數據存儲瓶頸的問題将不複存在。已有的程序基本上不怎麼需要修改已有的代碼，就可以很自然地接入到雲數據庫中來獲得無限Scale的能力。增減數據庫節點，或者節點的故障恢複，對于應用層來說完全透明。另外，雲數據庫的監控、運維、部署、備份等等操作都可以在雲端通過高效的自動化工具來自動完成，極大地降低了運維成本。

多租戶

雲數據庫本身應該是可以彈性伸縮的，所以很自然的，從資源利用率的角度來考慮，多個不同用戶的數據庫服務底層會跑在一個共享的雲數據庫中。因此多租戶技術會成為雲數據庫的标配。但是這裡面就有一個不得不面對的問題，如何做到不同用戶的隔離性？

用戶數據隔離是相對比較容易的，比如還是以電商用戶（這裡說的是電商企業，不是顧客客戶）為例，每個用戶都有一個唯一的ID，這樣在雲數據庫的底層存儲中，可以保證每個用戶數據都帶有自己ID前綴，用戶登陸進來的時候可以根據這個前綴規則，獲取他對應的數據，同時他看不到其他用戶的數據。

在一個真實的多租戶環境下面，純粹的數據隔離往往是不夠的，你還需要做到資源公平性的隔離。比如有的用戶寫一個SQL，這個SQL沒有做優化，主要做的事情是一個全表描掃，這個表的數據量特别特别大，這樣他會吃掉很多的CPU、Memory、IO等資源，導緻其他用戶很輕量級的SQL操作都可能會變得很慢，影響到其他用戶實際的體驗。

那麼針對這種情況怎麼做隔離？與此類似的還有，網絡帶寬怎麼做隔離？大家都是跑在一個雲數據庫上面的，如果一個用戶存放的數據特别大，他把帶寬都吃掉了，别人就顯得非常慢了。

還有一種情況，如果我本身作為一個租戶，内部又怎麼做隔離，大家知道 MySQL可以建很多Database，不同的Database給不同的團隊來用，那麼他們之間内部隔離又怎麼做，這個問題就進一步更加複雜了。

目前來講沒有特别好的方法，在一個分布式的環境下面去做很好的隔離，有兩個方向可以考慮：

第一種是最簡單也是有效的方法，制定一些規則，把某些用戶特别大的數據庫表遷移到獨享的服務器節點上面，這樣就不會影響其他用戶的服務，但是這裡面就涉及到定制化的事情了，本身理念其實與雲數據庫并不相符。

第二種就是依靠統計信息，做資源隔離和調度，但是這裡面對技術的要求就比較高了。因為雲數據庫是分布式的，所以一般的統計都要橫跨很多的機器，因為網絡原因，不可能做到完全準确的統計，所有統計都是有延遲的。

比如說對于某個用戶，現在統計到的流量是1個G，他可能突然就有一次峰值的網絡訪問，可能下一次統計消耗的流量是5個G（這裡面隻是舉例說明問題），如果你給他流量限制是1個G，中間統計的間隔是多少比較合适，如果間隔比較小，那麼這個對整個系統的壓力就比較大，可能影響正常的用戶SQL訪問，另外本身這個流量限制的系統也是很複雜的系統。

調度算法一直是整個分布式系統領域很困難的一個問題，如何做到隔離性和公平調度也是未來雲數據庫非常有挑戰的一個事情。

低成本

低成本應該是雲時代基礎設施最明顯的特點。首先，雲數據庫的高可用和容錯能力，使得我們不再需要昂貴的硬件設備，隻需要普通的X86服務器就可以提供服務。然後，受益于Docker的虛拟化技術，使得不同類型的應用容器可以跑在同一個物理機上，這樣可以極大地提高資源的利用率。

其次，多租戶的支持，使得不同的用戶可以共用一套底層的數據庫存儲系統，在數據庫層面再一次提高了資源的利用效率。再次，雲數據庫的自動化運維工具，降低了整個核心數據庫的運維成本。最後，雲數據庫資源是按需分配的，用戶完全可以根據自身的業務特點，選購合适的服務資源。

高吞吐

雲數據庫雖然可以做到彈性擴容，但是本身是分布式存儲的，雖然可以通過Batch Write、Pipeline和Router Cache等方式加快訪問SQL請求的數據，但是相對傳統單機的數據庫來說，在數據訪問鍊路上至少也要多走一次網絡，所以大部分并發量不大的小數據量請求，都會比單機延遲要高一些。

也就是說，當沒有足夠高的并發SQL訪問的話，其實不能完全體現雲數據庫的性能優勢，所以這也是我們在選用雲數據庫的時候需要認識到的問題，雲數據庫更多的是追求高吞吐，而不是低延遲。

當并發大到一定規模，雲數據庫高吞吐特性就顯現出來了，即使在很高的并發下，依然可以維持相當穩定的延遲，而不會像單機數據庫那樣，延遲線性增長。當然，延遲的問題，在合理的架構設計方案下，可以通過緩存的方式得到極大的緩解。

數據安全

雲數據庫的物理服務器分布在多個機房，這就為跨數據庫中心的數據安全提供了最基礎的硬件支持。談到金融業務，大家耳熟能詳的可能就是兩地三中心，比如北京有兩個機房，上海有一個。未來一切服務都跑在雲上，金融類的業務當然也不例外。相比其他業務，金融類業務對數據安全要求就要高得多。

當然，每個公司内部都有核心的業務，所以如果上雲的話，也會有同樣的強烈需要。這樣，對雲數據庫來說，數據的一緻性、分布式事務、跨數據中心的數據安全等更高端的需求有可能會日益強烈。常見的數據備份也有可能會被其他新的模式所取代或者弱化，比如基于Paxos/Raft的多副本方案，本身就保證了會有多份備份。

自動負載平衡

對于雲數據庫來說，負載平衡是一個很重要的問題，它直接決定了整個雲數據庫系統性能的好壞，如果一個數據庫節點的數據訪問過熱的話，就需要考慮把數據遷移到其他的數據庫節點來分擔負載，不然就很容易出現性能瓶頸。整個負載平衡是一個動态的過程，調度算法需要保證資源配比的最大平衡，還有保證數據遷移的過程對系統整體的負載影響最小。這在未來也是雲數據庫需要解決的一個核心問題。

小結

從目前已有的SQL數據庫實現方案來看，NewSQL應該是最貼近于雲數據庫理念的實現。NewSQL本身具有SQL、ACID和Scale的能力，天然就具備了雲數據庫的一些特點。但是，從NewSQL到雲數據庫，依然有很多需要挑戰的難題，比如多租戶、性能等。

上面提到的一些雲數據庫的特點，也是PingCAP目前在着力實現的部分，TiDB 作為國内第一個NewSQL的開源項目，在與社區的共同努力下，我們在上月底剛剛發布了beta版本，歡迎各位上Github了解我們。

随着整個社區技術水平的發展和雲時代新的業務需求的驅動，除了PingCAP 的TiDB，相信會有更多的團隊在這方面進行探索， 期待早日看到雲數據庫成熟的那一天。

本文首發于InfoQ垂直号：「細說雲計算」（ID：CloudNote）

,