NewSQL系統綜述——NewSQL到底New在哪裡？

原作者：Andrew Pavlo（卡內基梅隆大學）Matthew Aslett（451研究所）

摘要

近年來出現了一種稱為NewSQL的新型資料庫管理系統（DBMS），它們號稱有能力擴展現代在線交易處理（on-line transaction processing, OLTP）系統的工作負載，這對於以前的系統來說是無法做到的。NewSQL這個詞是本文的作者之一在2011年的一篇討論對傳統巨頭（Oracle，IBM，Microsoft）地位發起挑戰的新型資料庫系統的商業分析報告中提出來的。另一作者則曾經擔任第一代NewSQL DBMS的系統的開發者。從2011年後，一些商業公司和研究項目開始使用NewSQL來描述他們的系統。

鑒於傳統的DBMS已經發展了近40年，有必要仔細推敲一下NewSQL的優勢是真如他們所說，還是僅僅是一種商業宣傳行為。如果真的可以獲得更好的性能，那麼下一個問題自然就是它們是真的有技術突破，還是僅僅因為硬體方面的發展使得原來的問題已不再是瓶頸？

為了探討這些問題，我們先討論了資料庫的發展歷史，以此理解NewSQL出現的背景和原因。然後從一些細節方面深入討論了NewSQL的概念，特點，分類，以及在各個分類下面的NewSQL系統。

1. 資料庫管理系統（DBMSS）的簡要發展歷史

第一代DBMS出現在1960年代中期。IBM開發的IMS用於記錄土星V和阿波羅空間探索項目中的供應鏈和倉儲信息。它第一個提出將應用代碼和數據操作進行分隔的思想，使開發者只需要關注數據的產生和訪問，無需考慮操作和訪問這些數據的複雜性。1970年代，IBM和加州大學借鑒IMS的思想分別構建了System R和INGRES，成為第一代關係型的DBMS。其中INGRES很快被其他的大學用於信息系統，接著在1970年代後期進行了商業化。在同一時期，Oracle發布了第一版與System R的設計非常類似的DBMS。其他公司在1980年代早期也紛紛通過推出自己的DBMS系統獲得了成功，包括Sybase和Informix。儘管IBM從未將System R開放給公眾，但在它的基礎代碼上於1983年推出了一個新商用的關係型資料庫系統——DB2。

為了克服關係模型和面向對象編程語言之間的失配問題，1980年代後期和1990年代早期左右出現了一種新型的DBMS。因為不具備像SQL語言那樣的統一的標準介面，所以這種面向對象的DBMS並沒有被市場大規模接受。不過，當主要的廠商在十年後添加了對象和XML支持，二十年後添加了面相文檔的NoSQL系統之後，這類系統的許多設計思想最終被併入了關係型DBMS中。

在1990年代，另一個值得關注的事件是當今兩大主要開源DBMS的誕生。1995年，MySQL起源於瑞典，它建立在ISAM的mSQL系統之上。PostreSQL則是在1994年由兩個伯克利大學的研究生在QUEL的Postgres的代碼上添加了SQL支持而誕生。

到了2000年代，由於互聯網應用的興起，對系統資源的需求受到了前所未有的挑戰。互聯網應用需要支持大規模的並發用戶，並且要保持永遠在線。但是這些新應用的資料庫卻因為無法支持如此大規模的數據和訪問量而成為了整個系統的瓶頸。最簡單直接的辦法是不斷升級DBMS的硬體系統，使用更多的CPU，內存和硬碟。但是這種方法只是提高了性能，並且呈現明顯的收益遞減效應。更糟糕的是，將資料庫從一個機器遷移到另一個機器是一個比較複雜的過程，通常需要較長的停機時間。而這對於Web應用來說是不可接受的。為了解決這個問題，一些公司推出了資料庫中間件，對原有的單節點資料庫進行數據分片，並存放到由廉價機器組成的分散式的集群里。對於應用程序來說，資料庫中間件是一個邏輯上的單節點資料庫，但實際上它的存儲橫跨了多台物理機器。當應用向資料庫發起操作時，資料庫中間件會自動將操作指令發送到集群中的一個或多個節點來執行。節點執行之後將結果發送回中間件，再由中間件反饋給應用。比較著名的資料庫中間件包括eBay的Oracle的集群和Google的MySQL集群。這種方法後來也被Facebook採用，建立了自己的MySQL集群並應用至今。

數據分片中間件在簡單操作（如讀取或更新單條記錄）時能工作得很好，但對於在一個事務中更新多條記錄或者JOIN表之類的複雜操作時就無能為力。例如eBay中間件要求開發者在其應用的代碼里實現所有的JOIN操作。

於是一些公司不再使用資料庫中間件，轉而開發自己的分散式DBMS。原因有三個方面：1）傳統的DBMS將重點放在一致性和正確性上，犧牲了可用性和性能。但是這種設計上的妥協不能滿足Web應用大並發量和時時在線的需求。2）很多人認為使用一個完整功能的DBMS（如MySQL）的開銷過大，3）同樣地，使用SQL來執行簡單的查詢也被看做是一種過渡使用。

這些問題引發了2000年代NoSQL運動的誕生。NoSQL系統的關鍵是它們放棄了傳統的DBMS強事務保證和關係模型，通過所謂最終一致性和非關係數據模型（例如鍵值對，圖形，文檔）來提高Web應用所注重的高可用性和可擴展性。其中最著名的系統是Google BigTable和Amazon的Dynamo。這兩個系統最初並不對外開放（雖然現在都已經變成了雲服務），所以其他的用戶也創建了自己的開源克隆系統。包括Facebook的Cassandra（基於BigTable和Dynamo），PowerSet的Hbase（基於BigTable）。其他初創公司並沒有使用Google或者Amazon系統的副本，但仍遵循了NoSQL的哲學，最著名的是MongoDB。

