NewSQL概念幾乎是緊跟著NoSQL之后變得火熱的。Google Bigtable與AWS Dynamo奠定了NoSQL技術(shù)的根基，而Google Spanner&F1則***了NewSQL技術(shù)的發(fā)展。本文首先探討NoSQL與NewSQL的概念與范疇，隨后結(jié)合一些業(yè)界觀點(diǎn)以及兩者之間的優(yōu)缺點(diǎn)對(duì)比，來論述各自的適用場(chǎng)景以及未來的演變趨勢(shì)。

NoSQL

眾所周知，NoSQL已是一個(gè)很廣泛的概念?，F(xiàn)在被大家所廣泛認(rèn)知的NoSQL一詞，源自2009年在San Francisco舉辦的一次Meetup，該Meetup的描述信息如此闡述： 

 
 This meetup is about “open source, distributed, non relational databases”.
 Have you run into limitations with traditional relational databases? Don’t mind trading a query language for scalability? Or perhaps you just like shiny new things to try out? Either way this meetup is for you.
  

傳統(tǒng)的RDBMS在Scalability能力上的受限，是促使NoSQL技術(shù)出現(xiàn)的一個(gè)關(guān)鍵因素。在這次Meetup的主題中，涉及到了Cassandra、HBase、MongoDB、CouchDB、HyperTable等開源技術(shù)，而該Meetup描述信息中所提及的“open source, distributed, non relational databases”為NoSQL技術(shù)給出了精煉的描述。彼時(shí)，SQL幾乎是RDBMS的代名詞，自然而言的，Non-SQL也成了Non-Relational的代名詞。

隨著近些年的快速發(fā)展，SQL已經(jīng)逐步被應(yīng)用在了更廣泛的領(lǐng)域，因此，SQL已不再是RDBMS的專屬特征，NoSQL技術(shù)體系中也引入了SQL能力，因此而演變出來的Not-Only-SQL的概念，雖有自圓其說之嫌，但的確給出了更合理的解讀。無論如何，“open source, distributed, non relational databases“關(guān)于大多數(shù)NoSQL技術(shù)邊界的定義，也依然是合理的，只是，“open source”是一個(gè)可選特征，而“distributed”以及“non relational”卻是典型NoSQL技術(shù)的基本特征。大多數(shù)NoSQL技術(shù)，弱化了對(duì)ACID語義以及復(fù)雜關(guān)聯(lián)查詢的支持，采用了更加簡(jiǎn)潔或更加專業(yè)的數(shù)據(jù)模型，優(yōu)化了讀寫路徑，從而能夠換取更高的讀寫性能。

NewSQL

NewSQL可以說是傳統(tǒng)的RDBMS與NoSQL技術(shù)結(jié)合之下的產(chǎn)物，如下是Wiki中為NewSQL給出的定義： 

  NewSQL is a class of modern relational database management systems that seek to provide 
 the same scalable performance of NoSQL systems for online transaction processing (OLTP) 
 read-write workloads while still maintaining the ACID guarantees of a traditional database system.

因此，可以將典型NewSQL技術(shù)理解成分布式關(guān)系型數(shù)據(jù)庫(kù)，能夠支持分布式事務(wù)是一個(gè)基本前提。NoSQL與NewSQL在技術(shù)棧上有很多重疊，但在是否支持關(guān)系型模型及對(duì)復(fù)雜事務(wù)的支持力度上是存在明顯區(qū)別的。某些地方也將NewSQL劃在Not-Only-SQL的范疇之內(nèi)，即NewSQL技術(shù)也被納入到NoSQL概念體系中，該說法雖也合理，但使得NoSQL一詞過于泛化。

業(yè)界觀點(diǎn)

近期，Timescale DB的聯(lián)合創(chuàng)始人Ajay Kulkarni曾經(jīng)發(fā)表過如下一篇文章：

 “Why SQL is beating NoSQL, and what this means for the future of data” 

文章標(biāo)題話題感十足，主要觀點(diǎn)總結(jié)如下：

• 很多新興技術(shù)都已經(jīng)在擁抱SQL，如AWS Aurora, Google Spanner, Kafka也已經(jīng)支持了SQL接口等等。
• 大多數(shù)NoSQL技術(shù)都定義了獨(dú)立的且不完善的查詢語言接口(DSL)，盡管有些NoSQL技術(shù)提供了SQL-Like接口，但與標(biāo)準(zhǔn)SQL接口兼容性極差。
• NewSQL的興起，而且開始積極擁抱標(biāo)準(zhǔn)SQL接口。Spanner是典型的例子，最初版本的Spanner的SQL語法的支持度是非常受限的，而最近幾年的時(shí)間里一直在不斷完善SQL語法的支持。
• 在當(dāng)前時(shí)代，數(shù)據(jù)的價(jià)值越來越大，SQL依然是不同數(shù)據(jù)源之間的標(biāo)準(zhǔn)接口。而關(guān)于SQL語法的支持度，是未來數(shù)據(jù)分析工作的***瓶頸點(diǎn)。

關(guān)于這篇文章的這幾個(gè)主要觀點(diǎn)，筆者是完全認(rèn)可的，但完全不認(rèn)可標(biāo)題中所給出的誤導(dǎo)性內(nèi)容，SQL的回歸并不意味著NoSQL技術(shù)將會(huì)被完全取代，正如下面一篇文章中關(guān)于Ajay Kulkarni觀點(diǎn)的評(píng)論：

