縱觀過去十年數(shù)據(jù)庫(kù)的發(fā)展，其實(shí)是相當(dāng)迅速，隨著互聯(lián)網(wǎng)的發(fā)展以及業(yè)務(wù)數(shù)據(jù)量的不斷膨脹，大家漸漸發(fā)現(xiàn)傳統(tǒng)的單機(jī)RDBMS 開始出現(xiàn)一些瓶頸，很多業(yè)務(wù)的模型也和當(dāng)初數(shù)據(jù)庫(kù)設(shè)計(jì)的場(chǎng)景不太一樣，一個(gè)最典型的思潮就是反范式設(shè)計(jì)，通過適當(dāng)?shù)臄?shù)據(jù)冗余來減小 JOIN 帶來的開銷，當(dāng)初 *-NF 的設(shè)計(jì)目的是盡可能的減小數(shù)據(jù)冗余，但現(xiàn)在的硬件和存儲(chǔ)容量遠(yuǎn)非當(dāng)年可比，而且存儲(chǔ)介質(zhì)也在慢慢發(fā)生變化，從磁帶到磁盤到閃存，甚至最近慢慢開始變成另一個(gè)異構(gòu)的分布式存儲(chǔ)系統(tǒng) (如 Google F1, TiDB)，RDBMS 本身也需要進(jìn)化。

 

在 NoSQL 蓬勃發(fā)展的這幾年也是 Web 和移動(dòng)端崛起的幾年，但是在 NoSQL 中反范式的設(shè)計(jì)是需要以付出一致性為代價(jià)，不過這個(gè)世界的業(yè)務(wù)多種多樣，大家漸漸發(fā)現(xiàn)將一致性交給業(yè)務(wù)去管理會(huì)極大的增加業(yè)務(wù)的復(fù)雜度，但是在數(shù)據(jù)庫(kù)層做又沒有太好的可以 Scale 的方案，SPOF 問題和單機(jī)性能及帶寬瓶頸會(huì)成為懸在業(yè)務(wù)頭上的達(dá)摩克利斯之劍。

 

NewSQL 的出現(xiàn)就是為了解決擴(kuò)展性和一致性之間的矛盾，我所理解的 NewSQL 主要還是面向 OLTP 業(yè)務(wù)和輕量級(jí)的OLAP業(yè)務(wù)，大型復(fù)雜的OLAP 數(shù)據(jù)庫(kù)暫時(shí)不在本文討論的范圍。對(duì)于NewSQL 來說，我覺得應(yīng)該需要明確一下必備的性質(zhì)，什么樣的數(shù)據(jù)庫(kù)才能稱之為NewSQL，在我看來，應(yīng)該有以下幾點(diǎn)必備的特性：

SQL 一切為了兼容性!兼容性!兼容性! SQL 的支持是和之前 NoSQL 從接口上最大的不同點(diǎn)， 但是在一個(gè)分布式系統(tǒng)上支持 SQL 和在單機(jī) RDBMS 上也是完全不一樣的，更關(guān)鍵的是如何更好的利用多個(gè)節(jié)點(diǎn)的計(jì)算能力，生成更好的執(zhí)行計(jì)劃，將計(jì)算邏輯盡可能的均攤到多個(gè)存儲(chǔ)節(jié)點(diǎn)上，設(shè)計(jì)這樣一個(gè) SQL engine 的更像是在做一個(gè)分布式計(jì)算框架，考慮的側(cè)重點(diǎn)和單機(jī)上的查詢引擎是不一樣的，畢竟網(wǎng)絡(luò)的開銷和延遲是單機(jī)數(shù)據(jù)庫(kù)之前完全不需要考慮的。

 

不過 從最近幾年社區(qū)的實(shí)現(xiàn)來看，尤其是一些 OLAP 的系統(tǒng)，已經(jīng)有不少優(yōu)秀的分布式SQL 實(shí)現(xiàn) ，比如： Hive, Impala，Presto, SparkSQL 等優(yōu)秀的開源項(xiàng)目。雖然 OLTP 的 SQL engine 和 OLAP 的側(cè)重點(diǎn)有所不同，但是很多技術(shù)是相通的，但是一些單機(jī) RDBMS 的 SQL 是很難直接應(yīng)用在分布式環(huán)境下的，比如存儲(chǔ)過程和視圖等。正如剛才提到的，越來越多的業(yè)務(wù)開始接受反范式的設(shè)計(jì)，甚至很多新的業(yè)務(wù)都禁止使用存儲(chǔ)過程和外鍵等，這是一個(gè)好的現(xiàn)象。

 