2000年代後期，出現了更具擴展性並且更廉價的分散式DBMS。使用NoSQL的好處（或者說人們想像中的好處）是開發者可以將精力集中在應用，業務或者組織方面，而不用擔心DBMS的擴展性。但是，仍有許多應用不能使用NoSQL。因為它們無法放棄強事務和一致性的需求。通常這些都是需要處理複雜關聯性數據的企業級應用（例如財務、訂單系統，人力資源系統等）。包括Google在內的一些公司發現採用NoSQL DBMS會迫使程序員在應用開發過程中花費過多的精力來處理一致性數據以提高事務的執行效率。於是唯一的解決之道是：要麼購買更強大的單節點機器來垂直擴展DBMS，要麼開發自己的數據分片中間件來支持事務。無論哪種方法都非常昂貴，並不是所有人都能接受。在這種環境下NewSQL系統出現了。

1. NewSQL的興起

本文關於NewSQL的定義是：這是一類現代關係型的DBMS，旨在為NoSQL的OLTP讀寫負載提供相同的可擴展性能，同時仍然提供事務的ACID保證。換句話說，這些系統希望達到NoSQL DBMS相同的可擴展性，又能保留從1970年代開始的關係模型和事務支持，使得應用可以執行大規模的並發事務，並使用SQL而不是特定的API來修改資料庫的狀態。如果應用使用了NewSQL DBMS，開發者不再需要像使用NoSQL一樣在應用邏輯里處理最終一致性的問題。我們下面的討論中，NewSQL的這個解釋涵蓋了許多學術系統和商業系統。

在2000年代中期出現了數據倉庫DBMS，有人認為它們達到了這個標準。例如Vertica，Greenplum，Aster Data）。這些DBMS服務的對象是OLAP系統，並不能認為是NewSQL系統。OLAP DBMS重點是執行複雜的只讀查詢（例如聚合查詢，多維度JOIN等），這些查詢需要大量的計算，較長的執行時間，使用超大的數據集，並且每一個查詢都是獨一無二的。而NewSQL DBMS服務的系統則需要執行讀寫事務，並具備以下幾個特徵：1）短生存時間，即沒有用戶停頓；2）使用索引查詢小數據集，不進行全表掃描或者大規模分散式JOIN；3）可重複執行，即不同的輸入執行相同的查詢。其他人提出了一個更窄的定義，其中NewSQL系統的實現必須使用：1）無鎖並發控制方案；2）無共享分散式架構。第三節里列舉所有的NewSQL DBMS都具備這個特徵，因此我們也認同這個定義。

1. NewSQL的分類

基於上述的定義，我們可以來看看現在有哪些NewSQL DBMS。為了簡化分析，我們將研究對象按照實現方式進行分組。我們分出了三個類：1）使用全新的架構；2）重新實現由Google和其他人在2000年代開發的數據分片基礎架構，並在此基礎上開發的資料庫中間件；3）來自雲服務提供商的database-as-a-service（DBaaS），同樣基於全新的架構。

本文的兩位作者都曾在NewSQL系統分類中考慮了替換現有單節點DBMS存儲引擎的方案。最常見的例子是對MySQL默認InnoDB存儲引擎的替換（例如，TokuDB，ScaleDB，Akiban，deepSQL）。使用新存儲引擎的好處是用戶可以獲得更好的性能而無需修改應用，並且仍能夠繼續使用DBMS的周邊工具和API。其中最有意思的是ScaleDB，它提供了透明的數據分片方案而不使用中間件，通過在不同的存儲引擎之間重新分配執行。不過現在這個公司已經轉向了其他問題領域。

除了MySQL，還有其他類似的擴展。Microsoft的內存Hekaton OLTP引擎用於SQL Server時幾乎可以與傳統的磁碟駐留表無縫集成。其他人使用Postgres的外部數據包裝器和API鉤子來實現相同類型的集成，但目標卻是OLAP工作負載（例如Vitesse，CitusDB）。

現在我們認為這種單節點DBMS的存儲引擎和擴展並不代表NewSQL系統，因此在我們的分類中將會省略掉它們。MySQL的InnoDB在可靠性和性能方面獲得了長足的進步，因此為OLTP應用切換到其他的存儲引擎變得沒有十分的必要。我們承認從面向行的InnoDB引擎切換到列存儲的引擎對於OLAP負載來說是有意義的（例如Infobright，InfiniDB），但一般來說，為OLTP負載替換MysQL的存儲引擎業務是失敗的資料庫項目的墓地。

3.1 新型架構

這個分類包括了NewSQL系統最有趣的部分，因為它們是全新架構的，從頭設計的DBMS。也就是說，跟擴展現有系統不同（如Microsoft的Hekaton for SQL Server），它們從一個全新的起點開始設計，擺脫了原有系統的設計束縛。這個分類中所有的DBMS都採用了分散式架構，對無共享資源進行操作，並且包含支持多節點並發控制，基於複製的容錯，流控制和分散式查詢處理等組件。使用一個全新的為分散式執行而設計的DBMS的好處是，系統所有的部分都可以針對多節點環境進行優化，包括查詢優化，節點間通信協議優化等。例如，大部分的NewSQL DBMS都可以在節點之間直接發送內部查詢數據，而不用像一些中間件系統一樣需要通過中心節點進行轉發。

在這個分類中的所有DBMS（Google的Spanner除外）都管理自己的主存儲，有的是在內存中，有的是在磁碟中。也就是說，DBMS負責使用定製開發的引擎在其資源上分布其資料庫，而不是依賴現成的分散式文件系統（例如HDFS）或存儲結構（例如Apache Ignite）。這是很重要的一個特徵，因為這使得DBMS能夠「向數據發送查詢」，而不是「將數據帶給查詢」，這意味著更少的網路流量。因為跟傳輸數據（不僅僅是元組，還包括索引，物化視圖等）相比，傳輸查詢所需的網路流量要少得多。

