對大多數(shù)開發(fā)人員而言，SQL 以及 MySQL、PostgreSQL 等關系數(shù)據(jù)庫管理系統(tǒng)（即 RDBMS）并不陌生。RDBMS 的基本架構原則已歷經(jīng)了數(shù)十年的發(fā)展。而 MongoDB、Cassandra 等 NoSQL 解決方案，則是在本世紀初為滿足數(shù)據(jù)分布可擴展的需求而提出的。

但是最近幾年我們看到，出現(xiàn)了一個稱為 NewSQL 的新方向。

NewSQL 是一種新方式關系數(shù)據(jù)庫，意在整合 RDBMS 所提供的 ACID 事務特性（即原子性、一致性、隔離性和可持久性），以及 NoSQL 提供的橫向可擴展性。聽上去 NewSQL 應該汲取了這兩個方向各自的長處，像是一種完美的解決方案。那它為什么時至今日方得以推出呢？

數(shù)據(jù)庫的推出，源自于上世紀六十年代分離代碼與數(shù)據(jù)的需求。數(shù)據(jù)庫的最初設計基于如下考慮：

1. 數(shù)據(jù)庫的查詢用戶數(shù)量有限。

2. 查詢類型不受限，即開發(fā)人員可以給出任何所需類型的查詢。

3. 硬件的價格昂貴。

在當時，開發(fā)人員需要通過終端輸入交互式查詢。鑒于開發(fā)人員是唯一能訪問數(shù)據(jù)庫的用戶，上面的考慮是有意義，且有價值的。正確性和一致性曾是戶最為看重的兩個度量，但是時至今日人們更看重的是性能和可用性。由此，縱向擴展可用于解決不斷增加的數(shù)據(jù)需求，以及考慮在數(shù)據(jù)庫遷移或恢復時需移動數(shù)據(jù)的情況下的可承受宕機時間。

下面快進數(shù)十年進入當前的互聯(lián)網(wǎng)和云時代，數(shù)據(jù)庫的需求已大為不同。數(shù)據(jù)的規(guī)模是海量的，而商業(yè)硬件比起上世紀要更為便宜。

隨著數(shù)據(jù)規(guī)模的增長，以及基于互聯(lián)網(wǎng)的實時交互無處不在，用戶對數(shù)據(jù)庫的基本需求呈現(xiàn)出兩個主要的類別，即 OLAP（在線分析處理）和 OLTP（在線交易處理）。

OLAP 數(shù)據(jù)庫通常稱為數(shù)據(jù)倉庫。它們用于存儲供商業(yè)智能業(yè)務統(tǒng)計和分析歷史記錄。OLAP 數(shù)據(jù)庫側(cè)重于只讀工作負載，其中包括用于批處理的即席查詢。OLAP 數(shù)據(jù)庫的查詢用戶數(shù)相對較少，通常情況下只有企業(yè)員工可以訪問歷史記錄。

OLTP 數(shù)據(jù)庫用于高度并發(fā)的事務數(shù)據(jù)處理場景，該場景的特點是實時用戶提交預定義的短時查詢。事務處理的一個簡單例子，就是普通用戶在電子商務網(wǎng)站上搜索并購買商品。相對于 OLAP 用戶，盡管 OLTP 用戶訪問的數(shù)據(jù)集規(guī)模很小，但是用戶的數(shù)量要龐大很多，并且查詢中可以包括讀操作和寫操作。OLTP 數(shù)據(jù)庫主要考慮的是高可用性、并發(fā)性和性能。

在大多數(shù) Web 站點上，任一時刻都可能會有成百上千的用戶并發(fā)執(zhí)行有效的查詢。考慮到這樣的規(guī)模，系統(tǒng)必須具備高可用性，因為每宕機一分鐘，都可能會導致企業(yè)損失數(shù)千甚至 上百萬美元。

Web 站點上用戶提交的查詢是預定義的，因為用戶無法訪問數(shù)據(jù)庫終端并執(zhí)行任意查詢。查詢是存在于應用邏輯中的，這使得我們可以針對高性能做優(yōu)化。

