NewSQL：雲時代的完美資料庫？

作者 | Gokhan Simsek

譯者 | 蓋磊

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

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

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

資料庫的推出，源自於上世紀六十年代分離代碼與數據的需求。資料庫的最初設計基於如下考慮：

資料庫的查詢用戶數量有限。

查詢類型不受限，即開發人員可以給出任何所需類型的查詢。

硬體的價格昂貴。

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

下面快進數十年進入當前的互聯網和雲時代，資料庫的需求已大為不同。數據的規模是海量的，而商業硬體比起上世紀要更為便宜。

隨著數據規模的增長，以及基於互聯網的實時交互無處不在，用戶對資料庫的基本需求呈現出兩個主要的類別，即 OLAP（在線分析處理）和 OLTP（在線交易處理）。

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

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

在大多數 Web 站點上，任一時刻都可能會有成百上千的用戶並發執行有效的查詢。考慮到這樣的規模，系統必須具備高可用性，因為每宕機一分鐘，都可能會導致企業損失數千甚至 上百萬美元。

Web 站點上用戶提交的查詢是預定義的，因為用戶無法訪問資料庫終端並執行任意查詢。查詢是存在於應用邏輯中的，這使得我們可以針對高性能做優化。

可擴展性是這一新資料庫生態系統中的一個重要度量，而高可用性則對企業的盈利至關重要。NoSQL 資料庫給出了一種易於實現可擴展性和更好性能的解決方案，解決了 CAP 理論中的 A（可用性）和 P（分區容錯性）上的設計考慮。但這意味著，在很多 NoSQL 設計中實現為 最終一致性，擯棄了 RDBMS 提供的強一致性及事務的 ACID 屬性。

NoSQL 資料庫使用了不同於關係模型的模型，例如鍵值模型、文檔模型、寬列模型和圖模型等。採用這些模型的 NoSQL 資料庫並不提供規範化，本身在設計上是無模式的。大多數 NoSQL 資料庫支持自動分區，無需開發人員干預即可輕鬆實現水平擴展。

NoSQL 適用於可接受最終一致性的部分應用，例如社交媒體。用戶並不關注看到的是否為不一致的資料庫視圖，並且考慮到數據的狀態更新、發推文等，強一致性也並非必要的。但是，NoSQL 資料庫不宜用於對一致性要求高的系統，例如電子商務平台。

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

傳統的 RDBMS 架構從一開始設計時並未考慮分散式系統，而是在分散式需求出現後，才考慮在最初的設計之添加支持分散式的設計。由於 RDBMS 實現了規範化模式，而非 NoSQL 那樣的聚合表單，因此 RDBMS 中必須引入一些複雜的概念，才能在支持可擴展的同時保持一致性需求。由此，為支持 RDBMS 中的橫向擴展，人們提出了手動分片和主從架構。

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

NewSQL 資料庫為雲時代而生，因此它從一開始就考慮了分散式架構。

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

一致性

相對於可用性而言，NewSQL 更重視一致性，即側重 CAP 中的 C 和 P。很多 NewSQL 資料庫為提供強一致性而犧牲了部分可用性。這些資料庫為達成分散式一致性，在全局系統或本地分區層面使用了 Paxos 或 Raft 共識協議。MemSQL 等一些解決方案還提供了一致性和可用性之間的權衡調優，支持不同用例的各種配置。

內存資料庫

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

內存解決方案提供了更好的性能提升，因為內存的使用消除或簡化了 緩存管理 和重度並發系統。鑒於內存中保持了全部數據（或是大部分數據），因此完全沒有必要做緩存管理。對於並發而言，不同的實現有不同的解決方案，例如序列化等。

那麼如何解決持久性問題？RAM 本身是非持久介質。一旦掉電，需要持久化的數據就會丟失。內存資料庫採用了多種方式解決該問題。常用方法包括組合使用基於磁碟的非頻繁備份、保存狀態的日誌以實現可恢復性，以及對關鍵數據使用非易失 RAM 介質。

下面給出內存資料庫的兩個重要例子，VoltDB 和 MemSQL。

VoltDB