ACID Transaction 對(duì)于 OLTP 類型的 NewSQL 來說，最重要的特點(diǎn)我認(rèn)為是需要支持 ACID 的跨行事務(wù)，其實(shí)隔離級(jí)別和跨行事務(wù)是個(gè)好東西，能用更少的代碼寫出正確的程序，這個(gè)交給業(yè)務(wù)程序員寫基本費(fèi)時(shí)費(fèi)力還很難寫對(duì)，但在分布式場(chǎng)景下支持分布式事務(wù)需要犧牲點(diǎn)什么。

 

本身分布式 MVCC 并不是太難做，在 Google BigTable / Spanner 這樣的系統(tǒng)中顯式的多版本已經(jīng)是標(biāo)配，那么其實(shí)犧牲掉的是一定的延遲，因?yàn)樵诜植际綀?chǎng)景中實(shí)現(xiàn)分布式事務(wù)在生產(chǎn)環(huán)境中基本就只有兩階段提交的一種辦法，不過呢，考慮到 Multi-Paxos 或者 Raft 這樣的復(fù)制協(xié)議總是要 有延遲的，兩階段提交所帶來的 contention cost 相比復(fù)制其實(shí)也不算太多，對(duì)于一個(gè)分布式數(shù)據(jù)庫(kù)來說我們優(yōu)化的目標(biāo)永遠(yuǎn)是吞吐。延遲問題也可以通過緩存和靈活降低隔離級(jí)別等方法 搞定。

 

很多用戶在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，通常會(huì)避免分布式事務(wù)，但是這其實(shí)將很多復(fù)雜度轉(zhuǎn)移給了業(yè)務(wù)層，而且實(shí)現(xiàn)正確的事務(wù)語(yǔ)義是非常復(fù)雜的事情，對(duì)于開發(fā)者的要求還蠻高的，之前其實(shí)沒有太多的辦法，因?yàn)閹缀鯖]有一個(gè)方案能在數(shù)據(jù)庫(kù)層面上支持事務(wù)，但是有些對(duì)一致性的要求很高的業(yè)務(wù)對(duì)此仍然是繞不開的。

 

就如同 Google 的 Senior Fellow Engineer，Jeff Dean 在 去年的一個(gè)會(huì)議上提到，作為工程師最后悔的事情就是沒有在 BigTable 上支持跨行事務(wù)，以 至于在隨后的 10 多年，Google 內(nèi)部的團(tuán)隊(duì)前赴后繼的在 BigTable 上造了多套事務(wù)的輪子以支撐業(yè)務(wù)，不過這個(gè)遺憾在 Spanner 中已經(jīng)彌補(bǔ)了，也算是 happy ending。

 

其實(shí) Spanner 的例子是非常好的，而且我認(rèn)為 Google Spanner 及 F1 是第一個(gè)在線上大規(guī)模使用的 NewSQL 系統(tǒng)，很多經(jīng)驗(yàn)和設(shè)計(jì)我們這些后來者是可以借鑒的。我認(rèn)為，從使用者的角度來 說，濫用事務(wù)帶來的性能問題不能作為在數(shù)據(jù)庫(kù)層面上不支持的理由，很多場(chǎng)景如果使用得當(dāng) ，能極大的降低業(yè)務(wù)開發(fā)的復(fù)雜度。

 

Scale 作為一個(gè)現(xiàn)代的數(shù)據(jù)庫(kù)，可擴(kuò)展性我覺得是排在第一位的，而且這里的可擴(kuò)展性值得好好說一 下，目前關(guān)系型數(shù)據(jù)庫(kù)的擴(kuò)展方案上，基本只有分庫(kù)分表和 PROXY 中間件兩種方案，但是這兩種方案并沒有辦法做到透明的彈性擴(kuò)展，而且到達(dá)一定規(guī)模后的運(yùn)維成本幾乎是指數(shù)級(jí)別上升，這也是大多數(shù)公司在微服務(wù)實(shí)踐的過程中遇到的最大障礙，服務(wù)可以很好的做到無狀態(tài)和解耦合，但是數(shù)據(jù)天然是有狀態(tài)的，比較理想的情況是有一個(gè)統(tǒng)一的，通用的存儲(chǔ)層，讓服務(wù)層能夠放開手腳。

 

