NewSQL 究竟新在哪裏？

近幾年來，數據庫領域出現了一種新的關係數據庫類型，稱爲NewSQL，例如，Google的Spanner，Amazon的Aurora等等，這些數據庫相對於傳統數據庫來說，區別在哪裏？What's Really New with NewSQL?給了很好的總結，本篇文章主要是總結該論文的觀點，最後會有一個簡單的討論部分，全文的組織結構以下：

• 爲何須要NewSQL？
• NewSQL的分類
• NewSQL的技術挑戰有哪些？
• 討論

本文收錄在個人github中papers項目，papers項目旨在學習和總結分佈式系統相關的論文。
同時本文也同步發佈在我的博客oserror.com。

爲何須要NewSQL？

數據庫的發展一般是隨着業務需求的變化，在2000年左右，隨着互聯網的興起，有許多同時在線的用戶，這對數據庫領域帶來了很是大的挑戰，數據庫一般會成爲瓶頸，因此，此時業務針對數據庫的需求，主要體如今可擴展上面。

這時期數據庫的擴展性，每每採用以下兩種方案：

1. 垂直擴展：使用更好的硬件，來作數據庫的服務器
2. 水平擴展：採用中間件，作sharding的方式，即分庫分表的方式

垂直擴展中使用更好的硬件意味者成本高，而且更換硬件後，須要把數據從老的機器遷移到新的機器，中間可能須要停服務，所以每每採用水平擴展，例如，Google's MySQL-based cluster。

採用中間件方式也有缺點，中間件通常要求輕量級，簡單數據庫操做能夠搞定，可是，若是須要作分佈式事務或者聯表操做，會很是複雜，一般這些邏輯會放到應用層來作。

後續，NOSQL興起，主要有幾個緣由：

1. 傳統關係數據庫更傾向於一致性，而在性能和可用性比較差
2. 全功能的關係型數據庫過重
3. 關係模型對於簡單的查詢過重，沒必要要

NOSQL以Google’s BigTable 和 Amazon’s Dynamo爲表明，開源版對應爲HBase和Cassandra。

NOSQL每每是不保證強一致性的，而對於一些應用來說（例如金融服務），是須要強一致性和事務的，所以，若是它們基於NOSQL系統來開發的話，應用層須要些大量的邏輯來處理一致性和事務相關的問題。此時，業務需求是擁有可擴展性的基礎上，可以支持強一致性。

所以，這裏有幾條路：

1. 性能更好的單個服務器來作數據庫服務器
2. 中間件層支持分佈式事務

使用更好的單個服務器的話，不知足業務需求的可擴展性。

使用中間件的話，會有以下問題，例如：

1. 中間件層每每是比較輕量級的，要實現一致性，必須在中間件層實現分佈式事務，這點是很是困難的
2. 中間件層自己的高可用很難保證

上面兩條路都不能很好的知足應用的需求，所以，NewSQL出現了。

首先來看NEWSQL的定義：針對OLTP的讀寫，提供與NOSQL相同的可擴展性和性能，同時能支持知足ACID特性的事務。即保持NOSQL的高可擴展和高性能，而且保持關係模型。

NEWSQL的優勢：

1. 輕鬆的得到可擴展性
2. 可以使用關係模型和事務，應用邏輯會簡化不少

注意，此篇論文中的NEWSQL偏向於OLTP型數據庫，和一些OLAP類型的數據庫不一樣，OLAP數據庫更偏向於複雜的只讀查詢，查詢時間每每很長。

而NEWSQL數據庫的特性以下，針對其讀寫事務：

1. 執行時間短
2. 通常只查詢一小部分數據，經過使用索引來達到高效查詢的目的
3. 通常執行相同的命令，使用不一樣的輸入參數

NewSQL的分類

分三大類：

1. 從頭開始，使用新架構的系統
2. 中間件
3. DAAS，數據庫即服務

New Architectures

採用新架構的NewSQL有以下特色：

1. 無共享存儲
2. 多節點的併發控制
3. 基於多副本作高可用和容災
4. 流量控制
5. 分佈式查詢處理

優點：

1. 全部的部分均可覺得分佈式環境作優化，例如查詢優化，通訊協議優化。例如，全部的NEWSQL DBMS能夠直接在節點間發送查詢，而不是經過中心節點，例如中間件系統
2. 自己負責數據分區，所以，能夠把查詢發送給有數據的分區，而不是把數據發送給查詢。
3. 擁有自身的存儲，能夠指定更復雜的多副本的方式

缺點：

1. 懂該數據庫的人少，缺乏專業的運維

表明產品：Spanner，CockroachDB

Transparent Sharding Middleware

中間件負責的事情以下：