對主存儲的管理還使DBMS可以使用比HDFS中使用的基於塊的複製方案更為複雜靈活的複製方案，因此這種DBMS比那些建立在其他已有技術分層上的系統擁有更好的性能。在現有技術分層上建立的系統有所謂的「SQL on Hadoop」系統（如Trafodion），以及在Hbase上提供事務支持的Splice Machine等等，但我們認為這類系統並不是NewSQL。

但是新架構DBMS的使用情況是呈下降態勢的。最重要的原因是許多用戶擔心這項技術太新，沒有大規模的安裝基礎和實際的生產環境的驗證。另外就是社群和有經驗的用戶數量比流行的DBMS要小許多，許多用戶有可能無法使用現有的管理和報表生成工具。一些DBMS，例如Clustrix和MemSQL，通過兼容MySQL的網路協議避免了這類問題。

本類案例：Clustrix, Cockroach, Google Spanner, H-Store, HyPer, MemSQL, NuoDB, SAP HANA, VoltDB.

3.2 透明的數據分片中間件

現在有一些產品跟2000年代的eBay，Google和Facebook一樣提供數據分片的中間件。用戶可以藉助它們將資料庫分成多個部分，並存儲到由多個單節點機器組成的集群中。數據分片比1990年代出現的資料庫聯合技術更難，因為每一個節點都要運行相同的DBMS，只維護整個資料庫的一部分數據，且不能被不同的應用獨立訪問或修改。

集中化的中間件組件負責分配查詢，協調事務，同時也管理數據的位置，複製和跨節點的數據分區。集群典型的架構是在每個節點上都安裝一個中介層來與中間件通信。這個組件負責代替中間件在DBMS實例上執行查詢並返回結果，最終由中間件整合。對應用來說中間件就是一個邏輯上的資料庫，應用和底層的DBMS都不需要修改。

使用數據分片中間件的核心優勢在於，它們通常能夠非常簡單地替換已經使用了單節點DBMS的應用的資料庫，並且開發者無需對應用做任何修改。最常見的中間件目標系統是MySQL，這意味著為了保持與MySQL的一致性，中間件必須支持MySQL的網路協議。Oracle提供了MySQL Proxy和Fabric工具來做這些工作，但是其他公司也開發了自己的協議處理器來避免GPL授權問題。

儘管中間件使用戶擴展資料庫變得更容易，但它們仍需要在每個節點上安裝傳統的DBMS（例如MySQL，Post供熱SQL，Oracle）。這些DBMS採用的是1970年代提出的面向磁碟存儲架構，不能像新架構的NewSQL系統那樣使用面向內存的存儲管理和並發控制方案。以前的研究表明，面向磁碟的架構阻礙了傳統的DBMS通過提升CPU核數和內存容量進行向上擴展。中間件方法會導致在分片節點上執行複雜查詢操作的時候出現冗餘的查詢計劃和優化操作（即在中間件執行一次，在單節點上再執行一次），不過所有節點可以對每個查詢使用局部的優化方法和策略。

本類案例：AgilData Scalable Cluster, MariaDB MaxScale, ScaleArc, ScaleBase.

3.3 Database-as-a-Service

最後一個分類是雲服務提供商的NewSQL方案，database-as-a-service，也稱為DBaaS。通過這些雲服務，用戶不需要在自己的硬體設備上或者雲端虛擬機上安裝和維護DBMS。DBaaS的提供商負責維護所有的資料庫物理機及其配置，包括系統優化（例如緩衝池調整），複製，以及備份。交付給用戶的只是一個連接DBMS的URL，以及一個用於監控的儀錶盤頁面或者一組用於系統控制的API。

DBaaS的客戶根據他們預計使用的系統資源來付費。因為不同的資料庫查詢在計算資源的利用上差距非常大，DBaaS提供商通常不會採用塊存儲服務（例如Amazon的S3，Google的Cloud Storage）常用的依據調用次數計費，而更傾向於採用預付費的訂閱方式。即客戶指定所需的最大的存儲空間，CPU數量，內存空間等，服務提供商則會在服務期間保證這些資源的可用性。

因為從規模經濟角度來看，DBaaS的主要提供商也是雲計算服務的主要提供商，但幾乎所有的DBaaS僅僅提供一個傳統的單節點DBMS實例（例如MySQL）。Google Cloud SQL， Microsoft的Azure SQL, Rackspace Cloud Database, 以及Scaleforce Heroku都是這麼做的。因為它們同樣使用了從1970年代就沿用至今的面向磁碟的存儲架構，我們不把這種單實例的系統算作NewSQL。一些提供商（例如Microsoft）對DBMS進行了一些改造，提供了對多租戶的支持。

我們僅僅認為那些基於新型架構的DBaaS是NewSQL。最著名的例子是Amazon的Aurora for MySQL RDS，它與InnoDB的最大區別在於它使用日誌結構化存儲管理器來提高I / O並行性。

另外一些公司的產品並沒有自己的數據中心，他們的DBaaS軟體建立在公有雲平台之上，例如ClearDB能夠讓客戶將其部署在任何的主流雲平台上。這麼做的好處是用戶可以把資料庫建立在同一個地區不同的雲平台上，以避免由於雲服務中斷而導致的停機。

Aurora和ClearDB是2016年這個分類下僅存的兩個產品。我們注意到其他公司在這個領域的產品都失敗了（例如GenieDB，Xeround），原有的客戶不得不在他們關閉雲服務前遷出他們的DBaaS並尋找下一個提供商。我們將他們的失敗總結為超出市場需求，價格上與主要競爭對手沒有拉開差距。

分類案例：Amazon Aurora，ClearDB

1. NewSQL的現狀

接下來我們將討論NewSQL DBMS的特點，以理解這些系統的創新之處。文末所附的列表是我們分析工作的總結。

4.1 主內存存儲

