1.簡(jiǎn)介

這張圖來(lái)自于李飛飛的一片文章，介紹了數(shù)據(jù)庫(kù)的過(guò)去和未來(lái)。

2.不同的數(shù)據(jù)類型

2.1.單機(jī)數(shù)據(jù)庫(kù)

經(jīng)常聽(tīng)到說(shuō)傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù)是一種shared-everything的架構(gòu)，怎么理解呢？

實(shí)際上這里的 everything 指的是馮·諾依曼架構(gòu)中的「計(jì)算」和「存儲(chǔ)」，而 shared 指的是單機(jī)數(shù)據(jù)庫(kù)可以隨意使用本地的所有「計(jì)算」和「存儲(chǔ)」資源。

(資料圖片僅供參考)

2.2.分布式數(shù)據(jù)庫(kù)

很快，單機(jī)數(shù)據(jù)庫(kù)就面臨著可擴(kuò)展性問(wèn)題，這時(shí)就需要通過(guò)加資源的方式解決，于是出現(xiàn)了兩種解決方案：Scale up 和 Scale out。

這里 Scale up 并不是指單機(jī)維度的 scale up，而是從資源視角的 scale up。

更具體地說(shuō)，也就是存儲(chǔ)池化：數(shù)據(jù)庫(kù)的底層存儲(chǔ)由原來(lái)的單機(jī)磁盤（磁盤陣列）、單機(jī)文件系統(tǒng)，演變?yōu)榛诜植际綁K存儲(chǔ)、分布式文件存儲(chǔ)、對(duì)象存儲(chǔ)等的 shared-storage 分布式數(shù)據(jù)庫(kù)。

Scale out 則是各個(gè)數(shù)據(jù)庫(kù)實(shí)例獨(dú)立運(yùn)行，實(shí)例之間通過(guò) raft/paxos 等共識(shí)算法實(shí)現(xiàn)數(shù)據(jù)同步，而不依賴底層的分布式存儲(chǔ)系統(tǒng)。

這就是所謂的 shared-nothing 分布式數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)不共享任何 IaaS 層的資源，完全依賴于 PaaS 層（DB）本身，去做高可用和強(qiáng)一致，實(shí)現(xiàn)分布式事務(wù)。

2.3.云原生數(shù)據(jù)庫(kù)

云原生數(shù)據(jù)庫(kù) = 分布式數(shù)據(jù)庫(kù)(scale out) + 資源池化(scale up)。

云原生 = 云 + 原生。「云」就代表著IaaS資源池化，「原生」意味著應(yīng)用（PaaS、SaaS）天然就是針對(duì)這種池化的特性進(jìn)行設(shè)計(jì)的。

現(xiàn)在的分布式數(shù)據(jù)庫(kù)大多是 shared-nothing 的，例如 tidb 和 ob，使用了本地盤。

一旦使用本地盤，就意味著無(wú)法上云，因?yàn)樵频奶匦跃褪琴Y源池化，所以要上云，就要使用公有云廠商提供的EBS、S3等云盤。

而云盤的性能沒(méi)有本地盤好，這就要求應(yīng)用層，也就是DB這一層，是面向公有云的基礎(chǔ)服務(wù)進(jìn)行設(shè)計(jì)的。

這就是云原生的數(shù)據(jù)庫(kù)，即在數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候，就考慮各種資源是在云上，以池化的方式提供。

這種方式意味著 shared-nothing 和 shared-everything 的結(jié)合：宏觀上看，是 shared-everything 的（未來(lái)內(nèi)存也會(huì)池化），從微觀上看，又是分布式的shared-nothing。

這是一種真正的算存分離：在單機(jī)部署情況下，通信就是計(jì)算通過(guò) Memory Bus、IO Bus和內(nèi)存、存儲(chǔ)通信。