彈性擴(kuò)展的技術(shù)在很多 NoSQL 里已經(jīng)有過很好的實(shí)踐，目前比較成熟的 方案還是類 BigTable 式的 Region based 的方案，在 Key-Value 層面上實(shí)現(xiàn)水平擴(kuò)展。另外值得一提的是，對(duì)于 NewSQL 這類需要支持 SQL 的數(shù)據(jù)庫(kù)而言，region based 的數(shù)據(jù)切分是目前唯一的方案， 因?yàn)?SQL 的查詢需要支持順序 Scan 的數(shù)據(jù)訪問方式，基于一致性哈希的方案很難支持高效的順序訪問。這

 

里隱含了一個(gè)假設(shè)就是真正能夠支持 Scale 的 NewSQL 架構(gòu)很難是基于中間件的方案，SQL above NoSQL 是目前來說唯一的可行方案，從 Google 的選型也能看出來。

 

基于中間件的方案的問題是中間件很難生成足夠高效的執(zhí)行計(jì)劃，而且底 層的多個(gè)數(shù)據(jù)庫(kù)實(shí)例之間并沒有辦法提供一個(gè)統(tǒng)一的事務(wù)語(yǔ)義，在執(zhí)行跨節(jié)點(diǎn)的 JOIN 或者事務(wù)的時(shí)候沒有辦法保證一致性，另外底層的數(shù)據(jù)庫(kù)實(shí)例(一般來說是 PostgreSQL 或者 MySQL) 本身并沒有原生的擴(kuò)展方案，需要中間件層面上額外做大量的工作，這也是為什么中間件的方案很多，但是做完美非常困難。

 

Failover 目前大多數(shù)的數(shù)據(jù)庫(kù)的復(fù)制模型還是基于主從的方案，但是主從的方案本質(zhì)上來說是沒有辦法脫離人工運(yùn)維的，所以這個(gè)模型是很難 Scale 的 。如果需要做 Auto failover，從庫(kù)何時(shí)提升成主庫(kù)，主庫(kù)是否完全下線，提升起來的從庫(kù)是否擁有最新的數(shù)據(jù)?尤其如果出現(xiàn)集群腦裂的 狀況，一旦 Auto failover 設(shè)計(jì)得不周全，甚至可能出現(xiàn)雙主的嚴(yán)重故障。

 

所以數(shù)據(jù)的一致性是需要 DBA 的人工介入保證，但是在數(shù)據(jù)量比較龐大的情況下，人工可運(yùn)維的規(guī)模是有上限的，比如 Google 在 F1 之前，維護(hù)了一個(gè) 100 節(jié)點(diǎn)左右的 MySQL 中間件集群支持同樣的業(yè) 務(wù)，在這個(gè)規(guī)模之下維護(hù)的成本就已經(jīng)非常高了，使得 Google 不惜以從零開始重新開發(fā)一個(gè)數(shù)據(jù)庫(kù)為代價(jià)。

 

從 Google 在 Spanner 和 F1 以及現(xiàn)在流行的開源 NewSQL 方案，比如 TiDB 和 CockroachDB 等可以看到，在復(fù)制模型上都沒有選擇主從的模型，而是選用了 Multi-Paxos 或者 Raft 這樣基于分布式選舉的復(fù)制協(xié)議。

 

Multi-Paxos (以下出于省略暫用 Paxos 來指代，但是實(shí)際上兩者有些不一樣，在本文特指 Multi-Paxos) 和 Raft 的原理由于篇幅原因就不贅述了，簡(jiǎn)單來說，它們是高度自動(dòng)化，強(qiáng)一 致的復(fù)制算法，在某節(jié)點(diǎn)故障的時(shí)候，支持完全自動(dòng)和強(qiáng)一致的故障轉(zhuǎn)移和自我恢復(fù)，這樣才能做到用戶層的透明，但是這里有一個(gè)技術(shù)的難點(diǎn)，即Scale 策略與這樣的復(fù)制協(xié)議的融合， 多個(gè) Paxos / Raft Group 的分裂、合并以及調(diào)度，以及相關(guān)的測(cè)試。

 

