剑网3指尖江湖职业推荐 www.1468054.com

圖0:對比五款數據庫,告訴你 NewSQL 的獨到之處

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

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

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

圖1:對比五款數據庫,告訴你 NewSQL 的獨到之處

數據庫的推出,源自于上世紀六十年代分離代碼與數據的需求。數據庫的最初設計基于如下考慮:

  1. 數據庫的查詢用戶數量有限。
  2. 查詢類型不受限,即開發人員可以給出任何所需類型的查詢。
  3. 硬件的價格昂貴。

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

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

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

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

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

在大多數 Web 站點上,任一時刻都可能會有成百上千的用戶并發執行有效的查詢??悸塹秸庋墓婺?,系統必須具備高可用性,因為每宕機一分鐘,都可能會導致企業損失數千甚至上百萬美元。

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

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

圖2:對比五款數據庫,告訴你 NewSQL 的獨到之處

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 HuggRyan Betts訪談的播客。

圖3:對比五款數據庫,告訴你 NewSQL 的獨到之處

HTAP 特性

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

圖4:對比五款數據庫,告訴你 NewSQL 的獨到之處

TiDB

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

圖5:對比五款數據庫,告訴你 NewSQL 的獨到之處

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 的代價,給出一種同時支持分析和事務需求的統一解決方案。

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

Cosmos DB

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

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

就全球分布而言,Cosmos DB 在位于全球的多個數據中心保存數據備份,確保了可靠性和高可用性??⑷嗽笨梢源唇ū阜?,并通過幾個基本的 API 調用實現數據的橫向擴展。

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

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

圖6:對比五款數據庫,告訴你 NewSQL 的獨到之處

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

增強 RDBMS

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

Citus

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

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

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

圖7:對比五款數據庫,告訴你 NewSQL 的獨到之處

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

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

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。

圖8:對比五款數據庫,告訴你 NewSQL 的獨到之處

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

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

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

結束語

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

作者簡介

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

余下全文(1/3)
分享這篇文章:

請關注我們:

發表評論

電子郵件地址不會被公開。 必填項已用*標注