但在集群部署的情況下，計(jì)算和存儲(chǔ)的通信就是網(wǎng)絡(luò)。數(shù)據(jù)庫(kù)剛誕生的年代，單機(jī)的存儲(chǔ)訪問(wèn)速度肯定要快于集群，但是隨著網(wǎng)絡(luò)、存儲(chǔ)等基礎(chǔ)設(shè)施的不斷發(fā)展，未來(lái)這個(gè)情況可能就不一定了，IaaS池化一定是未來(lái)，云計(jì)算一定是未來(lái)，數(shù)據(jù)庫(kù)上云一定是未來(lái)。

3.存在的問(wèn)題

分布式數(shù)據(jù)庫(kù)上k8s會(huì)遇到哪些問(wèn)題呢？

由于分布式數(shù)據(jù)庫(kù)在設(shè)計(jì)上就不是云原生的，一般比較適合 on-primises 部署，也就是直接部署在物理機(jī)上，而不是部署到云上。

由于使用本地盤，分布式數(shù)據(jù)庫(kù)不適合通過(guò) k8s 進(jìn)行部署。

但是，隨著基礎(chǔ)設(shè)施硬件的不斷發(fā)展，池化后的資源不會(huì)再成為性能瓶頸，所以云原生數(shù)據(jù)庫(kù)一定是數(shù)據(jù)庫(kù)的未來(lái)，現(xiàn)在的分布式數(shù)據(jù)庫(kù)也在往云原生數(shù)據(jù)庫(kù)的方向演進(jìn)，到那一天，有狀態(tài)應(yīng)用就可以在k8s上發(fā)揮它最大的威力。

4.本地盤

本地盤使用的是靜態(tài)PV，不支持動(dòng)態(tài) scale up，靈活性差。

cgroup v1的IO隔離機(jī)制有缺陷，無(wú)法對(duì)buffered IO的IOPS進(jìn)行很好的限制。

本地盤在做節(jié)點(diǎn)遷移時(shí)，需要遷移數(shù)據(jù)。眾所周知移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更方便。

沒(méi)法利用k8s的自我修復(fù)能力。比如節(jié)點(diǎn)掛了，你可以通過(guò)起一個(gè)新的Pod的方式進(jìn)行修復(fù)。但是如果用了本地盤，這個(gè)Pod卻必須調(diào)度到原節(jié)點(diǎn)。

5.網(wǎng)盤

在公有云上，使用網(wǎng)盤最大的問(wèn)題第一是延遲抖動(dòng)；第二是性能比本地盤要差很多。如何在軟件層面克服這種問(wèn)題是云原生數(shù)據(jù)庫(kù)要攻克的難關(guān)。

現(xiàn)有的云原生數(shù)據(jù)庫(kù)（比如snowflake）一般都是面向OLAP的數(shù)據(jù)倉(cāng)庫(kù)，原因在于數(shù)據(jù)倉(cāng)庫(kù)對(duì)于吞吐的要求其實(shí)是更高的，對(duì)于延遲并不是那么在意，一個(gè) query 可能跑五秒出結(jié)果就行了，不用要求五毫秒之內(nèi)給出結(jié)果。

特別是對(duì)于一些 Point Lookup 這種場(chǎng)景來(lái)說(shuō)，Shared Nothing 的 database 可能只需要從客戶端的一次 rpc，但是對(duì)于計(jì)算與存儲(chǔ)分離的架構(gòu)，中間無(wú)論如何要走兩次網(wǎng)絡(luò)，這是一個(gè)核心的問(wèn)題。

Aurora 是一個(gè)計(jì)算存儲(chǔ)分離架構(gòu)，但它是一個(gè)單機(jī)數(shù)據(jù)庫(kù)，Spanner 是一個(gè)純分布式的數(shù)據(jù)庫(kù)，純 Shared Nothing 的架構(gòu)并沒(méi)有利用到云基礎(chǔ)設(shè)施提供的一些優(yōu)勢(shì)。