可擴展性是這一新數(shù)據(jù)庫生態(tài)系統(tǒng)中的一個重要度量，而高可用性則對企業(yè)的盈利至關重要。NoSQL 數(shù)據(jù)庫給出了一種易于實現(xiàn)可擴展性和更好性能的解決方案，解決了 CAP 理論中的 A（可用性）和 P（分區(qū)容錯性）上的設計考慮。但這意味著，在很多 NoSQL 設計中實現(xiàn)為 最終一致性，擯棄了 RDBMS 提供的強一致性及事務的 ACID 屬性。

NoSQL 數(shù)據(jù)庫使用了不同于關系模型的模型，例如鍵值模型、文檔模型、寬列模型和圖模型等。采用這些模型的 NoSQL 數(shù)據(jù)庫并不提供規(guī)范化，本身在設計上是無模式的。大多數(shù) NoSQL 數(shù)據(jù)庫支持自動分區(qū)，無需開發(fā)人員干預即可輕松實現(xiàn)水平擴展。

NoSQL 適用于可接受最終一致性的部分應用，例如社交媒體。用戶并不關注看到的是否為不一致的數(shù)據(jù)庫視圖，并且考慮到數(shù)據(jù)的狀態(tài)更新、發(fā)推文等，強一致性也并非必要的。但是，NoSQL 數(shù)據(jù)庫不宜用于對一致性要求高的系統(tǒng)，例如電子商務平臺。

NewSQL 系統(tǒng)的提出，正是為了滿足整合 NoSQL 和 RDBMS 特性的需求。其中，NoSQL 提供了可擴展性和高可用性，傳統(tǒng) RDBMS 提供了關系模型、ACID 事務支持和 SQL。用戶已不再考慮一招能解決所有問題（one-size-fits-all）的方案，逐漸轉(zhuǎn)向針對 OLTP 等不同工作負載給出特定數(shù)據(jù)庫。大多數(shù) NewSQL 數(shù)據(jù)庫做了全新的設計，或是主要聚焦于 OLTP，或是采用了 OLTP/OLAP 的混合架構載的全新設計。

傳統(tǒng)的 RDBMS 架構從一開始設計時并未考慮分布式系統(tǒng)，而是在分布式需求出現(xiàn)后，才考慮在最初的設計之添加支持分布式的設計。由于 RDBMS 實現(xiàn)了規(guī)范化模式，而非 NoSQL 那樣的聚合表單，因此 RDBMS 中必須引入一些復雜的概念，才能在支持可擴展的同時保持一致性需求。由此，為支持 RDBMS 中的橫向擴展，人們提出了手動分片和主從架構。

但是，RDBMS 為實現(xiàn)橫向擴展而在性能上做出了很大讓步。這是因為連接運算中需要在各個節(jié)點間移動數(shù)據(jù)以實現(xiàn)聚合，運算實現(xiàn)代價增大。另外，數(shù)據(jù)維護開銷變得更為耗時。為保持 RDBMS 的性能，一些企業(yè)推出了復雜的系統(tǒng)和產(chǎn)品。但是當前，人們依然并不認為傳統(tǒng) RDBMS 本身支持可擴展。

NewSQL 數(shù)據(jù)庫為云時代而生，因此它從一開始就考慮了分布式架構。

那么 NewSQL 解決方案提供了那些獨到特性？

相對于可用性而言，NewSQL 更重視一致性，即側(cè)重 CAP 中的 C 和 P。很多 NewSQL 數(shù)據(jù)庫為提供強一致性而犧牲了部分可用性。這些數(shù)據(jù)庫為達成分布式一致性，在全局系統(tǒng)或本地分區(qū)層面使用了 Paxos 或 Raft 共識協(xié)議。MemSQL 等一些解決方案還提供了一致性和可用性之間的權衡調(diào)優(yōu)，支持不同用例的各種配置。

傳統(tǒng) RDBMS 依賴二級存儲（即磁盤）作為數(shù)據(jù)存儲的介質(zhì)。常用的二級存儲包括 SSD 或 HDD。鑒于 OLTP 工作負載可將歷史數(shù)據(jù)歸檔到數(shù)據(jù)倉庫中，因此并不需要大量的數(shù)據(jù)，只需要最新的數(shù)據(jù)。一些 NewSQL 解決方案使用內(nèi)存（RAM）作為存儲介質(zhì)。內(nèi)存訪問要比磁盤訪問快很多，具體而言，可比 SSD 快百倍，比 HDD 快萬倍。

