Categories
程式開發

HTAP會成為數據庫的未來嗎?


在訪問量和數據量急劇膨脹的今天,關係型數據庫已經難以支撐龐大復雜的系統規模。在此背景下,備受關注的數據庫新理念HTAP,會是一條“正確”的路嗎?

為什麼是HTAP?

在互聯網浪潮出現之前,企業的數據量普遍不大,特別是核心的業務數據,通常一個單機的數據庫就可以保存。那時候的存儲並不需要復雜的架構,所有的線上請求 (OLTP, Online Transactional Processing) 和後台分析 (OLAP, Online Analytical Processing) 都跑在同一個數據庫實例上。

隨著互聯網的發展,企業的業務數據量不斷增多,單機數據庫的容量限制制約了其在海量數據場景下的使用。因此在實際應用中,為了面對各種需求,OLTP、OLAP在技術上分道揚鑣,在很多企業架構中,這兩類任務處理由不同團隊完成。當物聯網大數據應用不斷深入,具有海量的傳感器數據要求實時更新和查詢,對數據庫的性能要求也越來越高,此時,新的問題隨之出現:

1、OLAP 和 OLTP 系統間通常會有幾分鐘甚至幾小時的時延,OLAP 數據庫和 OLTP 數據庫之間的一致性無法保證,難以滿足對分析的實時性要求很高的業務場景。

2、企業需要維護不同的數據庫以便支持兩類不同的任務,管理和維護成本高。

因此,能夠統一支持事務處理和工作負載分析的數據庫成為眾多企業的需求。在此背景下,由Gartner提出的 HTAP(混合事務 / 分析處理,Hybrid Transactional/Analytical Processing)成為希望。基於創新的計算存儲框架,HTAP數據庫能夠在一份數據上同時支撐業務系統運行和OLAP場景,避免在傳統架構中,在線與離線數據庫之間大量的數據交互。此外,HTAP基於分佈式架構,支持彈性擴容,可按需擴展吞吐或存儲,輕鬆應對高並發、海量數據場景。

目前,實現HTAP的數據庫不多,主要有PingCAP的TiDB、阿里雲的HybridDB for MySQL、百度的 BaikalDB 等。其中,TiDB是國內首家開源的HTAP分佈式數據庫,接下來,本文將以此例進行深入分析。

一、TiDB基本架構解析

TiDB的理論基礎來源於2013 年 Google 發布的 Spanner / F1 論文 ,以及2014 年 Stanford 工業級分佈式一致性協議算法 Raft 論文。在架構上,TiDB 將計算和存儲層進行高度的抽象和分離,對混合負載的場景通過 IO 優先級隊列、智能副本調度、行列混合存儲等技術,使HTAP變為可能。

參考 Google Spanner / F1 的設計,TiDB整體架構分為上下兩層: 負責計算的TiDB Server 和 負責存儲的TiKV Server,二者由集群管理模塊 PD Server 調度和管理。

HTAP會成為數據庫的未來嗎? 1

TiDB基本架構

根據PingCAP 高級技術總監、CMC 成員、華南區總經理姚維最近的《TiDB性能設計及鯤鵬平台優化實踐》演講,TiDB Server對應於Google F1, 是一層無狀態的SQL Layer ,其本身並不存儲數據,只負責計算。在接收到SQL請求後,該計算層會通過 PD Server 找到存儲計算所需數據的 TiKV 地址,然後與 TiKV Server交互獲取數據,最終返回結果。在水平擴展方面,隨著業務的增長,用戶可以簡單地添加 TiDB Server 節點,提高數據庫整體的處理能力和吞吐。

作為整個集群的管理模塊,PD(Placement Driver ) 主要工作有三類:一是存儲集群的元信息;二是對TiKV 集群進行調度和負載均衡,如數據的遷移、Raft group leader 的遷移等;三是分配全局唯一且遞增的事務ID。

TiKV Server是一個分佈式 Key Value 數據庫,對應於Google Spanner ,支持彈性水平擴展。不同於 HBase 或者 BigTable 那樣依賴底層的分佈式文件系統,TiKV Server在性能和靈活性上更好,這對於在線業務來說非常重要。隨著數據量的增長,用戶可以部署更多的 TiKV Server 節點解決數據 Scale 的問題。 PD 模塊則會在 TiKV 節點之間以 Region 為單位做調度,將部分數據遷移到新加的節點上。