VoltDB 是一種符合 ACID 特性的內存關係資料庫。VoltDB 的架構基於 Michael Stonebraker 等提出的 H-Store，一種設計用於 OLTP 工作負載的內存資料庫。

VoltDB 關注快速數據，目的是服務於那些必須對大流量數據做快速處理的特定應用，例如貿易應用、在線遊戲、物聯網感測器等 應用場景。為實現高性能，VoltDB 基於 OLTP 原則做了全新的設計。

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

ACID 原則中的持久性，對內存資料庫是一個重要問題。VoltDB 採用多種技術實現持久性，包括 快照、命令日誌、K-safety 機制和資料庫複製等。這些方法確保 VoltDB 實現數據冗餘，進而支持數據持久化。

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

HTAP 特性

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

TiDB

TiDB 是一款來自中國的開源解決方案，它給出了一種兼容 MySQL 的 HTAP 資料庫，支持強一致性，並且分散式可擴展。TiDB 實現為分層架構，其中 TiDB 伺服器作為無狀態計算層出於頂層。底層存儲層實現為支持事務的鍵值資料庫，稱為 TiKV。TiKV 的設計受到了 Google Spanner 的啟發。

TiDB 層實現監聽 SQL 查詢、解析查詢並創建執行計劃。查詢進而將按需切分為各個子查詢，並發送給相應的 TiKV 存儲。鑒於 TiDB 層是無狀態的，因此該層易於實現擴展。

TiKV 層實現了底層存儲層，它是一種使用 RocksDB 作為物理存儲的鍵值資料庫。TikV 按區域組織數據，各個區域將被存儲和複製。為基於複製模式實現持久性和高可用性，TiKV 使用 Raft 共識演算法提供強一致性。TiKV 的分布本質提供了對分散式查詢的支持。

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

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

Cosmos DB

微軟的 Azure Cosmos DB 提供了多種可調優特性，是一種高度靈活的解決方案，可通過調整適合多類用例。我們認為 Cosmos DB 也是 NewSQL 資料庫。

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

就全球分布而言，Cosmos DB 在位於全球的多個數據中心保存數據備份，確保了可靠性和高可用性。開發人員可以創建備份，並通過幾個基本的 API 調用實現數據的橫向擴展。

Cosmos DB 在設計上考慮了降低資料庫管理的代價。它無需開發人員操心索引或模式管理，自動維護索引以確保性能。

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

作為微軟這樣的技術和雲巨頭所提供的產品，Cosmos DB 易於開發人員使用，對性能、可用性和一致性提供了全面的保證。

增強 RDBMS

NewSQL 也可以通過增強現有的 RDBMS 實現擴展的功能，無需完全重新設計資料庫。這樣的解決方案實現在經實戰驗證的 SQL 資料庫之上，增強了現有資料庫的功能。該理念對於那些現有系統運行良好而不願意遷移到新資料庫解決方案的大型企業是非常有用的。

Citus

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

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

在 Citus 集群中，資料庫表是分散式的。資料庫表被水平分區到不同的工作節點上，在用戶看來與常規資料庫表並無二致。Citus 使用一種維護了資料庫表元數據的協調器掌握 PostgreSQL 節點的工作情況，處理查詢，並將查詢並行化到適當的表分區。

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

Vitess

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

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

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

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

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

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

Vitess 用 Go 語言實現。利用 Go 對並發的良好支持，它支持對數千連接的處理。

要了解 Vitess 的發展歷程、架構和用例，可收聽 我們就 Vitess 對 Sugu Sougoumarane 深度訪談的播客。

結束語

NewSQL 生態系統正在持續增長和演進。我們無法給出一個能描述全部 NewSQL 資料庫的通用定義，或是提出一些通用的特徵。但是在 NewSQL 概念下提出的多種資料庫設計，為開發人員提供了針對不同用例的多種選項。人們不再寄希望於給出適用於所有用例的單一架構，NewSQL 推動了創新和專業資料庫設計的發展。

作者簡介

Gokhan 是一名計算機科學研究生，目前就讀於埃因霍溫技術大學數據科學專業。他的興趣包括大數據、NLP 和機器學習。

英文原文：

https://softwareengineeringdaily.com/2019/02/24/what-is-new-about-newsql/

點個在看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！