內(nèi)存解決方案提供了更好的性能提升，因為內(nèi)存的使用消除或簡化了 緩存管理 和重度并發(fā)系統(tǒng)。鑒于內(nèi)存中保持了全部數(shù)據(jù)（或是大部分數(shù)據(jù)），因此完全沒有必要做緩存管理。對于并發(fā)而言，不同的實現(xiàn)有不同的解決方案，例如序列化等。

那么如何解決持久性問題？RAM 本身是非持久介質(zhì)。一旦掉電，需要持久化的數(shù)據(jù)就會丟失。內(nèi)存數(shù)據(jù)庫采用了多種方式解決該問題。常用方法包括組合使用基于磁盤的非頻繁備份、保存狀態(tài)的日志以實現(xiàn)可恢復性，以及對關鍵數(shù)據(jù)使用非易失 RAM 介質(zhì)。

下面給出內(nèi)存數(shù)據(jù)庫的兩個重要例子，VoltDB 和 MemSQL。

VoltDB 是一種符合 ACID 特性的內(nèi)存關系數(shù)據(jù)庫。VoltDB 的架構基于 Michael Stonebraker 等提出的 H-Store，一種設計用于 OLTP 工作負載的內(nèi)存數(shù)據(jù)庫。

VoltDB 關注快速數(shù)據(jù)，目的是服務于那些必須對大流量數(shù)據(jù)做快速處理的特定應用，例如貿(mào)易應用、在線游戲、物聯(lián)網(wǎng)傳感器等 應用場景。為實現(xiàn)高性能，VoltDB 基于 OLTP 原則做了全新的設計。

VoltDB 明確以支持存儲過程為指導思想，讓存儲過程更接近于數(shù)據(jù)，因此 VoltDB 支持執(zhí)行序列化事務。為實現(xiàn)序列化事務處理，一個事務會被切分為一些原子事務，然后做序列化，并在隊列中依次執(zhí)行。序列化事務模式消除了管理并發(fā)的開銷，進而提高了性能。VoltDB 還支持即席查詢，性能優(yōu)化可受益于存儲過程。這非常適合 OLTP 工作負載，因為終端用戶并不能執(zhí)行即席查詢。

ACID 原則中的持久性，對內(nèi)存數(shù)據(jù)庫是一個重要問題。VoltDB 采用多種技術實現(xiàn)持久性，包括 快照、命令日志、K-safety 機制和數(shù)據(jù)庫復制等。這些方法確保 VoltDB 實現(xiàn)數(shù)據(jù)冗余，進而支持數(shù)據(jù)持久化。

如需進一步了解 VoltDB 及其架構，可查看我們前期對 John Hugg 和 Ryan Betts 訪談的播客。

前文曾提及，很多 NewSQL 數(shù)據(jù)庫是完全重新設計的。正因為重新設計，一些項目希望實現(xiàn)統(tǒng)一支持事務處理和工作負載分析的數(shù)據(jù)庫。HTAP（混合事務 / 分析處理，Hybrid Transactional/Analytical Processing）一詞 由 Gartner 提出。支持 HTAP 功能的數(shù)據(jù)庫提供對高級實時分析，進而支持實時業(yè)務決策和智能事務處理。VoltDB 也提供 HTAP 能力，它更側(cè)重于事務負載。其他主流 HTAP 數(shù)據(jù)庫還包括 TiDB 和 Google 的 Spanner。

TiDB 是一款來自中國的開源解決方案，它給出了一種兼容 MySQL 的 HTAP 數(shù)據(jù)庫，支持強一致性，并且分布式可擴展。TiDB 實現(xiàn)為分層架構，其中 TiDB 服務器作為無狀態(tài)計算層出于頂層。底層存儲層實現(xiàn)為支持事務的鍵值數(shù)據(jù)庫，稱為 TiKV。TiKV 的設計受到了 Google Spanner 的啟發(fā)。