總體來看,TiDB 具備如下核心特性:

  • 水平線性擴展
  • 強一致分佈式事務
  • 故障自恢復(auto -failover)的金融級高可用(非主從)
  • 真正跨數據中心多活

據了解,TiDB 對業務沒有任何侵入性,能夠替換傳統的數據庫中間件、數據庫分庫分錶等 Sharding 方案。同時它也讓開發運維人員不用關注數據庫 Scale 的細節問題,專注於業務開發,大幅度提升研發生產力。目前,TiDB已被近千家不同行業的企業引入到實際生產環境中,涉及互聯網、遊戲、金融、政府、電信、製造業等多個領域,並得到成功應用。

二、“TiDB 在4.0版本上真正實現了 HTAP 功能”

姚維在接受InfoQ採訪時表示:“2020年是PingCAP的里程碑年。”在今年的5月底、6月初,PingCAP將發布TiDB 重要的4.0版本。該版本將會在性能、易用性、易管理性等方面有明顯的增強, 事務處理能力方面也有大幅度提高。

除此之外,在4.0版本上真正實現了HTAP功能。簡單來說,用戶可以在一套數據庫上同時運行截然不同的計算負載,即聯機交易的計算負載和海量數據的實時分析。此前,在數據庫領域,這兩種計算還不能完全放在一起,因為它們對資源的消耗、對計算本身的性能要求,以及對數據的處理方式是完全矛盾的。

姚維表示:“我們經過兩年多的內部開發,終於將OLAP和OLTP真正放在同一套TiDB集群上,讓TiDB可以同時支持聯機交易和海量的數據分析。並且這兩種計算在內部轉換的過程對用戶是透明的。”通過底層數據同步及行列透明轉換的技術,TiDB 將TiKV 面向聯機交易的行存式引擎與TiFlash 面向實時分析場景的列存引擎,轉為真正的行列混合數據架構。同時,該版本在TiDB 分佈式計算層實現了透明的可根據請求自動選擇行列存儲引擎的能力,使高並發、低延遲的聯機交易與海量數據實時分析查詢計算,在TiDB 新一代架構上完美地融合在一起。

在演講中,姚維也為我們展示了TiDB 4.0 版本性能優化的部分成果(圖中的縱軸是指語句耗時,該值越低代表性能越好):

HTAP會成為數據庫的未來嗎? 2

HTAP會成為數據庫的未來嗎? 3

三、未來,TiDB將跑在雲上!

和很多企業一樣,PingCAP也是雲的用戶,數據中心的上百台機器在雲上24小時不停運轉著。

姚維感慨道:“雲給我們的業務帶來了看得到的便利,比如降低成本、提高效率、靈活性高等,這些好處都是實實在在的。因此,我們相信,未來雲一定會成為主流的方向。TiDB在過去兩年時間裡面已經在做雲的適配。TiDB跑在雲上,底層有很強的計算能力、擴展能力,以及完備的基礎設施和基礎網絡作為支撐,再加上數據庫引擎本身的自動橫向彈性伸縮能力,其整體所提供的能力很多用戶非常想要獲得。”

在企業全面上雲的大背景下,數據庫因其成本昂貴、高運維難度、以及低擴展性和可用性受到挑戰,尤其是對傳統的數據庫而言,在服務用戶的過程當中往往沒有辦法滿足用戶上雲的很多需求。而云計算+數據庫將帶來更低的運營成本、更高的靈活性,以及​​與未來物聯網、5G結合滿足龐大而復雜數據需求的能力。將數據庫“搬”到雲上,將成為未來數據庫發展的主旋律。

在研發TiDB的Cloud版本過程中,PingCAP前期主要在與x86架構適配。如今,基於用戶對異構平台的需求,PingCAP主要在做 TiDB 在鯤鵬計算平台上的性能優化。根據姚維的介紹,除了市場訴求外,在技術層面還有以下兩個主要原因:

1、來自分佈式數據庫的底層需求。x86平台現在雖然比較成熟,但該架構的擴展性具有比較明顯的限制。 TiDB在x86架構和ARM架構上最大的一個差異在於單台服務器上CPU核的數量。因為在固定的情況下,分佈式數據庫意味著需要多台服務器來組成該集群。 PingCAP在與用戶合作的過程中發現,很多企業希望採用具有更多核心的服務器。 x86架構的服務器多為64核,而基於鯤鵬高密度的CPU核架構,數據庫的性能可以有很大的提高。

相應地,對用戶而言,部署成本也會有所降低。當單台機器CPU核數增多,處理能力會隨之增強。在達到同樣性能的情況下,採用ARM架構的機器台數要比x86架構下少。機架、服務器、電源、交換機等周邊費用,也會有比較明顯的降低。

2、ARM的指令級不同於x86複雜的指令級,其在語言的優化層面有較大的空間。TiDB有兩種開發語言,其中,與數據庫性能息息相關的存儲引擎TiKV採用的是Rust語言,這是一種支持並行的編譯型語言,通過優化該語言對鯤鵬處理器架構有比較好的支持性,同時也為編譯器等底層的進一步優化提供了空間。

四、TiDB on 鯤鵬,結果如何?

在TiDB遷移到鯤鵬計算平台的過程中,PingCAP做了深入的性能優化,其中涉及諸多層面和細節,僅代碼上的重要優化少則有幾十項。姚維為我們介紹了其中對TiDB性能影響較大的三個優化工作:

1、在源碼適配上,TiDB底層使用Rust語言編寫,上層的分佈式計算引擎採用Go語言編寫。 TiDB轉移到鯤鵬計算平台上,需要將TiDB的源碼與該平台進行適配。根據姚維的介紹,在適配過程中,超過三分之一的優化工作都是由編譯器自身機制來完成。

2、在存儲引擎上,TiDB中的數據被打散在多個節點上,每一個節點中都會有部分的數據存儲以及數據冗余副本。在存儲引擎框架負責單節點的數據存取操作時,保證數據在內存、磁盤、操作系統、文件系統、存儲等各個層面的準確性至關重要,這就需要數據庫內部有一個足夠強壯的檢查機制。

TiDB通過調用多種校驗核的計算方法來實現上述檢查。在x86上,由於核數不多,該架構上的核心不僅要承載TiDB自身的任務處理請求,如數據庫的增刪改查等運算,還要擠出一部分資源用於校驗的計算。而在核數較多的鯤鵬平台上,與數據校驗有關的計算可以利用更加寬裕的處理器核資源執行。這類高密度數值類的計算優化,為數據庫的性能帶來了比較大的影響。

3、在網絡吞吐的中斷上,雖然中斷與網卡有關,但也和CPU處理網絡隊列的方式有直接的關聯。因此TiDB遷移到鯤鵬平台上後,PingCAP基於ARM對網絡相關的架構進行了優化和適配,以實現更加穩定高效的集群間通訊。

在整個優化過程中,PingCAP進行了一輪又一輪針對各項的嚴格測試,對數據庫穩定性基準、性能基準也在做反复的核驗工作。在演講中,姚維也為我們直接展示了TiDB在鯤鵬平台上的性能優化成果:

HTAP會成為數據庫的未來嗎? 4
HTAP會成為數據庫的未來嗎? 5
HTAP會成為數據庫的未來嗎? 6

對於用戶來講,這些優化工作最直接的效益就是在成本可控的情況下,能夠大幅度提高整個數據庫的服務能力,這也是任何產品在用戶心中最核心的價值考量。

無論是多大體量的用戶,在數據中心未來持續發展的規劃過程中,性價比是不得不考量的一個要素。隨著集群規模的加大,如果單台集群的性能優化成本很高,那麼總體的成本將非常可觀,這其中包括不可避免的機房、機架、供電、高端的配設網絡等基礎設施支出。 TiDB與ARM架構的適配,在同樣的處理能力甚至更高密度的處理能力之下,可以幫助用戶實現總體應用成本不升反降的效果。

寫到最後

傳統技術在市場上的衰弱和退出,意味著新機會的產生。隨著人們對計算、存儲、網絡等層面的要求越來越高,新技術將迎來更多的機會,這也是IT界自然迭代的過程。無論是TiDB的出現,還是TiDB 在鯤鵬平台上的遷移實踐,都為後續更高性能和更高性價比的數據庫發展帶來了足夠的信心。