NoSQL沒落了？NewSQL有機(jī)會(huì)挑大梁嗎？

作者：龍逢 2019-01-07 20:30:48

提起NoSQL，大家一定會(huì)想到Google的Bigtable(2008年)和Amazon的Dynamo(2007年)，前者出于互聯(lián)網(wǎng)企業(yè)數(shù)據(jù)量爆發(fā)的擴(kuò)展性需求，實(shí)現(xiàn)了一個(gè)CP系統(tǒng);而后者則出于商業(yè)用戶的寫高可用需求，實(shí)現(xiàn)了一個(gè)AP系統(tǒng)。

2018年4月20日，蘋果宣布開源FoundationDB——一款支持多種數(shù)據(jù)模型、高性能、高可用、可擴(kuò)展，且具備ACID事務(wù)的分布式KV NoSQL系統(tǒng)。FoundationDB已在蘋果公司內(nèi)部的生產(chǎn)環(huán)境使用三年，主要用于iCloud上的云存儲(chǔ)服務(wù)。

蘋果于2015年收購開源的FoundationDB并將其閉源。此次再次開源，是因?yàn)樘O果預(yù)見到：FoundationDB有潛力成為下一代分布式數(shù)據(jù)庫系統(tǒng)的底層基礎(chǔ)設(shè)施。同時(shí)，也希望借助社區(qū)的力量，利用FoundationDB設(shè)計(jì)的分層機(jī)制，開發(fā)以其為底層核心且符合各種應(yīng)用定制需求的存儲(chǔ)系統(tǒng)。這也間接使得蘋果的底層基礎(chǔ)設(shè)施更安全、更可靠，而最終實(shí)現(xiàn)公司和社區(qū)雙贏的結(jié)果。

拋開蘋果開源FoundationDB背后的商業(yè)利益不談，F(xiàn)oundationDB在技術(shù)上有兩點(diǎn)值得關(guān)注：

NoSQL+ACID+SQL Layer=NewSQL

在獨(dú)立的KV存儲(chǔ)服務(wù)上實(shí)現(xiàn)事務(wù)ACID語義，再通過分層設(shè)計(jì)在應(yīng)用層支持文檔、圖、SQL等多種數(shù)據(jù)模型。

MVCC+OCC=SSI

基于多版本/樂觀并發(fā)控制技術(shù)實(shí)現(xiàn)可串行化的快照隔離級(jí)別。

一、NoSQL的沒落?

1、Bigtable & Dynamo

在CAP定理(2000年)的推波助瀾下，NoSQL運(yùn)動(dòng)發(fā)展的如火如荼(AP系統(tǒng)如Cassandra、Voldemort、Tokyo Cabinet、Riak，CP系統(tǒng)如HBase、Hypertable、MongoDB、Redis)，并總結(jié)出了自己的設(shè)計(jì)哲學(xué)：

no SQL
no ACID
no schema
high performance
high scalability
high availability
low latency
relaxed consistency

然而，隨著NoSQL系統(tǒng)在應(yīng)用中的廣泛使用，系統(tǒng)設(shè)計(jì)中拋棄的技術(shù)債務(wù)成了應(yīng)用開發(fā)人員的負(fù)擔(dān)，開發(fā)接口千奇百怪，數(shù)據(jù)不一致問題狀況百出，事務(wù)一致性無法保證，正如Eric Brewer所說：

The hidden cost of forfeiting consistency, which is the need to know the system's invariants. The subtle beauty of a consistent system is that the invariants tend to hold even when the designer does not know what they are.

尤其是在互聯(lián)網(wǎng)業(yè)內(nèi)具備神級(jí)存在的Google公開的Spanner(2012)，成為壓垮NoSQL的最后一根稻草，又一次改變了分布式數(shù)據(jù)庫系統(tǒng)發(fā)展的方向。

2、Google從NoSQL轉(zhuǎn)向NewSQL的歷程

Google內(nèi)部的存儲(chǔ)系統(tǒng)，在自身業(yè)務(wù)需求的推動(dòng)下，經(jīng)歷了幾代系統(tǒng)的演變，Bigtable、Percolator、Megastore、NoSQL Spanner、F1、SQL Spanner，本質(zhì)上是一個(gè)NoSQL到NoSQL+APP ACID到NoSQL+ACID到NoSQL with ACID到NoSQL with ACID+SQL到SQL的過程。

Percolator(2010，NoSQL+APP ACID)

該系統(tǒng)實(shí)現(xiàn)為一個(gè)基于Bigtable的業(yè)務(wù)系統(tǒng)，用于搜索索引的構(gòu)建，作者在論文中指出了Bigtable對應(yīng)用需求的限制：