“SQL is not beating NoSQL. NoSQL is evolving” 

 
 The analysis was mostly agreeable, except for one major flaw. It is not SQL which is making a comeback, its NoSQL which is morphing into providing a familiar interface.

SQL的回歸，恰恰是NoSQL技術(shù)在不斷演進(jìn)的結(jié)果。

技術(shù)分類法

在探討一個(gè)分布式存儲(chǔ)技術(shù)時(shí)，簡(jiǎn)單的將其歸類為NoSQL或者NewSQL是不合理的，像Bigtable/HBase/Dynamo是典型NoSQL技術(shù)，而Spanner/CockroachDB以及國(guó)內(nèi)的TiDB，可以將其歸類為典型NewSQL技術(shù)，但像Kudu，它本身的存儲(chǔ)引擎層是典型NoSQL技術(shù)，而在此基礎(chǔ)上提供了完善的SQL能力以及復(fù)雜的事務(wù)支持，因此，它兼顧了NoSQL與NewSQL的很多特征，更像是集兩者于一身的技術(shù)。

因此，非NoSQL即NewSQL的簡(jiǎn)單二分法是不合理的，很多技術(shù)都在將兩者進(jìn)行不斷的融合，至于這個(gè)合理的平衡點(diǎn)在哪里，要取決于這個(gè)分布式存儲(chǔ)技術(shù)要解決的核心問題是什么。

當(dāng)我們談?wù)揘oSQL，更多的是在談?wù)撘环N分布式、非關(guān)系型數(shù)據(jù)存儲(chǔ)技術(shù)，而談起NewSQL，更多可能是在討論一種分布式關(guān)系型數(shù)據(jù)庫(kù)技術(shù)。當(dāng)用NoSQL或者NewSQL來為一個(gè)技術(shù)進(jìn)行歸類時(shí)，更多考慮的可能是該技術(shù)更像什么，例如，如果提供了標(biāo)準(zhǔn)SQL接口以及復(fù)雜事務(wù)能力，優(yōu)先使用NewSQL一詞來描述是更加貼切的，但該技術(shù)幕后的存儲(chǔ)引擎，也許是基于NoSQL技術(shù)實(shí)現(xiàn)的。

***的總結(jié)

在闡述了NoSQL與NewSQL的概念以及兩者的范疇之后，再回到本文標(biāo)題中所提出來的***，該***似乎成了一個(gè)偽***，因?yàn)閮烧咭捕荚诼葸M(jìn)/融合。所以，對(duì)該***存在疑惑的人，更多是針對(duì)如下***：

分布式關(guān)系型數(shù)據(jù)庫(kù)技術(shù)是否會(huì)取代分布式非關(guān)系型數(shù)據(jù)存儲(chǔ)技術(shù)？

分布式關(guān)系型數(shù)據(jù)庫(kù)技術(shù)在分布式事務(wù)以及關(guān)系型模型上的強(qiáng)化，導(dǎo)致在數(shù)據(jù)吞吐量／并發(fā)能力上的弱化。借助NuoDB官方提供的一個(gè)NuoDB與Spanner/Cockroach的benchmark對(duì)比結(jié)果(“Benchmarking Google Cloud Spanner, CockroachDB, and NuoDB”)來進(jìn)一步說明該觀點(diǎn)：

NewSQL Benchmark 

上圖中的Workload定義： 

 A – Heavy update (50% read, 50% update)
 B – Mostly read (95% read, 5% update)
 C – Read-only (100% read)
 D – Read the latest inserted (90% read, 10% insert)
 E – Scan the latest inserted (90% read, 10% insert)
 F – Read-modify-write (50% read, 50% update)
 

可以看出，無論哪種Workload下，Spaner與CockroachDB的Throughput都是很低的。盡管NuoDB也可以歸類到 NewSQL的范疇中，但它也大量借鑒了NoSQL技術(shù)，將事務(wù)機(jī)制與持久化機(jī)制分層處理以及更好的利用緩存技術(shù)是性能取得質(zhì)的提升的關(guān)鍵。上圖中部分Workload中，NuoDB的Throughput幾乎達(dá)到了主流 NoSQL技術(shù)的Throughtput水準(zhǔn)，但還是可以看出，當(dāng)讀寫比例相當(dāng)或者寫多讀少的場(chǎng)景下，NuoDB的Throughput較之主流的NoSQL技術(shù)存在明顯的差距。 

因此，分布式關(guān)系型數(shù)據(jù)庫(kù)技術(shù)與分布式非關(guān)系型數(shù)據(jù)存儲(chǔ)技術(shù)依然是針對(duì)不同的應(yīng)用場(chǎng)景的，前者主要還是針對(duì)傳統(tǒng)RDBMS的部分應(yīng)用場(chǎng)景，而分布式非關(guān)系型數(shù)據(jù)存儲(chǔ)技術(shù)，則更適合高吞吐、高并發(fā)的新興應(yīng)用場(chǎng)景。隨著物聯(lián)網(wǎng)、車聯(lián)網(wǎng)的不斷普及，分布式非關(guān)系型數(shù)據(jù)存儲(chǔ)(NoSQL)技術(shù)也會(huì)帶來更大的價(jià)值。兩者還會(huì)走向進(jìn)一步的融合，也會(huì)看到更徹底的分離。