自從1970年代以來，所有主流DMBS都採用了面向磁碟的存儲架構設計。在這些系統中，資料庫的主要的存儲位置被假定為在一個可進行塊定址的永久性存儲設備上，例如SSD，HDD。因為在這些設備上進行讀寫操作非常慢，DBMS使用內存來緩存從磁碟讀取的塊，並緩衝來自事務的更新。這是非常必要的，因為當時的內存非常昂貴，而且容量與磁碟相比非常有限。而現在內存的容量和價格都到達了可以將大部分的資料庫都容納進去的程度。使用內存作為主存儲的好處是它支持針對性的優化，因為DBMS不必假設事務需要在任何時間隨機地訪問不在內存中的數據，許多需要處理諸如緩衝池或者重量級並發控制的組件不再是必須的，所以系統將獲得更好的性能。

有一些NewSQL DBMS是基於主內存架構的，包括研究性的系統（例如H-Store, Hyper）和商業系統（例如MemSQL，SAP HANA，VoltDB）。這些面向主內存的系統的性能比面向磁碟的處理OLTP的DBMS要高很多。

將資料庫全部放在主內存的思想並不是最新的。1980年代初，威斯康辛-麥迪遜大學的開創性研究為內存資料庫DBMS的許多方面奠定了基礎，包括索引，查詢處理和恢復演算法等。同時期第一個分散式主內存DBMS——PRISMA/DB被開發出來。第一個商用的主內存DBMS——Altibase則出現在1990年代。Oracle的TimesTen和AT&T的DataBlitz是這種方法的早期實現。

主內存NewSQL系統一個比較新的點是它有能力將資料庫的部分子數據集驅逐到持久存儲以減少內存的佔用。這種類型的DBMS可以把容量比內存更大的資料庫放到內存里，而無需切換回面向磁碟的存儲架構。一般的方法是使用一個內部的跟蹤機制，一旦發現那些不再被訪問的數據元組，就立即將其驅逐出內存。H-Store的anti-caching組件可以將這些不被訪問的數據元組存放到面向磁碟的存儲器中，同時在資料庫中添加一條「墓碑」信息來記錄這些數據的位置。當事務試圖通過「墓碑」記錄訪問元組時，它會被終止，然後另一個獨立線程會將數據非同步地放回到內存中。另一種支持「大於內存資料庫」的變體是EPFL的一個學術項目，它在VoltDB中使用OS虛擬內存分頁技術。為了避免假陰性，所有的DBMS在資料庫的索引中保留了已驅逐元組的鍵，這使那些具有許多次級索引的應用在內存節省方面的效果變差。雖然不是NewSQL DBMS，Microsoft的Project Sibera for Heikaton的每個索引都保持了一個Bloom過濾器，以減少內存中用於跟蹤已驅逐元組的內存開銷。

MemSQL採用了完全不同的方法來實現「大於內存資料庫」的功能。系統管理員可以手動設定DBMS將某個表存儲為列格式。MemSQL並不為磁碟存儲的元組在內存中保存任何跟蹤元數據。它將這些數據組織在日誌結構化存儲中以減少更新的開銷，這在傳統的OLAP數據倉庫通常很慢。

4.2 分區/分片

幾乎所有的分散式NewSQL DBMS水平擴展方案都是將資料庫分割成不相交的數據集，這稱之為分區或者分片。

在分區的資料庫上進行分散式事務處理並不是一個新的想法。這些系統的許多基本原理來自偉大的Phil Bernstein（和其他人）在1970年代後期的SDD-1項目中的開創性工作。1980年代的早期，兩個開創性的單節點DBMS項目，Syste R和INGRES的小組同時創建了分散式版本。IBM的R系統是一個類似於SDD-1的，無共享的，面向磁碟的分散式DBMS。INGRES的分散式版本給人們留下最深刻印象的是它的動態查詢優化演算法，遞歸地將分散式查詢分解成更小的部分。之後，威斯康辛-麥迪遜大學的GAMMA項目探索了不同的分區策略。

但是這些早期的分散式DBMS並沒有真正獲得成功，原因有兩個。首先是當時硬體成本太高，大部分的客戶不可能購買足夠多的設備來構建資料庫集群環境。其次是應用對分散式DBMS的高性能需求還沒有成熟，當時對DBMS吞吐量的最高要求也只有每秒數千筆交易。而我們現在這兩點原因都不復存在。構建大規模的數據密集型應用從未如此簡單，部分原因是開源分散式系統工具，雲計算平台和廉價的移動設備的激增。

資料庫的表被水平劃分為多個片段，劃分的邊界基於一個或多個列的值。這些列被稱為分區屬性。基於這些屬性值，DBMS使用範圍或散列的分區將每個元組分配給某一個片段。 來自多個表的相關片段被組合在一起以形成由單個節點管理的分區。 該節點負責執行所有訪問存儲在其分區中的數據的查詢。 只有DBaaS系統（Amazon Aurora，ClearDB）不支持此類型的分區。

理想情況下，DBMS應該能夠在多個分區上分散式地執行查詢，然後將所有結果合併為一個單一的結果返回給調用方。除了支持本地分區的ScaleArc之外的所有NewSQL系統都提供此功能。

分區是許多OLTP應用資料庫都具備一個重要特性。這些資料庫schema可以轉換為樹狀結構，樹的後代與根具有外鍵關係。然後依據這些關係關聯的屬性對錶進行分區，使得單個實體的所有數據都能位於同一分區。舉例來說，一個樹的根節點可能是一個客戶表，資料庫將會根據每一個客戶進行分區，將每個人的訂單記錄和賬戶信息存放在一起。這麼做的好處是它使大部分的事務只需要訪問一個單獨的數據分區就夠了。因為不需要使用原子通信協議（例如2階段提交）來保證事務在不同節點上正確執行，又進一步減少了網路通信開銷。