這個(gè)技術(shù)的門檻比較高 ，實(shí)現(xiàn)起來的復(fù)雜度也比較高，但是作為一個(gè) Scale 的數(shù)據(jù)庫(kù)來說，是一定要實(shí)現(xiàn)的，在目前的開源實(shí)現(xiàn)中，只有 PingCAP 的 TiDB 的成熟度和穩(wěn)定度是比較高的，有興趣的朋友可以參考 TiDB (github.com/pingcap/tidb) 的實(shí)現(xiàn)。

 

Failover 相關(guān)的另外一個(gè)話題是跨數(shù)據(jù)中心多活，這個(gè)基本上是所有分布式系統(tǒng)開發(fā)者心中的 圣杯。目前也是基本沒有方案，大多數(shù)的多活的方案還是同步熱備，而且很難在保證延遲的情 況下同時(shí)保持一致性，但是 Paxos 和 Raft based 的方案給多活提供了一種新的可能性，這類選舉算法，只要一個(gè) paxos / raft group 內(nèi)的大多數(shù)節(jié)點(diǎn)復(fù)制成功，即可給客戶端返回成功。

 

舉一個(gè)簡(jiǎn)單的例子，如果這個(gè) group 內(nèi)有三個(gè)節(jié)點(diǎn)，分別在北京，廊坊，廣州的三個(gè)數(shù)據(jù)中心，對(duì)于傳統(tǒng)的強(qiáng)一致方案，一個(gè)在北京發(fā)起的寫入需要等待廣州的數(shù)據(jù)中心復(fù)制完畢，才能 給客戶端返回成功，但是對(duì)于 paxos 或者 raft 這樣的算法，其實(shí)延遲僅僅是北京和廊坊之間 數(shù)據(jù)中心的延遲，比傳統(tǒng)方案大大的降低了延遲，雖然對(duì)于帶寬的要求仍然很高，但是我覺得這是在數(shù)據(jù)庫(kù)層面上未來實(shí)現(xiàn)跨數(shù)據(jù)中心多活的一個(gè)趨勢(shì)和可行的方向。

 

按照 Google 在 Spanner 論文中的描述，Google 的數(shù)據(jù)中心分別位于美國(guó)西海岸，東海岸，以及中部，所以 總體的寫入延遲控制在半個(gè)美國(guó)的范圍內(nèi)，還是可以接受的。

 

未來在哪里不妨把眼光稍微放遠(yuǎn)一些，其實(shí)仔細(xì)想想 NewSQL 一直在嘗試解決問題是：擺脫人工運(yùn)維束縛，存儲(chǔ)層實(shí)現(xiàn)真正的自生長(zhǎng)，自維護(hù)，同時(shí)用戶可以以最自然的編程接口訪問和存儲(chǔ)數(shù)據(jù)。 當(dāng)實(shí)現(xiàn)這點(diǎn)以后，業(yè)務(wù)才可以擺脫存儲(chǔ)的介質(zhì)，容量的限制，而專注于邏輯實(shí)現(xiàn)。

 

大規(guī)模的分布式和多租戶是必然的選擇，其實(shí)這個(gè)目標(biāo)和云的目標(biāo)是很接近的，實(shí)際上數(shù)據(jù)庫(kù)是云不可或缺的一部分，不過現(xiàn)在的數(shù)據(jù)庫(kù)都太不 Cloud-Native 了，所以如何和云更緊密結(jié)合，更好的利用云的資源調(diào)度，如何對(duì)業(yè)務(wù)透明的同時(shí)無縫的在云上自我進(jìn)化是我最近思考得比較多的問 題。在這個(gè)領(lǐng)域Google 是走在時(shí)代前沿的，從幾個(gè) NewSQL 的開源實(shí)現(xiàn)者都不約而同的選 擇了 Spanner 和 F1 的模型上可以看得出來。