TiDB 層實現(xiàn)監(jiān)聽 SQL 查詢、解析查詢并創(chuàng)建執(zhí)行計劃。查詢進而將按需切分為各個子查詢，并發(fā)送給相應的 TiKV 存儲。鑒于 TiDB 層是無狀態(tài)的，因此該層易于實現(xiàn)擴展。

TiKV 層實現(xiàn)了底層存儲層，它是一種使用 RocksDB 作為物理存儲的鍵值數(shù)據(jù)庫。TikV 按區(qū)域組織數(shù)據(jù)，各個區(qū)域?qū)⒈淮鎯蛷椭?。為基于復制模式實現(xiàn)持久性和高可用性，TiKV 使用 Raft 共識算法提供強一致性。TiKV 的分布本質(zhì)提供了對分布式查詢的支持。

這一計算層與存儲層的分離解耦架構，使得 TiDB 可同時提供對 OLTP 和 OLAP 強大支持。鑒于 TiDB 同時支持處理 OLTP 和基本 OLAP 負載，TiSpark 作為一種在 TiKV 上直接運行 Spark SQL 的 OLAP 解決方案，可輕易實現(xiàn)基于 TiDB/TiKV 架構的運行。TiDB 本身就具有代價優(yōu)化器和分布式執(zhí)行器，可處理 80% 的即席 OLAP 查詢。

TiSpark 針對復雜 OLAP 查詢做了一些優(yōu)化。和 TiDB 層類似，TiSpark 也是一種無狀態(tài)計算層，并與 TiKV 層交互。TiSpark 在設計上就是通過與 Spark SQL 的交互去處理復雜 OLAP 查詢。因此，同時部署 TiDB 和 TiSpark 可消除 ETL 的代價，給出一種同時支持分析和事務需求的統(tǒng)一解決方案。

要了解 TiDB 及其架構的更多信息，可查看 我們近期對 Kevin Xu 關于 TiDB 的訪談。要進一步了解支持 TiKV/TiDB 的數(shù)據(jù)物理存儲 RockDB，可查看 我們對 Dhruba Borthakur 和 Igor Canadi 關于 RocksDB 的訪談。要深入了解 TiKV，可查看 我們對中國開源項目的報道。

微軟的 Azure Cosmos DB 提供了多種可調(diào)優(yōu)特性，是一種高度靈活的解決方案，可通過調(diào)整適合多類用例。我們認為 Cosmos DB 也是 NewSQL 數(shù)據(jù)庫。

Cosmos DB 是一種分布于全球的 多模型數(shù)據(jù)庫 服務。作為多模型服務，它的底層存儲模型支持鍵值、列存儲、文檔和圖數(shù)據(jù)庫，并支持通過 SQL 和 NoSQL API 提供數(shù)據(jù)。

就全球分布而言，Cosmos DB 在位于全球的多個數(shù)據(jù)中心保存數(shù)據(jù)備份，確保了可靠性和高可用性。開發(fā)人員可以創(chuàng)建備份，并通過幾個基本的 API 調(diào)用實現(xiàn)數(shù)據(jù)的橫向擴展。

Cosmos DB 在設計上考慮了降低數(shù)據(jù)庫管理的代價。它無需開發(fā)人員操心索引或模式管理，自動維護索引以確保性能。

Cosmos DB 提供 多個一致性層級，支持開發(fā)人員在確定所需的適用 SLA 上做出權衡。除了兩種極端的強一致性情況和最終一致性之外，Cosmos DB 還一并提供了另外五個良好定義的一致性層級。每個一致性層級提供單獨的 SLA，確保達到特定的可用和性能層級。

作為微軟這樣的技術和云巨頭所提供的產(chǎn)品，Cosmos DB 易于開發(fā)人員使用，對性能、可用性和一致性提供了全面的保證。