NewSQL DBMS中，NuoDB和MemSQL採用了與同質集群節點架構採用不同方案。NuoDB指定一個或多個節點作為每個資料庫分區的存儲管理器（簡稱為SM）。SM將資料庫分成塊（在NuoDB的術語中稱之為原子）。集群中所有其他的節點被當做事務引擎（簡稱為TE），它是原子在內存中的緩存。當處理一個查詢時，TE通過SM或其他TE可獲得這個事務所涉及的所有原子。獲得一個寫入鎖之後，對原子進行的任何更改都將廣播給其他的TE和SM。為了避免原子在節點之間來回移動，NuoDB公開了負載均衡方案以確保使用的數據會駐留在同一個TE中。這意味著NuoDB最終會具備與其他分散式DBMS相同的分區，但它不必進行資料庫的預分區或對錶關係進行預定義。

MemSQL同樣使用了一個類似的異構架構，包括只具備執行功能的聚合器節點和存儲實際數據的葉節點。MemSQL與NuoDB最大的不同在於二者如何減少從存儲節點拉到執行節點的數據量。在NuoDB中，TE會緩存原子來減少從SM中讀取的數據量，而MemSQL的聚合節點不緩存任何數據，但葉子節點會執行部分查詢，以此減少發送到聚合節點的數據量。這在NuoDB中是不可能的，因為存儲管理器只有數據存儲功能，沒有執行查詢的能力。

這兩個系統都能夠向DBMS集群中添加執行資源（NuoDB的TE，MemSQL的聚合節點）而無需對資料庫進行重新分區。SAP HANA的一個研究性的原型系統同樣採用了這個方法。不過，從性能和操作複雜度方面，異構架構是否比同構架構（即所有的節點都可以同時執行查詢和存儲數據）更優秀仍有待進一步通過實踐來檢驗。

NewSQL分區的一個新的功能是部分系統支持實時遷移。它們允許DBMS將數據在物理資源間進行遷移，以達到系統重新平衡，緩解熱點壓力，動態增加/減少DBMS容量的目的。這一點跟NoSQL系統的重新平衡類似，但是難點在於NewSQL DBMS需要在遷移中仍然維持ACID的事務特性。有兩種方法能夠做到這點。第一種方法是將資料庫組織成為許多粗粒度的「虛擬」（即邏輯）分區，並分布到各個物理節點上。這樣當DBMS需要重新平衡的時候，它可以將虛擬分區在節點間移動。Clustrix和AgilData使用了這種方法，NoSQL中的Cassandra和DynamoDB也使用了這種方法。另一種方法是DBMS通過範圍分區重新分布單個元組或多個元組來執行更細粒度的重新平衡。 這類似於MongoDB NoSQL DBMS中的自動分片功能。 ScaleBase和H-Store等使用了這種方法。

4.3 並發控制

並發控制方案是事務處理DBMS中最突出和最重要的實現細節，因為它影響系統幾乎所有的方面。並發控制允許最終用戶通過多個程序訪問資料庫，而每個程序在都認為自己運行在專用資料庫上。這一點非常重要，因為它提供了系統的原子性和隔離性保證，並由此影響了整個系統的行為。

除了系統並發控制方案外，分散式DBMS的設計的另一個重要方面是該系統使用集中式還是分散式事務協調協議。在集中式協調系統中，所有的事務操作都必須通過中央協調器，它負責決定事務是否得以執行。1970-1980年代的事務處理監控器（例如IBM的CICS，Oracle的Tuxedo）中採用了這種方法。而在分散式的協調系統中，每個節點維護訪問其數據的事務的狀態。節點之間相互協調來確定事務是否有衝突。分散式協調器具有更好的可擴展性，但為了產生和維護事務的全局順序，DBMS的所有節點都需要與同一個高精度時鐘保持同步。

1970-1980年代的第一代分散式DBMS系統使用了二階段鎖（two phase-locking，2PL）方案。SDD-1項目是第一個專用於由集中式協調器管理無共享節點集群中的分散式事務處理的DBMS。IBM的R類似於SDD-1，但是它的主要區別在於R系統的協調器是完全分散式的，它使用了分散式的2PL協議，這樣事務可以鎖定正在訪問的節點中的數據項。INGRES的分散式版本中同樣採用了分散的2PL和集中式的死鎖監測。

幾乎所有基於新架構的NewSQL系統都沒有使用2PL，因為處理死鎖問題的複雜度太高。當前的趨勢是使用時間戳順序並發控制的變體，其中DBMS假定那些違反串列順序的事務不會執行交錯的數據操作。在NewSQL系統中使用最廣泛的協議是分散式的多版本並發控制（multi-version concurrency control, MVCC）。其中DBMS會在數據元組被事務更新時創建新的副本。維護多個版本的方案使事務即使是在其他事務同時更新相同數據時也能夠成功地完成，也避免了長時間運行的只讀事務阻塞寫入操作。這個協議被多數基於新架構的NewSQL系統所採用，例如MemSQL， HyPer，HANA，CockroachDB等。雖然這些系統在實現MVCC的細節上使用了不同的工程方法進行優化，但是這個方案的基本概念並不是新的。MVCC最早是由在一篇MIT的博士論文中提出來的，第一個使用它的商業DBMS是1980年代Digital的VAX Rdb和InterBase。我們注意到InterBase的架構是由Jim Starkey設計的，他同時也是NuoDB最早的設計者，也是失敗的Falcon MySQL存儲引擎項目的設計者。

其他的系統使用了2PL和MVCC的組合方案。這種方案中事務仍然需要在2PL模式下請求鎖來更新資料庫，而同時當一個事務修改了一條記錄時，DBMS也為這條記錄創建一個副本。這個方案使只讀查詢可以避免請求鎖，因此不會阻塞寫事務。這個方法最著名的實現是MySQL的InnoDB。另外還有Google的Spanner，NuoDB，Clustrix也都用了這個方法。NuoDB改進了原始的MVCC，它使用gossip協議在節點間廣播版本信息。

