近幾年來，資料庫領域出現了一種新的關聯式資料庫型別，稱為NewSQL，例如，Google的Spanner，Amazon的Aurora等等，這些資料庫相對於傳統資料庫來講，區別在哪裡？What's Really New with NewSQL?給了很好的總結，本篇文章主要是總結該論文的觀點，最後會有一個簡單的討論部分，全文的組織結構如下：
- 為什麼需要NewSQL？
- NewSQL的分類
- NewSQL的技術挑戰有哪些？
- 討論
本文收錄在我的github中papers專案，papers專案旨在學習和總結分散式系統相關的論文。
同時本文也同步釋出在個人部落格oserror.com。
為什麼需要NewSQL？
資料庫的發展通常是隨著業務需求的變化，在2000年左右，隨著網際網路的興起，有許多同時線上的使用者，這對資料庫領域帶來了非常大的挑戰，資料庫通常會成為瓶頸，所以，此時業務針對資料庫的需求，主要體現在可擴充套件上面。
這時期資料庫的擴充套件性，往往採用如下兩種方案：
- 垂直擴充套件：使用更好的硬體，來做資料庫的伺服器
- 水平擴充套件：採用中介軟體，做sharding的方式，即分庫分表的方式
垂直擴充套件中使用更好的硬體意味者成本高，並且更換硬體後，需要把資料從老的機器遷移到新的機器，中間可能需要停服務，因此往往採用水平擴充套件，例如，Google's MySQL-based cluster。
採用中介軟體方式也有缺點，中介軟體一般要求輕量級，簡單資料庫操作可以搞定，但是，如果需要做分散式事務或者聯表操作，會非常複雜，通常這些邏輯會放到應用層來做。
後續，NOSQL興起，主要有幾個原因：
- 傳統關聯式資料庫更傾向於一致性，而在效能和可用性比較差
- 全功能的關係型資料庫太重
- 關係模型對於簡單的查詢太重，不必要
NOSQL以Google’s BigTable 和 Amazon’s Dynamo為代表，開源版對應為HBase和Cassandra。
NOSQL往往是不保證強一致性的，而對於一些應用來講（例如金融服務），是需要強一致性和事務的，因此，如果它們基於NOSQL系統來開發的話，應用層需要些大量的邏輯來處理一致性和事務相關的問題。此時，業務需求是擁有可擴充套件性的基礎上，能夠支援強一致性。
因此，這裡有幾條路：
- 效能更好的單個伺服器來做資料庫伺服器
- 中介軟體層支援分散式事務
使用更好的單個伺服器的話，不滿足業務需求的可擴充套件性。
使用中介軟體的話，會有如下問題，例如：
- 中介軟體層往往是比較輕量級的，要實現一致性，必須在中介軟體層實現分散式事務，這點是非常困難的
- 中介軟體層本身的高可用很難保證
上面兩條路都不能很好的滿足應用的需求，因此，NewSQL出現了。
首先來看NEWSQL的定義：針對OLTP的讀寫，提供與NOSQL相同的可擴充套件性和效能，同時能支援滿足ACID特性的事務。即保持NOSQL的高可擴充套件和高效能，並且保持關係模型。
NEWSQL的優點：
- 輕鬆的獲得可擴充套件性
- 能夠使用關係模型和事務，應用邏輯會簡化很多
注意，此篇論文中的NEWSQL偏向於OLTP型資料庫，和一些OLAP型別的資料庫不同，OLAP資料庫更偏向於複雜的只讀查詢，查詢時間往往很長。
而NEWSQL資料庫的特性如下，針對其讀寫事務：
- 執行時間短
- 一般只查詢一小部分資料，通過使用索引來達到高效查詢的目的
- 一般執行相同的命令，使用不同的輸入引數
NewSQL的分類
分三大類：
- 從頭開始，使用新架構的系統
- 中介軟體
- DAAS，資料庫即服務
New Architectures
採用新架構的NewSQL有如下特點：
- 無共享儲存
- 多節點的併發控制
- 基於多副本做高可用和容災
- 流量控制
- 分散式查詢處理
優勢：
- 所有的部分都可以為分散式環境做優化，例如查詢優化，通訊協議優化。例如，所有的NEWSQL DBMS可以直接在節點間傳送查詢，而不是通過中心節點，例如中介軟體系統
- 本身負責資料分割槽，因此，可以把查詢傳送給有資料的分割槽，而不是把資料傳送給查詢。
- 擁有自身的儲存，可以指定更復雜的多副本的方式
缺點：
- 懂該資料庫的人少，缺少專業的運維
代表產品：Spanner，CockroachDB
Transparent Sharding Middleware
中介軟體負責的事情如下：
- 對查詢請求做路由
- 分散式事務的協調者
- 資料分佈，資料多副本控制，資料分割槽
往往在各個資料庫節點，需要裝代理與中介軟體溝通，負責如下事情：
- 在本地節點執行中間節點發來的情況，並且返回結果
優點：
- 應用通常不需要做變化
缺點：
- 各個節點還是執行傳統資料庫，即以磁碟為核心的資料庫，對現有的大記憶體，多核伺服器難以高效地利用
- 重複的查詢計劃和查詢優化，在中介軟體做一次，在各個DBMS做一次
備註：有研究表明，以磁碟為主要儲存的傳統DBMS，很難有效地利用非常多的核，以及更大的記憶體容量。
代表產品: MariaDB MaxScale, ScaleArc
Database-as-a-Service
特點：
- 使用者可以按需使用
- 資料庫本身可能使用雲產品，例如雲端儲存等，可以較容易的實現可擴充套件性
代表產品：
- Amazon Aurora
- ClearDB
NewSQL的技術挑戰有哪些？
Main Memory Storage
傳統資料庫都是以磁碟為儲存中心的架構，讀盤操作相對較慢，一般是記憶體中快取頁。
現在來講，記憶體較便宜，容量大，能儲存大量的資料。這些純記憶體操作帶來的好處是，讀取和寫入資料速度較快。
現有的大記憶體伺服器，對資料庫對記憶體的管理提出了新的要求，不再是像傳統資料庫那樣，只是用來做頁快取，可以採用更高效地記憶體管理方式。
Partitioning/Sharding
資料分割槽一般以某幾列做hash或者range分割槽。
特點：
- 資料庫需要能在多個分割槽執行SQL，並且合併資料結果的功能。
- 把同一個使用者的資料可以放在一起，即使是不同資料表的資料，可以減少通訊開銷。
- 可以線上的新增或者刪除機器。
- 可以線上的遷移或複製分割槽。
Concurrency Control
資料庫通過Concurrency Control來提供ACID中的Atomicity和Isolation。
Atomicity
分散式場景下，一般採用類2PC的協議，根據事務是否需要中心節點，分為以下兩類：
- 中心節點：單點，容量限制
- 非中心節點：需要時鐘的同步
關於時鐘同步，不同資料庫也有不同的做法，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全域性索引
區域性索引：
- 每個partition有一部分索引資料，每次修改索引，只需要修改一個節點，但查詢資料需要可能涉及多個節點
全域性索引：
- 每個partition都有完整的索引資料，每次修改索引，都需要使用分散式事務，修改所有包含此索引副本的節點，查詢資料只需要在一個節點
Replication
兩個需要考慮的點：
- 如何保證一致性：Paxos和2PC（跨Partition）
- 同步的方式：採用同步執行命令的方式，還是同步狀態的方式
Crash Recovery
如何最小化當機時間？
採用主備切換
如何優化新加機器恢復到同步的時間？
一般手段為做checkpoint
討論
可擴充套件性是NewSQL的一個非常重要的特點，對於中介軟體的方式，其上需要存路由資訊，其本身的可擴充套件性比較難以解決，個人認為，其不應該算入NewSQL。
NewSQL的技術挑戰除了上述提到的之外，還有如何實現多租戶架構及租戶之間的隔離，負載均衡等等問題。
從整篇論文中描述的內容可以看出，NewSQL中並沒有開拓性的理論技術的創新，更多的是架構的創新，以及把現有的技術如何更好地適用於當今的伺服器，適用於當前的分散式架構，使得這些技術有機的結合起來，形成高效率的整體，實現NewSQL高可用，可擴充套件，強一致性等需求。
PS:
本部落格更新會在第一時間推送到微信公眾號，歡迎大家關注。
