我們對比了5款數據庫,告訴你NewSQL的獨到之處

導讀:NewSQL 是一種新方式關係數據庫,意在整合 RDBMS 所提供的 ACID 事務特性,及 NoSQL 提供的橫向可擴展性。本文通過對 VoltDB、TiDB、Cosmos DB、Citus、Vitess 等 NewSQL 數據庫的介紹,給出了 NewSQL 的獨到考慮。

作者:Gokhan Simsek

譯者:蓋磊

來源:AI 前線(ID:ai-front)

 

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

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

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

 

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

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

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

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

隨着數據規模的增長,以及基於互聯網的實時交互無處不在,用戶對數據庫的基本需求呈現出兩個主要的類別,即 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 解決方案提供了那些獨到特性?

01 一致性

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

02 內存數據庫

傳統 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 訪談的播客。

 

03 HTAP 特性

前文曾提及,很多 NewSQL 數據庫是完全重新設計的。正因爲重新設計,一些項目希望實現統一支持事務處理和工作負載分析的數據庫。HTAP(混合事務 / 分析處理,Hybrid Transactional/Analytical Processing)一詞由 Gartner 提出。支持 HTAP 功能的數據庫提供對高級實時分析,進而支持實時業務決策和智能事務處理。

VoltDB 也提供 HTAP 能力,它更側重於事務負載。其他主流 HTAP 數據庫還包括 TiDB 和 Google 的 Spanner。

 

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

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

2. 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 易於開發人員使用,對性能、可用性和一致性提供了全面的保證。

04 增強 RDBMS

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

1. Citus

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

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

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

 

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

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

2. 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 對併發的良好支持,它支持對數千連接的處理。

05 結束語

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

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

查看英文原文:

What Is New About NewSQL?

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章