所有的中間件和DBaaS服務都繼承了它們底層DBMS架構使用的並發控制方案，因為大部分都使用MySQL作為底層DBMS，所以大部分的都是使用的2PL加上MVCC方案。

我們認為Spanner（及其後代F1和SpannerSQL）中的並發控制實現是最新穎的NewSQL系統之一。實際方案本身是基於2PL和MVCC組合，但Spanner最大的不同是使用了硬體設備（例如GPS和原子時鐘）來做高精度時鐘同步，為事務分配時間戳，通過廣域網路實施其多版本資料庫的一致視圖。CockroachDB聲稱會提供與Spanner一樣的跨數據中心的事務一致性，但不使用原子鐘。 它們依賴於混合時鐘協議，該協議組合了鬆散同步的硬體時鐘和邏輯計數器。

Spanner引人注目的另一個原因是它預示著Google將在最關鍵的服務中重新使用交易。 Spanner的作者甚至表示，最好讓他們的程序員去處理由於過度使用事務造成的性能問題，而不是像NoSQL DBMS那樣編寫代碼來處理事務的缺失。

最後，唯一沒有使用MVCC及其變體的商業NewSQL DBMS是VoltDB。它仍在使用TO並發控制，不像MVCC那樣交錯執行事務，它通過調度使每個分區一次只有一個事務被執行。它還使用一種混合架構，其中單分區事務以分散方式調度，但多分區事務使用集中式協調器調度。VoltDB通過邏輯時間戳對事務進行排序，然後調度它們以便在輪到它們時在分區上執行。當事務在一個分區上執行時，它對該分區中的所有數據具有獨佔訪問，因此系統不必在其數據結構上設置細粒度的鎖和鎖存器。因為沒有來自其他事務的競爭，那些必須訪問單個分區的事務得以有效地執行。基於分區的並發控制的缺點是，如果事務跨越多個分區，它不能很好地工作，因為網路通信延遲會導致節點在等待網路消息時處於空閑狀態。這種基於分區的並發控制也不是新的想法。它的早期變體首先在1992年Hector Garcia-Molina的文章中提出，並在1990年代末在kdb系統和HStore（VoltDB的學術版本的前身）中得以實現。

綜上，我們發現除了值得稱道的工程方法使這些演算法在現代硬體和分散式操作環境中更為高效外，NewSQL系統中的核心並發控制方案沒有任何顯著的新特點。

4.4 次級索引

次級索引包含來自表的不同於其主鍵的屬性集。它允許DBMS支持主鍵和分區鍵以外的快速查詢。當整個資料庫位於單個節點上時，在非分區DBMS中支持它們是沒有太多意義的。但是在分散式DBMS中，不會總是以正好需要的屬性值進行分區。舉例來說，假設資料庫根據客戶表的主鍵進行了分區。但是可能會有一些情況希望通過客戶的email地址反向查詢客戶的賬戶。因為資料庫是按照客戶主鍵進行的分區，DBMS不得不將這個查詢廣播到所有節點，這明顯效率非常低下。

在分散式DBMS中支持次級索引有兩個設計決策：1）系統在哪裡存儲它們 2）如何由事務上下文維護他們。在使用集中式協調器的系統中，類似數據分片中間件，次級索引可以同時放在協調器節點和分片節點。這個方法的好處是整個系統中只有一個版本的索引，更加容易維護。

所有基於新架構的NewSQL 系統都是分散式的，使用的是分區的次級索引。意思是說每個節點存儲了索引的一部分，而不是一個完整的副本。分區索引和複製完整索引之間的折衷是，前面的查詢可能需要跨越多個節點來找到他們正在尋找的東西，但是如果事務更新索引，它將只需要修改一個節點。 在複製索引中，情況正好相反：查找查詢可以僅由集群中的一個節點滿足，但是任何時候事務修改次級索引關聯的數據， DBMS必須執行一個分散式事務來更新索引所有副本。

Clustrix使用分散次級索引，將上述概念混合在一起。DBMS在每個節點上維護一個粗粒度（基於範圍的）的索引的副本，而節點將索引值映射到分區。映射使用表分區屬性之外的其他屬性，這樣DBMS可以利用映射關係將查詢路由到適當的節點。因為次級索引將精確值映射到數據元組，於是查詢通過索引就可以訪問數據元組。這種兩層的方法僅僅映射範圍而不是單個的值，減少了保持索引副本在集群中同步所需的調度次數。

在使用不支持次級索引的NewSQL DBMS的過程中，開發人員創建次級索引最常見方法是使用內存中的分散式緩存（如Memcached）來部署索引。 但是使用外部系統需要應用程序來維護緩存，因為DBMS不會自動更新外部緩存。

4.5 複製

客戶為其OLTP應用保證數據的高可用性和持久性的最好的方法是複製資料庫。所有現代的DBMS，包括NewSQL系統，都支持某種機制的複製。DBaaS有一個突出的優勢是它將所有複製配置的細節都對客戶隱藏，因此部署一個DBMS的副本變得極為簡單，用戶無需關心日誌是否傳輸成功，數據是否同步。

在數據複製中有兩個設計決策。第一個是DBMS如何使數據保持節點間的一致性。在強一致的DBMS中，事務的寫入必須在被確認提交（即持久化）之前被確認並被安裝到所有副本。這種方法的好處是副本可以提供只讀的查詢並且仍保持一致性。也就是說，當應用收到了事務提交的確認，則該事務對資料庫的任何修改對於後續所有的事務都是可見的，無論它們訪問哪一個DBMS節點。同時，這樣意味著如果一個副本失效，系統並不會丟失任何更新，因為其他所有的節點都是同步的。但是維護這樣的同步需要DBMS使用原子提交協議（例如兩階段提交）來確保所有的副本與事務的執行結果一致，而這帶來了額外的開銷，並且如果節點失敗或者有網路分區延遲則，也可能導致系統停滯。這就是為什麼NoSQL系統選擇弱一致性模型（也稱為最終一致性），其中並非所有副本都必須在DBMS通知應用程序寫入成功之前確認修改。