Distributed storage systems like Bigtable can scale to the size of our repository but don't provide tools to help programmers maintain data invariants in the face of concurrent updates.

同時(shí)也描述了支持事務(wù)語義的好處：

...make it more tractable for the user to reason about the state of the system and to avoid the introduction of errors into a long-lived repository.

Percolator通過2PL技術(shù)實(shí)現(xiàn)了多行ACID事務(wù)：

...stores its locks in special in-memory columns in the same Bigtable that stores data and reads or modifies the locks in a Bigtable row transaction when accessing data in that row...

Megastore(2011，NoSQL+ACID)

該系統(tǒng)用于內(nèi)部交互式在線NoSQL系統(tǒng)，作者在論文中也指出了實(shí)現(xiàn)事務(wù)語義的好處：

Despite the operational advantages of eventually consistent systems,it is currently too difficult to give up the read-modify-write idiom in rapid application development.

Megastore通過OCC技術(shù)實(shí)現(xiàn)了單分區(qū)上的ACID事務(wù)，但論文中并沒有詳細(xì)描述實(shí)現(xiàn)細(xì)節(jié)。

Spanner(2012，NoSQL with ACID)

該系統(tǒng)是第一個(gè)不依賴Bigtable，從頭打造的分布式數(shù)據(jù)庫系統(tǒng)，作者在論文中也強(qiáng)調(diào)了支持事務(wù)語義的好處：

...it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

Spanner通過2PL技術(shù)實(shí)現(xiàn)了跨分區(qū)的多行ACID事務(wù)。

F1(2012，NoSQL with ACID + SQL)

該系統(tǒng)基于NoSQL Spanner實(shí)現(xiàn)為AdWords的存儲(chǔ)系統(tǒng)，作者在論文中(同上)從業(yè)務(wù)視角直接陳述了事務(wù)和SQL的缺失對業(yè)務(wù)開發(fā)造成的影響：

...the complexity of dealing with a non-ACID data store in every part of our business logic would be too great, and there was simply no way our business could function without SQL queries.

F1借助Spanner基于樂觀鎖實(shí)現(xiàn)了樂觀事務(wù)，并詳盡描述了優(yōu)缺點(diǎn)(無法避免幻讀)，這個(gè)和數(shù)據(jù)庫層面基于OCC技術(shù)實(shí)現(xiàn)的事務(wù)有本質(zhì)的區(qū)別.

Spanner(2017，SQL)

該系統(tǒng)是一個(gè)全功能的SQL系統(tǒng)，作者在論文中再次強(qiáng)調(diào)了支持事務(wù)和SQL的重要性：

...developers of many OLTP applications found it difficult to build these applications without a strong schema system, cross-row transactions, consistent replication and a powerful query language.

如果沒有強(qiáng)表達(dá)能力的查詢語言：

...developers had to write complex code to process and aggregate the data in their applications.

與此同時(shí)，作者對NoSQL with ACID + SQL的技術(shù)架構(gòu)也寄予了高度的肯定：

A scalable, manageable, transactional key-value store is perhaps the lowest common denominator for building enterprise-strength global storage systems. It has been demonstrated by our colleagues from the F1 team that a transactional NoSQL core can be used to build a scalable SQL DBMS.

并且，在存儲(chǔ)系統(tǒng)中松耦合還是緊耦合實(shí)現(xiàn)SQL還是一個(gè)需要認(rèn)真討論的問題：

both the loosely coupled (in case of F1) and tightly coupled SQL designs can be deployed successfully, and even simultaneously, on a transactional NoSQL core. A detailed exploration of the pros and cons of these designs is still outstanding. But it is perhaps fair to say that from the perspective of many engineers working on the Google infrastructure, the SQL vs NoSQL dichotomy may no longer be relevant.

二、NewSQL的繁榮?

根據(jù)論文中的定義，NewSQL的核心特性如下：

支持SQL接口。
支持ACID事務(wù)語義。
在OLTP場景下具備NoSQL的高性能、高可用、高擴(kuò)展性。

Spanner和F1論文發(fā)表至今，催生了一些優(yōu)秀的NewSQL開源項(xiàng)目：

2015年6月4日，前Google員工創(chuàng)辦CockroachDB;2015年融資600萬美元;2016年融資2000萬美元;2017年融資2700萬美元。
2015年中，前豌豆莢員工發(fā)布TiDB;2017年融資1500萬美元。
2015年5月24日，HP開源Trafodion，一款基于HBase，支持ACID事務(wù)、SI隔離級(jí)別的SQL數(shù)據(jù)庫;2018年1月10日，Apache宣布Trafodion成為頂級(jí)項(xiàng)目。
2017年11月2日，前Facebook員工創(chuàng)辦YugaByte DB;2017年融資800萬美元;2018年融資1600萬美元。

