關係型數據庫 RDBMS 的舊與新 -- 談談 NewSQL

做者簡介

陳運海

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）是一個數學上的概念，其定義爲：

給定 n 個集合 S1, S2, ..., Sn，R 是一個 n 元數組（n-tuples），它的第一個元素取自集合S1，第二個元素取自集合S2，以此類推。咱們將 R 稱之爲基於該 n 個集合的一個 Relation，Sj爲 R 的第 j 個域（Domain）。

簡要的表述：

R 是集合 S1 × S2 × ... × Sn 笛卡爾積的一個子集

在工業界，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 臺數據庫，數據分發策略爲：

hash(some_field_in_record) % 5

後來因爲業務訪問量增長，須要 7 臺數據庫服務器的時候，相應的數據分發策略爲：

hash(some_field_in_record) % 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/