我們所知道的所有NewSQL都支持強一致性複製。但是在系統如何保證一致性方面並沒有任何創新。在1970年代研究了DBMS的狀態機複製的基本原理。NonStop SQL是在1980年代構建的第一代分散式DBMS之一，它就使用了相同的強一致性複製提供容錯能力。

除了DBMS將更新傳播到副本的策略之外，還有兩種不同的執行模型用於決定DBMS如何執行此傳播。第一種是主動-主動複製，其中每個節點同時處理相同的請求。例如，當事務執行查詢時，DBMS在所有副本處並行執行該查詢。這不同於主動-被動複製，首先在單個節點處理請求，然後DBMS將所得狀態傳送到其他副本。大多數NewSQL DBMS實現第二種方法，因為它們使用非確定性並發控制方案。這意味著它們不能向副本發送查詢，因為它們可能在不同副本上以不同的順序執行，並且資料庫的狀態將在每個副本處出現分歧。因為執行順序取決於很多因素，包括網路延遲，緩存停滯，時鐘偏差等。

另一方面，確定性DBMS（例如，H-Store，VoltDB，ClearDB）不執行這些附加的協調步驟。這是因為這些DBMS要保證事務的操作在每個副本上以相同的順序執行，從而保證資料庫的狀態相同。VoltDB和ClearDB還確保應用程序不會執行那些使用外部信息源的查詢，因為這些信息在每個副本上可能是不同的（例如，將時間戳欄位設置為本地系統時鐘）。

另一個NewSQL系統的獨特之處是通過廣域網WAN來進行複製。這是現代操作環境的副產品，因為現在很少在遠距離的數據中心之間部署系統。所有的NewSQL DBMS都可以通過配置實現廣域網上的同步複製，但是這也會引起正常操作中很明顯的延遲，所以非同步複製的方式更為流行。據我們所知，NewSQL系統中只有Spanner和CockroachDB能提供廣域網上強一致副本的複製方案。Spanner使用了原子鐘和GPS來做時間同步，而CockroachDB使用的是混合時鐘方案。

4.6 崩潰恢復

NewSQL系統容錯功能的一個重要特徵是使用了崩潰恢復機制。傳統的DBMS容錯方案的重點是保障數據的更新不會丟失，而NewSQL DBMS除了這點以外，還希望最小化停機時間。現代的Web應用希望能夠一直保持在線，因為停機帶來的成本實在是太大了。

單節點無備份系統中恢復的傳統方法是，在DBMS修復後重新聯機，它將載入從磁碟取得的最後一個檢查點，然後重播其寫入日誌（write-ahead log, WAL）以使資料庫到達崩潰前那一刻的狀態。這種方法的經典實現被稱為ARIES，是IBM研究人員在1990年代發明的。 所有主流的DBMS都使用了ARIES的一些變體來實現故障恢復。

在有副本的分散式DBMS中，不能直接使用傳統的單節點方法，因為當主節點崩潰時，系統將會自動提升某個從節點充當新的主節點，而之前崩潰的主節點重新聯機後，因為DBMS已經有了新的數據，資料庫並不停留在崩潰之前的狀態，所以主節點不能直接從自己的檢查點中恢複數據。恢復的節點需要從新的主節點或者其他副本中更新自己的數據，彌補在停機這段時間內缺失的數據。有兩種方法來做這個事情：第一是恢復的節點仍然從自身的存儲中載入最後的檢查點和寫入日誌，然後從其他節點讀取缺失的日誌部分。如果這個節點處理日誌的速度比數據更新快，節點上的數據最終會達到與其他節點上的副本相同的狀態。如果DBMS使用物理日誌，那麼這種方法就是可行的，因為將日誌更新直接應用到元組的時間遠小於執行原始SQL語句所需的時間。另一種方法可以減少恢復的時間，即節點重新聯機時丟棄其檢查點，讓系統給它另一個新的檢查點，然後從這個點開始恢復。這種方法帶來的一個額外的好處是，系統中加入新的副本節點時也可以用同樣的機制。

中間件和DBaaS系統依靠底層單節點DBMS的內建機制來實現故障恢復，不過都增加了額外的主節點選擇和其他管理能力。基於全新架構的NewSQL系統結合現成的組件（例如ZooKeeper, Raft）和他們實現的已有演算法來做這類事情。所有這些都是自1990年代以來在商業分散式系統中可用的標準程序和技術。

1. 未來趨勢

我們預計，在不久的將來，資料庫應用程序的下一個趨勢是能夠對新獲取的數據執行分析查詢和機器學習演算法。這種通常也稱為「實時分析」或者「混合事務分析處理（hybrid transaction-analytical processing，HTAP）」的應用通過分析新數據和歷史數據的組合來進行知識推斷，獲得洞察力。比傳統的商業智能只能基於歷史數據進行操作要更為先進。對於現代應用來說，更短的周轉時間非常重要，因為數據的價值在其創建時非常巨大，但隨著時間推移逐漸減少。

在資料庫應用里有三個方法支持HTAP。最為常見的一個方法是部署另一個DBMS，讓其中一個專門處理事務，另一個處理分析查詢。在這個架構下，前端的OLTP DBMS存儲所有由事務創建的新數據，而在後端，系統使用抽取與轉換（ETL，extract-transform-load）工具將數據從OLTP DBMS導入到另一個後台的數據倉庫DBMS。應用在後端執行所有的複雜的OLAP查詢，避免拖慢OLTP系統。所有在OLAP系統中產生的新數據也將會被推送到前端的DBMS中。