從這些項(xiàng)目的實(shí)現(xiàn)架構(gòu)來看，主要分為兩種：

原生實(shí)現(xiàn)：如CockroachDB、YugaByteDB
NoSQL+ACID+SQL：如TiDB、Trafodion

VoltDB在評(píng)價(jià)FoundationDB的博文中對NoSQL+ACID+SQL架構(gòu)下SQL實(shí)現(xiàn)的性能表示了質(zhì)疑，這種架構(gòu)的主要技術(shù)缺陷是計(jì)算無法下沉到存儲(chǔ)節(jié)點(diǎn)會(huì)導(dǎo)致大量的網(wǎng)絡(luò)傳輸開銷。

然而，2017年Google的Spanner論文中已經(jīng)將類似這種架構(gòu)的F1與SQL Spanner相提并論，兩種架構(gòu)的優(yōu)劣性仍然有待觀察和研究，但它們的共同點(diǎn)是都依賴于一個(gè)支持事務(wù)的NoSQL基礎(chǔ)系統(tǒng)。從這個(gè)視角來看，以下這些支持事務(wù)的NoSQL系統(tǒng)也具備演變成NewSQL的可能性：

2009年，F(xiàn)oundationDB開源，基于MVCC NoSQL，支持SSI隔離級(jí)別;2015年閉源;2018年4月開源。
2016年3月28日，Yahoo開源Omid，基于HBase，支持SI隔離級(jí)別;后續(xù)閉源，商業(yè)化為LeanXscale，同時(shí)支持SQL。
2016年3月7日，Tephra開源，基于HBase，支持SI隔離級(jí)別;由Cask公司商業(yè)化運(yùn)作。
2018年2月15日，MongoDB宣布將在今年夏季發(fā)布的4.0版本中支持多文檔ACID事務(wù)，基于WiredTiger存儲(chǔ)引擎改造。

三、事務(wù)的心臟——并發(fā)控制

從上述章節(jié)NewSQL的發(fā)展趨勢來看，ACID事務(wù)的回歸是必然的，而且在分布式場景下，均致力于實(shí)現(xiàn)可擴(kuò)展、高性能的串行化隔離級(jí)別，這在傳統(tǒng)數(shù)據(jù)庫的實(shí)現(xiàn)中是難以達(dá)到的。事務(wù)管理的核心技術(shù)是并發(fā)控制，原子性、一致性、隔離性都與它相關(guān)，本章簡單科普一下事務(wù)并發(fā)控制技術(shù)。

事務(wù)的并發(fā)控制是為了實(shí)現(xiàn)事務(wù)的調(diào)度。

一個(gè)正確、高效的事務(wù)調(diào)度應(yīng)滿足如下屬性：

可串行化：多個(gè)并發(fā)事務(wù)的調(diào)度S與一個(gè)串行化的調(diào)度產(chǎn)生相同的結(jié)果，則稱這個(gè)調(diào)度S是可串行化的;在數(shù)據(jù)庫實(shí)現(xiàn)中，一般使用沖突可串行化技術(shù)。
可恢復(fù)性：已經(jīng)提交的事務(wù)沒有讀過被終止的事務(wù)寫過的數(shù)據(jù)，防止臟讀異常。
避免級(jí)聯(lián)終止：避免由于事務(wù)T1的終止而導(dǎo)致事務(wù)T2的終止。
嚴(yán)格性：先發(fā)生寫操作的事務(wù)的提交或終止應(yīng)先于其它沖突事務(wù)的提交或終止。

并發(fā)控制從實(shí)現(xiàn)思路維度可以分為如下三類：

樂觀：重在事后檢測，在事務(wù)提交時(shí)檢查是否滿足隔離級(jí)別。滿足，則提交;否則回滾并自動(dòng)重新執(zhí)行。
悲觀：重在事前預(yù)防，在事務(wù)執(zhí)行時(shí)檢查是否滿足隔離級(jí)別。滿足，則繼續(xù)執(zhí)行;否則等待或回滾。
半樂觀：混合使用樂觀和悲觀技術(shù)實(shí)現(xiàn)事務(wù)并發(fā)控制。

并發(fā)控制從實(shí)現(xiàn)方式維度可以分為如下幾種：

基于鎖的并發(fā)控制

2PL(two-phase locking)：事務(wù)在執(zhí)行期間被明確的劃分為growing和shrinking階段，growing階段只能持有鎖不能釋放鎖;shrinking階段只能釋放鎖不能持有鎖，僅滿足可恢復(fù)性;

S2PL(strict two-phase locking)：在滿足2PL的前提下，要求持有的排它鎖必須在事務(wù)提交后才釋放，避免了級(jí)聯(lián)回滾;