1. 對查詢請求作路由
2. 分佈式事務的協調者
3. 數據分佈，數據多副本控制，數據分區

每每在各個數據庫節點，須要裝代理與中間件溝通，負責以下事情：

1. 在本地節點執行中間節點發來的狀況，而且返回結果

優勢：

1. 應用一般不須要作變化

缺點：

1. 各個節點仍是運行傳統數據庫，即以磁盤爲核心的數據庫，對現有的大內存，多核服務器難以高效地利用
2. 重複的查詢計劃和查詢優化，在中間件作一次，在各個DBMS作一次

備註：有研究代表，以磁盤爲主要存儲的傳統DBMS，很難有效地利用很是多的核，以及更大的內存容量。

表明產品: MariaDB MaxScale, ScaleArc

Database-as-a-Service

特色：

1. 用戶能夠按需使用
2. 數據庫自己可能使用雲產品，例如雲存儲等，能夠較容易的實現可擴展性

表明產品：

1. Amazon Aurora
2. ClearDB

NewSQL的技術挑戰有哪些？

Main Memory Storage

傳統數據庫都是以磁盤爲存儲中心的架構，讀盤操做相對較慢，通常是內存中緩存頁。

如今來說，內存較便宜，容量大，能存儲大量的數據。這些純內存操做帶來的好處是，讀取和寫入數據速度較快。

現有的大內存服務器，對數據庫對內存的管理提出了新的要求，再也不是像傳統數據庫那樣，只是用來作頁緩存，能夠採用更高效地內存管理方式。

Partitioning/Sharding

數據分區通常以某幾列作hash或者range分區。

特色：

• 數據庫須要能在多個分區執行SQL，而且合併數據結果的功能。
• 把同一個用戶的數據能夠放在一塊兒，即便是不一樣數據表的數據，能夠減小通訊開銷。
• 能夠在線的添加或者刪除機器。
• 能夠在線的遷移或複製分區。

Concurrency Control

數據庫經過Concurrency Control來提供ACID中的Atomicity和Isolation。

Atomicity

分佈式場景下，通常採用類2PC的協議，根據事務是否須要中心節點，分爲如下兩類：

1. 中心節點：單點，容量限制
2. 非中心節點：須要時鐘的同步

關於時鐘同步，不一樣數據庫也有不一樣的作法，Spanner和CroachDB在時鐘同步上的不一樣選擇：

But what makes Spanner differ- ent is that it uses hardware devices (e.g., GPS, atomic clocks) for high-precision clock synchronization. The DBMS uses these clocks to assign timestamps to transactions to enforce consistent views of its multi-version database over wide-area networks. CockroachDB also purports to provide the same kind of consistency for transactions across data centers as Span- ner but without the use of atomic clocks. They instead rely on a hybrid clock protocol that combines loosely synchronized hardware clocks and logical counters [41].複製代碼

Isolation

現有實現Isolation的技術主要包括：

• 2PL：two phase locking
• MVCC: Multiversion Concurrency Control
• OCC: Optimistic Concurrency Control

大部分的數據庫仍是在選擇使用MVCC，例如CockroachDB；有些數據庫使用2PL+MVCC，修改數據的時候，仍是採用2PL，例如，InnoDB，Spanner

Secondary Indexes

通常有兩種實現方式：局部索引VS全局索引

局部索引：

1. 每一個partition有一部分索引數據，每次修改索引，只須要修改一個節點，但查找數據須要可能涉及多個節點

全局索引：

1. 每一個partition都有完整的索引數據，每次修改索引，都須要使用分佈式事務，修改全部包含此索引副本的節點，查找數據只須要在一個節點

Replication

兩個須要考慮的點：

1. 如何保證一致性：Paxos和2PC（跨Partition）
2. 同步的方式：採用同步執行命令的方式，仍是同步狀態的方式

Crash Recovery

如何最小化宕機時間？

採用主備切換

如何優化新加機器恢復到同步的時間？

通常手段爲作checkpoint

討論

可擴展性是NewSQL的一個很是重要的特色，對於中間件的方式，其上須要存路由信息，其自己的可擴展性比較難以解決，我的認爲，其不該該算入NewSQL。

NewSQL的技術挑戰除了上述提到的以外，還有如何實現多租戶架構及租戶之間的隔離，負載均衡等等問題。

從整篇論文中描述的內容能夠看出，NewSQL中並無開拓性的理論技術的創新，更多的是架構的創新，以及把現有的技術如何更好地適用於當今的服務器，適用於當前的分佈式架構，使得這些技術有機的結合起來，造成高效率的總體，實現NewSQL高可用，可擴展，強一致性等需求。

PS:
本博客更新會在第一時間推送到微信公衆號，歡迎你們關注。

qocde_wechat

參考文獻

• What's Really New with NewSQL?