被稱為λ架構的另一種主流系統設計是使用單獨的批處理系統（例如，Hadoop，Spark）來計算歷史數據視圖，同時使用流處理系統（例如，Storm，Spark Streaming）來提供輸入數據視圖。在這個分離式的架構中，批處理系統周期性地對數據集進行重新掃描，並將結果批量上傳到流處理系統，然後流處理系統將基於新的更新進行修改。

這兩種方法都有一些固有的問題。最重要的一點是，在兩個分離系統中進行數據傳輸的時間通常以分鐘甚至小時來計算，而且在數據傳輸時應用程序不能進行數據處理。第二個問題是，部署和維護兩種不同DBMS的管理開銷巨大，因為人工成本占整個大規模資料庫系統成本的的50%左右。

如果想要合併來自不同資料庫的數據，還需要應用程序開發人員為多個系統編寫查詢語句。一些系統試圖通過隱藏分離系統架構偽裝成單個平台，例如Splice Machine，但是這種方法還有其他技術問題，因為在OLTP系統（Spark）中使用它之前，需要複製來自OLTP系統（Hbase）的數據。

第三個我們認為更好的方法是使用單個HTAP DBMS，它既支持OLTP工作負載的高吞吐量和低延遲需求，又允許在熱數據（事務）和冷數據（歷史數據）上運行複雜的長時間運行的OLAP查詢。 這些較新的HTAP系統與傳統的通用DBMS不同的是，它們結合了最近十年來在OLTP（例如，內存存儲，無鎖執行）和OLAP（例如，列式存儲，矢量化執行 ）領域的技術積累，而且只需要一個DBMS。

SAP HANA和MemSQL是最早的兩個聲稱自己是HTAP系統的NewSQL DBMS。HAHA在內部使用多個執行引擎，一個用於更適合事務的行數據，另一個用於更適合於分析的列數據。MemSQL使用兩個不同的存儲管理器（一個管理行，一個管理列），但是混合在同一個執行引擎中。

HyPer原本使用H-Store風格的用於處理OLTP的並發控制。它切換到了帶有MVCC的HTAP列存儲體系結構，於是可以支持更複雜的OLAP查詢。VoltDB甚至將他們的市場宣傳策略從純粹的OLTP性能轉向提供流式語義。類似地還有S-Store項目，在H-Store架構之上增加了對流式處理操作的支持。始於2000年代中期的OLAP系統（例如，Greenplum）很可能將開始增強對OLTP的支持。

我們注意到HTAP DBMS的興起意味著巨大的整體式OLAP數據倉庫的衰落。這樣的系統在短期內仍然是必要的，因為它們是所有前端OLTP應用孤島通用的後端資料庫。 但是最終資料庫技術的發展將允許用戶執行跨越多個OLTP資料庫（甚至包括多個供應商）的分析查詢，而不需要移動數據。

1. 結論

我們分析的主要結果是，NewSQL資料庫系統並不是與現有的系統架構完全不同的新物種，而是代表資料庫技術不斷發展的下一篇章。 這些系統使用的大多數技術已經存在於學術界和工業界的先前DBMS中很多年。但是以前這些技術只是獨立地在某些系統中得到實現，因此NewSQL DBMS的創新之處在於它們將這些想法納入了單一平台，而且人們付出了巨大的工程努力，作出了很多創新性的工作。雖然NewSQL DBMS是伴隨著更廉價而豐富的計算資源出現的，但它們的應用範圍和應用前景也因此而更為廣泛。

同樣有趣的是考慮NewSQL DBMS潛在的影響和未來的方向。鑒於傳統的DBMS提供商的市場地位牢不可破，資金充足，NewSQL系統只能通過艱難的戰鬥贏得市場地位。在過去的五年中，一些NewSQL公司已經關閉（例如GenieDB，Xeround，Translattice）或者轉向重點關注其他問題域（例如ScaleBase，ParElastic）。基於我們對一些公司的的分析和訪談，我們發現NewSQL系統的採用率相對較低，尤其是與開發人員驅動的NoSQL相比的時候。這是因為NewSQL DBMS的設計目標是支持事務性的工作負載，而這些應用大多數是企業應用。與Web應用相比企業應用對於資料庫的選擇更加保守。另外我們也發現NewSQL DBMS用於補充或者替換現有的RDBMS，但NoSQL通常用於新業務系統的開發。

2000左右OLAPL DBMS剛剛興起的時候，大部分開發商都被主要的技術公司收購。而NewSQL領域裡目前還只有一家公司被收購。在2016年3月，Tableau宣布它收購了HyPer項目的初創公司。另外兩個可能的例外是：1）2015年3月蘋果公司收購了FoundationDB，但是我們把它排除在外，因為這個系統底層是NoSQL的Key-Value存儲，上面只有一層效率低下的SQL層；2）ScaleArc收購了ScaleBase，但這起收購案發生在競爭對手之間。這些案例中沒有一個是傳統巨頭收購新興公司的情況（例如2011年，Teradata收購Aster Data System）。反過來，我們看到巨頭們更願意在自己的系統上進行改進和創新，而不是去收購初創的NewSQL公司。2014年Microsoft在SQLServer上新增了內存Hekaton引擎來增強OLTP處理能力。Oracle和IBM的創新進度比較慢，他們最近才為系統添加了列存儲擴展，與新興的OLAP DMBS（例如HP Vertica和Amazon Redshift）展開競爭，並有可能在未來推出內存中的OLTP工作負載處理系統。

從更長期來看，我們將資料庫的發展歸納為四類：1）始於1980-1990年代的傳統DBMS；2）始於2000年代的OLAP數據倉庫；3）始於2000年代的NoSQL DBMS，以及4）始於2010年代的NewSQL。我們希望在這些分類中所有的核心系統將會支持某種形式的關係模型和SQL（即使它們還沒有），並且會像HTAP DBMS一樣同時支持OLTP操作和OLAP查詢。當這一天到來時，這些標籤將成為歷史。

（完）