SS2PL(strong strict two-phase locking)：在滿足2PL的前提下，要求事務(wù)提交之前不得釋放任何鎖，保證了嚴(yán)格性。

基于時(shí)間戳的并發(fā)控制

在事務(wù)開始時(shí)生成一個(gè)單調(diào)遞增的時(shí)間戳，數(shù)據(jù)項(xiàng)上維護(hù)最近讀時(shí)間戳和最近寫時(shí)間戳。每次讀寫操作，系統(tǒng)都會(huì)將事務(wù)時(shí)間戳與數(shù)據(jù)項(xiàng)上的時(shí)間戳進(jìn)行檢查，對于任意讀寫操作，如果事務(wù)時(shí)間戳小于數(shù)據(jù)項(xiàng)的最近寫時(shí)間戳，則將事務(wù)回滾;對于寫操作，如果事務(wù)時(shí)間戳小于數(shù)據(jù)項(xiàng)的最近讀時(shí)間戳，則將事務(wù)回滾;如果都滿足，則繼續(xù)訪問下一個(gè)數(shù)據(jù)項(xiàng)。

基于OCC的并發(fā)控制

事務(wù)的生命周期被劃分為三個(gè)階段，將串行化檢測推遲到提交階段：

讀階段：事務(wù)寫操作僅是對事務(wù)私有空間中數(shù)據(jù)的更新，并不對數(shù)據(jù)庫中的數(shù)據(jù)項(xiàng)進(jìn)行真實(shí)的更新，保證讀階段沒有任何事務(wù)沖突及鎖開銷;

驗(yàn)證階段：檢測事務(wù)是否滿足串行化隔離級(jí)別;

寫階段：將事務(wù)私有空間中的更新數(shù)據(jù)寫入數(shù)據(jù)庫。

基于多版本的并發(fā)控制

每一次寫操作會(huì)生成一個(gè)新的數(shù)據(jù)項(xiàng)版本，數(shù)據(jù)項(xiàng)的版本號(hào)可以使用事務(wù)的時(shí)間戳或事務(wù)號(hào);系統(tǒng)維護(hù)多個(gè)數(shù)據(jù)版本，讀操作根據(jù)所在事務(wù)的時(shí)間戳或事務(wù)號(hào)能夠讀到指定的版本，做到讀-寫或?qū)?讀操作不阻塞，寫-寫操作的沖突依賴2PL實(shí)現(xiàn)。

上述只是傳統(tǒng)數(shù)據(jù)庫時(shí)代總結(jié)的并發(fā)控制技術(shù)，在分布式場景下一般會(huì)采用MVCC與其它并發(fā)控制技術(shù)的組合，目的是提高并發(fā)度，減小同步開銷。

四、悲觀還是樂觀

在了解了數(shù)據(jù)庫的基本并發(fā)控制技術(shù)后，本章針對現(xiàn)今感興趣的生產(chǎn)級(jí)NewSQL分布式數(shù)據(jù)庫使用的并發(fā)控制技術(shù)進(jìn)行了簡單的總結(jié)：

由上表可以看出，F(xiàn)oundationDB是第一個(gè)使用OCC技術(shù)實(shí)現(xiàn)ACID事務(wù)的生產(chǎn)級(jí)數(shù)據(jù)庫系統(tǒng)(嚴(yán)格地說，Google的MegaStore也使用了OCC并用于Google APP Engine等業(yè)務(wù)，但它的ACID事務(wù)實(shí)現(xiàn)僅作用于單個(gè)分區(qū))。

當(dāng)然，F(xiàn)oundationDB的OCC實(shí)現(xiàn)也有一些限制，比如官方文檔對KV和事務(wù)的大小及時(shí)長做出了如下限制：

key不超過10K;value不超過100K;事務(wù)不超過10M(包括所有讀、寫涉及的KV);
僅支持運(yùn)行時(shí)間不超過5s的讀寫事務(wù)。

這些限制在OLTP場景下是完全可以接受的，若要在其Layer機(jī)制上實(shí)現(xiàn)OLAP場景，需要做適配性改造。

不管怎樣，F(xiàn)oundationDB通過OCC技術(shù)實(shí)現(xiàn)了NoSQL+ACID，并經(jīng)過了蘋果企業(yè)級(jí)生產(chǎn)環(huán)境的檢驗(yàn)，NewSQL的設(shè)計(jì)者到底是該使用悲觀還是樂觀并發(fā)控制技術(shù)，現(xiàn)在看來是一個(gè)需要認(rèn)真考慮的問題了。

以上就是對當(dāng)前NewSQL的發(fā)展趨勢及使用到的相關(guān)并發(fā)控制技術(shù)的一些思考。