NewSQL 也可以通過增強現(xiàn)有的 RDBMS 實現(xiàn)擴展的功能，無需完全重新設計數(shù)據(jù)庫。這樣的解決方案實現(xiàn)在經(jīng)實戰(zhàn)驗證的 SQL 數(shù)據(jù)庫之上，增強了現(xiàn)有數(shù)據(jù)庫的功能。該理念對于那些現(xiàn)有系統(tǒng)運行良好而不愿意遷移到新數(shù)據(jù)庫解決方案的大型企業(yè)是非常有用的。

一個很好的例子，就是構建于 PostgreSQL 上的 Citus。

Citus 由近期被 微軟并購 的 Citus Data 開發(fā)維護。它是一款開源 PostgreSQL 擴展，通過透明分布式表和查詢支持橫向擴展，進而支持分布式 PostgreSQL。

在 Citus 集群中，數(shù)據(jù)庫表是分布式的。數(shù)據(jù)庫表被水平分區(qū)到不同的工作節(jié)點上，在用戶看來與常規(guī)數(shù)據(jù)庫表并無二致。Citus 使用一種維護了數(shù)據(jù)庫表元數(shù)據(jù)的協(xié)調(diào)器掌握 PostgreSQL 節(jié)點的工作情況，處理查詢，并將查詢并行化到適當?shù)谋矸謪^(qū)。

Citus 為 PostgreSQL 添加了查詢路由、分布式表、分布式事務和存儲過程等特性，管理了大量的底層細節(jié)，進而實現(xiàn)了水平可擴展、高性能的 PostgreSQL。

要了解 Cirus 的更多細節(jié)，可查看 我們就 PostgreSQL 擴展對 Ozgun Erdogan 的訪談，以及 就 Postgres 分片對 Marco Slot 的訪談。

相對于 Citus 是基于 PostgreSQL 構建的，Vitess 在設計上考慮對 MySQL 做出改進，滿足 MySQL 適用于云時代的需求。

Vitess 最初是由 Youtube 在 2011 年為適應自身擴展需求而構建的。隨著用戶和數(shù)據(jù)的增長，Youtube 必須要進行水平擴展和分片，由此創(chuàng)建了 Vitess 解決透明擴展的問題?，F(xiàn)在 Vitess 已經(jīng)開源，由 CNCF 管理。Vitess 被認可為是一種云原生技術，提供了 多處 MySQL 改進。

首要改進就是引入了多種分片模式。用戶可以創(chuàng)建自己的分片模式，Vitess 負責依模式組織分片和數(shù)據(jù)。Vitess 也支持自動分片，無需手工運行代碼，并支持只讀宕機時間最小化的實時重分片。

分片是通過 V 索引（Vindex）和鍵空間（keyspace）技術實現(xiàn)的。其中，主 V 索引（Primary Vindex）類似于數(shù)據(jù)庫索引模式中的主鍵索引。用戶可以指定需要建立主 V 索引的屬性，以及基于 V 索引的數(shù)據(jù)分片數(shù)量。在對數(shù)據(jù)庫分片后，基于鍵空間的查詢可被導向到相應的分片。

Vitess 的架構 使用 vtgate 提供負載均衡和查詢路由。vtgate 是一種無狀態(tài)層，可輕易地上下擴展。vtgate 將查詢路由至為分片提供代理的 vtable，并返回聚合結(jié)果給 vtgates。

當部署到 Kubernetes 等集群編排工具上時，Vitess 依然提供上述優(yōu)點。由于 vtgates 是一種無狀態(tài)代理，因此適合于部署到容器集群上。這時 Vitess 使用 lockserver 或 etcd 作為元數(shù)據(jù)存儲，處理模式定義等管理工作。

Vitess 用 Go 語言實現(xiàn)。利用 Go 對并發(fā)的良好支持，它支持對數(shù)千連接的處理。

NewSQL 生態(tài)系統(tǒng)正在持續(xù)增長和演進。我們無法給出一個能描述全部 NewSQL 數(shù)據(jù)庫的通用定義，或是提出一些通用的特征。但是在 NewSQL 概念下提出的多種數(shù)據(jù)庫設計，為開發(fā)人員提供了針對不同用例的多種選項。人們不再寄希望于給出適用于所有用例的單一架構，NewSQL 推動了創(chuàng)新和專業(yè)數(shù)據(jù)庫設計的發(fā)展。