作者簡介
陳運海
DaoCloud 資料平臺架構師，長期關注資料庫系統、分散式系統、區塊鏈等領域。
這是最好的時代，也是最壞的時代。
在這個時代我們有各種技術可以選擇，在這個時代我們有各種技術要選擇。
言必稱網際網路
在計算機科技這塊蓬勃發展的領域，新技術形態和新的商業模式源源不斷的湧現、令人眼花繚亂。世紀之初的以流量為王網際網路泡沫破滅，並不能阻擋當下網際網路行業繼續攀登高峰，只是在這將近20年的時間裡，消費者與網際網路從業人員有足夠長的時間一點一滴地將行業基礎夯實，將原來的浮雲壘高臺，變為了今天一個實實在在的行業。
網際網路已經從計算機網路、通訊領域的一個名詞慢慢演變成了一個形容詞，網際網路行業、網際網路應用（Internet application）中的網際網路代表著高併發、敏態IT、快速伸縮、資料驅動、精益運營等等，一切都顯得區別於傳統的行業、傳統的應用。
支撐網際網路應用的 PaaS 平臺已經日漸清晰，以 Docker 為代表的容器技術，在勢頭上已經力壓虛擬機器，為網際網路應用提供了標準的執行環境。而在上層的叢集管理、編排標準，大而全的 Kubernetes 和不甘於繼續做小巧靈巧的 Swarm，聯合開源社群的眾多玩家（Spring Cloud, Tyk, Prometheus）等，共同打造了包含負載均衡、彈性伸縮、服務註冊與發現、應用監控等功能的面向網際網路應用的高可用 PaaS 平臺。
另一方面，網際網路應用典型的高併發訪問量、大資料儲存量以及跨地理區域等特性使得傳統的基於關係型資料庫的應用架構無所適從，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 試圖比肩擴充套件性佔優的 NoSQL，並且實現傳統關係型資料庫所擅長的滿足 ACID 特性的事務處理。然而考慮到關係型資料庫，從 Edgar F. Codd 的文章 A Relational Model of Data for Large Shared Data Banks 發展到 NoSQL 盛行再到今天，學術界與工業界並進的資料庫理論和工程差不多已經經歷了四十多年了，那麼，標榜為 New 的 NewSQL，到底 New 在哪裡？NewSQL 是真有其貨還是隻是商業上的一種遊戲？
關係模型與 SQL 標準
在關係型資料庫流行併成為資料庫領域真正意義上的標準之前，曾經出現過幾個往往被一筆帶過的模型的資料庫，基本上都可以歸類為導航型資料庫，它們在物理結構上面向的是磁帶儲存，在邏輯結構上是現實世界某種程度的對映。例如：層級模型是以樹形結構組織資料的，每個子節點只會擁有唯一的父節點。公司內部的組織結構就是我們所熟悉一個層次結構。
A navigational database is a type of database in which records or objects are found primarily by following references from other objects.
不得不提的一個層次模型資料庫是誕生於 1968 年的 IBM 的 IMS（Information manangement system）。相傳在 1966 年，美國國家航空航天局找到了 IBM，尋求一款軟體，以求在登月工程中能夠有效的跟蹤管理數以萬計的火箭零部件。
If we could put a man on the Moon, could we also create a computer program to track the millions of rocket parts it takes?
如今，IMS 依然老當益壯，在大型製造業、銀行依然承擔著重要的角色，還會時不時的舉辦社群活動。但是它已經淡出了我們這些標榜為網際網路從業人員的視線，畢竟在推崇開源、微服務、敏態 IT、輕資產的網際網路行業，它已經顯得格格不入了。
但是它對整個資料庫領域，甚至整個電腦科學都留下了不可磨滅的貢獻，時至今日，再楞頭的程式設計師，也不會輕易把自己深陷在應用自己管理、查詢資料的泥淖裡。
It helped introduce the idea that an application’s code should be separate from the data that it operates on. This allows developers to write applications that only focus on the access and manipulation of data, and not the complications and overhead associated with how to actually perform these operations.
1970 年，同樣是 IBM 的 Edgar Codd 發表了資料庫發展史上重量級的一篇文章 A Relational Model of Data for Large Shared Data Banks（文章地址：https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf），Edgar 在這著名的文章裡，以數學理論為基礎，論證了為了做到對稱探索（Symmetric Exploitation），即使用者可以根據任何已知的屬性組合去探索剩下的未知屬性，必須要消除導航資料庫中的幾個依賴：
- 排序依賴
- 索引依賴
- 訪問路徑依賴
很多人認為關係型資料庫的成功在於其完美的數學模型，但是不可忽視的另外一面，關係型資料庫在資料庫發展的混沌時期，為其開啟了一面窗，原本導航型資料庫，關注點在於資料的寫入和基於路徑的資訊檢索，而關係型資料庫，讓人們看到了資料分析的曙光。
之後藉助於硬體技術特別是儲存裝置的發展，出現了支援 Semi-random access 的磁碟，關係型資料庫如魚得水，加上之後演繹出的關係代數、 E-R 模型、SQL 標準、 Codd`s 12 rules、資料倉儲等等，使其主導了資料庫領域近 40 年。
The introduction of low-cost hard drives that provided semi-random access to data led to new models of database storage better suited to these devices. Among these, the relational database and especially SQL became the canonical solution from the 1980s through to about 2010.
關係型資料庫中的 關係 並不是指我們直觀感受到的表與表之間通過外來鍵關聯在一起的 關係，關係（Relation）是一個數學上的概念，其定義為：
簡要的表述：
在工業界，1979 年誕生的 Oracle、1983 年誕生的 DB2，90 年代開源領域的 MySQL 和 PostgreSQL，都是各位耳熟能詳的幾個有名的資料庫。
資料庫領域下一個大事件就是 SQL 的標準化了。由於 Edgar 並未在那篇著名的論文中指定關係型資料庫具體實現方法，只是描述了關係模型，據此，市面上出現了多個關係型資料庫，各個系統的儲存引擎各不相同，資料的組織形式千差萬別。程式導向的資料庫操作語言顯然是不合適的。
比如，某一個學校組織了一次考試，為了錄入每個學生的成績，教務處老師需要處理以下細節：
1.成績表的儲存位置
2.各個列的組織形式
3.分隔符
4.解壓縮演算法
…
你也一定會同意，這樣不行！的確，這樣對應用的侵入性太強。我們哪裡在寫應用，我們在寫瑣碎的計算細節！
SQL 是高階的非過程化資料庫操縱語言，它允許使用者在高層資料結構上工作，不要求使用者指定對資料的存放方法，也不需要使用者瞭解其具體的資料操縱方式。它將資料庫以一個簡單的介面呈現出來，能使具有底層結構完全不同的資料庫系統和不同資料庫之間，使用相同的 SQL 作為資料的輸入、運算與管理。
你只需要用這種標準化的語言，告訴資料庫你要做什麼，而不是告訴它，為了做這件事情，所要一步步地怎麼做。
回到錄入成績那個例子，你只需要對資料庫執行以下操作：
create table score(id int, name string, level char);
insert into score values(12, John, `B`)
insert into score values(19, Lily, `A`);
...複製程式碼查詢獲得 `A` 的學生名單？小菜一碟：
select * from score where level = `A`;複製程式碼解耦合是計算機領域一個長盛不衰的話題，縱便有 data locality，儲存計算分離也是一股強大的潮流；應用和資料庫解耦合催生了資料庫，程式設計與執行平臺的解耦合催生了高階程式語言、編譯器；應用與承載平臺的解耦合催生了容器技術、Docker。
扯遠了，有一點是要記清楚的，耦合存在的意義就是被解開，就像記錄存在的意義就是被打破一樣。
網際網路時代的探索
網際網路應用猶如一頭咆哮的巨獸，對於習慣了傳統應用的人們來說，彷彿先民在《山海經》裡所描繪的巨獸。
面對網際網路應用的高併發、大容量和跨地域等挑戰，Sharding 是分而治之的最為樸素的解決方案，基本思想就是面對九頭蛇這種怪獸，召集九個有能力對付一條蛇的獵人，一起投入戰鬥。
Sharding 的具體做法是把一個 Database 切分成幾個部分放到不同的伺服器上，以分散式的手段增強資料庫的效能。Sharding 又有水平切分和垂直切分的區別，如果資料庫中 table 較多，可以把不同的表放在不同的伺服器上，這便是垂直切分。如果某些 table 的資料量特別大，需要對其進行水平切分，將這個表的資料分發到多個伺服器上。在網際網路應用場景，一般以水平切分為主，實現上以資料庫中介軟體（Database middleware）為主，之後的討論不特別說明的情況，Sharding 都是指水平切分。
由於原理上的限制，Sharding方案几乎很難做到有效的擴充套件。比如，某大型網際網路應用預測需要 Sharding 5 臺資料庫，資料分發策略為：
後來由於業務訪問量增加，需要 7 臺資料庫伺服器的時候，相應的資料分發策略為：
為了保障老資料還能夠正確的訪問，這裡就需要做資料的重新分發了，那麼大數量的資料重新載入，是一個很漫長而痛苦的過程。網際網路應用，一般都不能承受如此長時間的服務中斷。可以選擇在備庫上操作，但是過程相當也煩瑣。
當然，深入一點的有一致性 Hash 演算法，但往往會造成分片資料庫之間的負載傾斜，理論上並無很好的解決辦法。
另外，Sharding 方案對事務的支援蛻化嚴重，有 Sharding 表參與的關聯大部分需要應用開發者自己實現其邏輯。
Sharding middleware works well for simple operations like reading or updating a single record.It is more difficult, however, to execute queries that update more than one record in a transaction or join tables.
最終一些公司放棄了 Sharding 中介軟體的努力，開始開發它們自己的資料庫管理系統，開啟了 NoSQL 之路。傳統的資料庫系統往往為了一致性和正確性，而犧牲了高可用性和高效能。這種 trade-off 對於基於 Web 的網際網路應用是不合適的，它們需要更多的是系統的高可用性和高併發下的效能，被關係型資料庫拒之門外的非結構化資料也是這一過程重要的推手。創新之路最早開始對於一些簡單的網際網路應用，它們只是重複不斷地寫入記錄，根據主鍵執行 look-up 查詢，這樣一來，關係模型和 SQL 都成了累贅，資料的寫入和查詢都是通過更為高效的 API 來完成，因此，最開始 NoSQL 是 No more SQL 的簡稱。
後來，在易用性上也有一些系統慢慢加入了部分 SQL 的支援，除此之外， NoSQL 在高可用性、效能等方面也有著不錯的表現，NoSQL 最終演變成 Not Only SQL。
然而，放棄了關係模型，支援的 SQL 也只是標準的一小部分，在 API 方面 NoSQL 沒有也不可能有一個通用的標準，也就是在 NoSQL A 系統上執行的應用是不可能遷移到 NoSQL B 上的，也就是平常我們所說的技術棧繫結。NoSQL 更像是一個桀驁不馴的野馬，伯樂視之若千里馬，也有人被摔的鼻青臉腫。
NoSQL 中兩個最有名的系統當屬 Google 的 Bigtable 和 Amazon 的 Dynamo 了，它們開始都是隻對內服務的（現在已經開放為雲服務），其他的企業和組織開始根據它們的設計理念，集結開源社群的力量，建立了幾個有名的系統，包括 Cassandra, HBase 和 MongoDB。
NewSQL 的迴歸
計算機行業的發展是一個很有趣的過程，一些對自己需求、現有系統充分了解的大牛們，嫌棄現存的系統對他們強加了太多的限制，於是他們另起爐灶，搞了一套新的好用的東西。之後為了造福於天下，惠及眾生，接入了通用性，加入各種各樣的介面和規範，成了標準化的產品，繼續被新一輪大牛嫌棄並拋棄。
引入了分散式的架構的 NoSQL，在擴充套件性、高可用性和效能上相對於傳統關係型資料庫有著很大的提升，然而它們付出的代價是去除了事務支援和關係模型，同時，大部分系統都為了高可用性而放棄了系統的強一致性，而採用最終一致性模型，加上缺少 SQL 和統一的 API 規範，普通的應用開發者很難在這樣的系統上正確地構建他們網際網路應用。包括 Google 內部的應用開發人員，也有著類似的抱怨。
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.
OLTP 應用開發者關注的重點在資料庫的高併發、事務的支援上，這些事務的讀寫，具有以下幾個典型特徵：
1.Short-lived （i.e., no user stalls）
2.Touch a small subset of data using index lookups （i.e., no full table scans or large distributed joins）
3.Repetitive （i.e., executing the same queries with different inputs）
而之後的資料分析、資料探勘等，則不屬於 OLTP 的範疇，也不屬於 NewSQL 針對的場景。
NewSQL 是某種程度的迴歸，它試圖重新拾起被 NoSQL 拋棄的 ACID，ACID 是資料庫事務正確執行的四個基本要素，也就是 NewSQL 試圖重拾事務。
- Atomicity 原子性
- Consistency 一致性
- Isolation 隔離性
- Durability 永續性
這裡的一致性，與分散式系統常說的一致性並非同一個概念，傳統關係型資料庫往往是單機版的，這裡的一致性指的是事務，不管成功與否，都不會破壞任意已經定義好的關於資料的約束，比如外來鍵約束。而分散式系統中的一致性，也並不是同一份資料的多個副本是完全一致的，而是說不同的觀察者，對於同一個資料，讀取的內容是一致的。
引入了事務的支援，NewSQL 為了更好的解放開發者，進一步加入了 SQL 的支援和分散式一致性的支援。
NewSQLs enable applications to execute a large number of concurrent transactions to ingest new information and modify the state of the database using SQL (instead of a proprietary API). If an application uses a NewSQL DBMS, then developers do not have to write logic to deal with eventually consistent updates as they would in a NoSQL system.
在 What`s Really New with NewSQL? 那篇文章裡，作者對於當前存在的 NewSQL 資料庫，大致有以下三個分類：
採用全新架構的新系統
分散式 Shared-nothing 基因，零歷史包袱，多節點併發控制，多副本容錯，分散式查詢與優化。
Send the query to the data rather than bring the data to the query
獨立管理資料儲存，對資料有更直接、更細粒度的控制，不依賴現有的分散式儲存系統、分散式檔案系統。
Examples: ClustrixDB，CockroachDB，Google Spanner，MemSQL，NuoDB
重新實現的 Sharding 中介軟體
中心化的中介軟體負責查詢分發、協調事務處理、管理資料與副本分佈、節點管理；資料節點負責資料的儲存與查詢，並接收中介軟體發來的讀寫請求，返回結果等。
對應用呈現了一個單體的邏輯層的資料庫，不需要修改底層的DBMS。基於傳統 RDBMS 的應用甚至可以不修改任何程式碼就能夠無縫的遷移。
Examples: AgilData Scalable Cluster，MariaDB MaxScale，ScaleArc，ScaleBase.
全新架構的雲資料庫
DataBase as a Service（DBaaS），雲服務提供商負責運維，使用者只需按需申請資源並按需付費。
Examples: Amazon Aurora，ClearDB.
從文章作者流露於紙面的態度，我們做一個越俎代庖的猜測，作者並不是很認可分類二，有興趣的同學可以閱讀一下原文。另外，其他的 NewSQL 系統也注意到了協議相容的好處，比如 CockroachDB 相容 PostgreSQL wire protocol，ClustrixDB 號稱相容 MySQL 等。
Really new ?
迴歸到 NewSQL 的 New 之爭，這部分過於專業，還是建議感興趣的同學們閱讀原文，我們在這裡只一個大概的總結。在 What`s Really New with NewSQL?（文章地址：http://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf） 文章作者從以下幾個方面，對 NewSQl 所採用的技術進行了分析：
- 面向記憶體的儲存
- 資料分割槽
- 併發控制
- 二級索引
- 副本機制
- 故障恢復
The main takeaway from our analysis is that NewSQL database systems are not a radical departure from existing system architectures but rather represent the next chapter in the continuous development of database technologies. Most of the techniques that these systems employ have existed in previous DBMSs from academia and industry. But many of them were only implemented one-at-a-time in a single system and never all together. What is therefore innovative about these NewSQL DBMSs is that they incorporate these ideas into single platforms. Achieving this is by no means a trivial engineering effort. They are by-products of a new era where distributed computing resources are plentiful and affordable, but at the same time the demands of applications is much greater.
陽光之下，並無新事。NewSQL 所採用的各種技術已經廣泛應用在多個資料庫中，只是這一次，NewSQL 把這些技術組合在了一起。作者期待 NewSQL 開啟一個新的時代，肯定了 NewSQL 特別是 NewSQL 在工程方面的成就，畢竟：
Distributed systems engineering is full of tradeoffs.
未來之光 HTAP
業務的支撐、資料的採集只是企業資料閉環中的一部分，盤活數字資產，打造資料驅動型、商務智慧型的公司，是當前網際網路行業的一大願景。然而，由於底層資料的儲存結構很難同時折中 Fast analytics 和 Fast inserts and updates 的效能，當今大部分企業依然需要藉助於另外一套系統——OLAP。
OLTP 流入系統的資料，通過源源不斷 ETL 等過程，匯入到 OLAP 分析型資料庫，之後通過報表分析和資料探勘、機器學習等手段，生成決策結果，反作用於業務，調整業務，構成資料閉環。
同時維護了兩套資料的 OLTP 和 OLAP 由於資料的冗餘，成倍增加了系統的儲存開銷；依賴於 ETL 的資料複製，決策系統的時效性受到了很大的影響；同時，固定時間的 ETL 過程也對兩個系統的效能施加了很大的壓力。
人們對大統一的追求是永無止境的。在 What`s Really New with NewSQL? 文章中，作者預測資料庫系統的下一個大的趨勢就是整合 OLTP 和 OLAP，也就是所謂的 Hybrid Transaction-Annlytical Processing。
大資料巨頭 Cloudera 在 2015 年推出的 Kudu 儲存引擎試圖達到這一目標，不過根據目前的 Google trends，這個專案並沒有太火。NewSQL 中的諸多廠商都有這樣的 Roadmap（雖有廠商號稱它們已經是 HTAP 系統，但筆者更傾向於這是一個任重道遠的任務），比如 CockroachDB，ClustrixDB，MemSQL。
借一張圖來說明 HTAP 的優勢。
參考文獻
[1] Codd, E.F (1970). “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM. Classics. 13 (6): 377–387.
[2]Andrew Pavlo , Matthew Aslett, What`s Really New with NewSQL?, ACM SIGMOD Record, v.45 n.2, June 2016 [doi>10.1145/3003665.3003674]
[3] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, and D. Woodford. Spanner: Google’s Globally-Distributed Database. In OSDI, 2012.
[4] David F. Bacon, Nathan Bales, Nico Bruno, Brian F. Cooper, Adam Dickinson, Andrew Fikes, Campbell Fraser, Andrey Gubarev, Milind Joshi, Eugene Kogan, Alexander Lloyd, Sergey Melnik, Rajesh Rao, David Shue, Christopher Taylor, Marcel van der Holst, and Dale Woodford.2017. Spanner: Becoming a SQL System. In Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD `17). ACM, New York, NY, USA, 331-343. DOI: https://doi.org/10.1145/3035918.3056103
[5] ClustrixDB. https://www.clustrix.com/
[6] CockroachDB. https://www.cockroachlabs.com/
[7] Navigational database.
https://en.wikipedia.org/wiki/Navigational_database
[8] Kudu. https://kudu.apache.org/