歡迎光臨
每天分享高質量文章

雲化要求下,資料庫架構的演進

如今,大型企業如金融企業和銀行等,在下一代的微服務架構轉型要求下,需要基礎軟體和資料平臺能夠實現原生的雲化,以滿足微服務架構的需求。


微服務,也就是一種面向服務的,有特定邊界的鬆散耦合的架構。


主要特點包括,每一個微服務是一個獨立的自治系統,可以不依賴外部元件獨立執行;對應用只暴露介面,使用者可以靈活的調整過每個微服務的使用;業務粒度足夠小。

 

在企業架構“雲化”的過程中,資料庫的雲化是最為重要也是難度較大的一個部分。資料庫雲平臺(dbPaaS)是一類支援彈性擴張、多租戶、自我管理、並能夠執行在雲服務提供商的基礎設施(IaaS)之上的資料庫管理系統(DBMS)或儲存管理系統。

 

根據Gartner報告預測,資料庫雲平臺市場份額將會在下一個五年中翻倍,而70%的使用者將開始使用dbPaaS資料庫雲平臺。因此,為了滿足各類應用程式對資料庫雲平臺的需求,同時為了減少私有雲部署中對大量不同型別資料儲存產品的運維複雜性,資料庫的架構演進將是未來十年資料庫轉型的主要方向之一。

雲資料庫的技術需求

在業務和應用進行“雲化”的過程中,雲資料庫因為在整體架構中的重要地位,在雲化改造中的重要性不言而喻。雲資料庫的核心需求有一下幾點,主要有:


  • 彈性擴張能力:資料庫容量需要根據業務彈性擴充套件,滿足不同業務的容量需求;

  • 彈性部署與隨需應變能力:除了資料庫的儲存,其他資料庫功能也需要根據應用的需求,進行彈性的部署調整;


  • 資料可靠性與服務持續能力:資料的可靠安全,全時線上是所有業務的必須要求;


  • 計算儲存分離:將計算和儲存資源靈活配置,既可以選擇多種計算方式也可以同時對應多種儲存方式,滿足更多業務需求;


  • 多樣式儲存能力:結構化、非結構化、半結構化和圖等多型別資料的儲存;


  • 自我管理能力:提供零停機維護、持續整合、以及滾動升級能力,提升開發人員效率;


  • 自我監控以及問題修複能力:故障監控和問題修複,降低運維成本;


  • 是否滿足特定應用場景:針對特定場景的可插拔元件或工具;


  • 監管與安全:滿足監管的要求,保證資料的安全。

 

雲資料庫需要滿足這些技術要求,除了在功能上的具體提升,在整體架構上更需要進行升級和“進化”。

雲資料庫架構方向

雲資料庫架構是其能否承載應用架構“雲化”的關鍵點,隨著技術和業務的發展,雲資料庫的架構出現了幾個主要的發展方向:


  • 在dbPaaS平臺中,計算-儲存層分離將會成為主流技術方向。透過將協議解析、計算等模組與底層儲存解耦,資料庫雲平臺將儲存層進行分片以實現儲存的彈性水平擴張,同時透過計算層的無狀態設計允許計算層透過增加節點數量線性提升計算能力,已達到整個資料庫雲平臺的彈性水平擴張。


  • 多模架構成為主流趨勢,Multi-model的架構在一個資料庫平臺就可以支援多種儲存方式,大大減少運維和開發的成本。傳統資料庫中例如IBM、Oracle等早已經提供關係型、OO、甚至XML等儲存引擎。而新一代資料庫則更提供NewSQL、JSON、圖、物件儲存等多種型別資料儲存引擎。


  • 雲資料庫平臺將會提供多種混合樣式的資料服務 – 關係型與非關係型。該樣式使使用者能夠在同一平臺中結合不同資料儲存型別的特點,為新一代IT應用系統提供混合資料儲存解決方案。


  • 更符合微服務業務架構的要求,微服務要求各個服務模組之間儘量松耦合和可獨立擴充套件。因此對於資料庫,也同樣會針對不同的業務,進行不同側重的配置,無論是傳統的“讀寫分離”或者現在流行的HTAP都是圍繞這個要求展開的。

 

針對這幾個主要的發展方向,我們就將詳細來探討雲資料庫的幾個重要技術特點。

 

1)儲存-SQL 分離


針對雲資料庫的需求和架構方向,一種新的資料庫架構也在漸漸成為主流,也就是資料庫的 “儲存-SQL分離”架構。

 

儲存-SQL分離架構,即指資料庫的儲存引擎和SQL引擎兩部分互相松耦合獨立工作的架構。通常這一架構,分為儲存、SQL和元資料 三個部分。


  • 儲存層:即資料庫的儲存引擎,儲存引擎負責處理資料的儲存管理。同時包含路由及事務控制,保障資料的ACID特性。此外,儲存層還應還具備索引、查詢條件過濾、排序等一系列功能。


  • SQL層:SQL層主要負責處理SQL請求,上層直接面對應用程式,將應用程式的訪問請求分發給儲存層,並且接受儲存層傳回的資料結果。


  • 元資料區:元資料區負責儲存整個資料庫的所有元資料資訊。

 

典型的雲資料庫架構示意

 

對於這一架構,其實MySQL資料庫當前的架構是有一些類似的。


MySQL資料庫的SQL、儲存分離的架構,在架構較為靈活,而其開源的生態也支援將不同的產品、引擎和工具進行充分的對接。在儲存引擎的架構上,外掛式的儲存引擎架構將查詢處理和其它的系統任務以及資料的儲存提取相分離。這種架構可以根據業務的需求和實際需要選擇合適的儲存引擎。

MySQL資料庫整體技術模組架構

 

如上圖所示,MySQL 的儲存引擎可以掛載多種不同的產品,每個引擎都能提供不同的技術特性。其中包括InnoDB、MyISAM等架構。

 

儲存與SQL分離的架構,目前在資料庫業界十分流行,AWS的Aurora資料庫在SQL訪問上也採用了類似的架構。SequoiaDB 3.0 目前在MySQL相容上,主要也是採取“SQL-儲存分離“的架構。

 

SequoiaDB 3.0 MySQL 相容邏輯架構

 

SequoiaDB 3.0使用了MySQL資料庫原生的SQL解析器,天然支援MySQL協議並可以做到100%語法相容。在該架構中,MySQL協議解析層作為SQL解析和分發的角色,直接面對應用程式,每一個MySQL服務的接入節點都是一個獨立支援讀寫操作的MySQL行程。而資料儲存和管理層,則完全由巨杉資料庫的分散式資料庫引擎實現。簡單來說,SequoiaDB 3.0作為MySQL的InnoDB替換引擎,在天然支援MySQL的全部語法和功能的同時,提供了資料庫儲存層彈性擴張的能力。

2)多模Multi-Model


企業使用雲資料庫對接的應用越來越多,需求多種多樣,傳統的做法是在dbPaaS裡面提供十幾個不同的資料庫產品分別應對各種需求,這樣的方法在系統增加後,整體維護性和資料一致性管理成本很高,會影響到整個系統的使用。

雲資料庫的“多模”示意圖

 

為了實現業務資料的統一管理和資料融合,新型資料庫需要具備多樣式(Multi-Model)資料管理和儲存的能力。資料庫多模Multi-Model是指同一個資料庫支援多個儲存引擎,可以同時滿足應用程式對於結構化、半結構化、非結構化資料的統一管理需求。

 

通常來說,結構化資料特指表單型別的資料儲存結構,典型應用包括銀行核心交易等傳統業務;而半結構化資料則在使用者畫像、物聯網裝置日誌採集、應用點選流分析等場景中得到大規模使用;非結構化資料則對應著海量的的圖片、影片、和檔案處理等業務,在金融科技的發展下增長迅速。

 

多樣式資料管理能力,使得金融級資料庫能夠進行跨部門、跨業務的資料統一儲存與管理,實現多業務資料融合,支撐多樣化的金融服務。

 

在架構上,剛剛提到的多模Multi-model也是針對雲資料庫需求的,則使得資料庫使用一套資料管理體系可以支撐多種資料型別,因此支援多種業務樣式,大大降低使用和運維的成本。

 

3)災備和多活


對於應用程式來說,開發人員並不希望在設計應用的過程當中花費大量的精力來考慮底層資料高可用、災備與多活時應用的切換邏輯。一般來說,一個成熟的dbPaaS層應當盡可能將底層的資料多副本同步、災難切換、高可用接管等一系列操作進行封裝,對於應用程式做到完全透明。

 

在傳統的應用程式開發中,開發者使用中介軟體容器對資料源進行配置,底層使用F5或其他虛擬IP地址對多個資料源進行封裝。但是,在雲化的演變過程中,底層的資料庫從單一節點向分散式節點過渡,對於上層的應用程式一方面希望盡可能減少應用程式設計時對分庫分表的依賴,另一方面更希望在資料節點切換,甚至資料中心災難接管的過程當中做到應用透明無感知。


SequoiaDB 3.0則引入了異地多活的架構,應用程式可以從任意接入節點以讀寫的方式訪問本地資料庫。在資料讀寫的過程當中,巨杉資料庫能夠從底層有效地進行資料一致性控制,對多個地區本地寫入的資料進行遠端複製,確保多個站點所讀寫的資料完全一致。

 

另外,災難發生時巨杉資料庫提供對應用程式透明的資料切換與接管機制,動態調整底層資料分佈拓撲邏輯,能夠動態有效地排除故障資料中心內的節點,做到其他站點無感知地繼續提供資料服務。

 

多活相比於傳統的高可用來說,不僅在效能和安全性上實現了更大的提升,而這一架構也能在多活資料中心中充分的應用軟硬體裝置,減少冗餘。

 

雲資料庫架構優勢

在技術驅動的需求下,雲資料庫架構具備了幾項主要的業務價值:


  • 無需分庫分表:此前,一種資料庫分散式改造的方向是關係型資料庫往分散式架構改造,MySQL分庫分表就是其中一種方案。如今,儲存-SQL分離的架構,在資料儲存層已經實現原生分步實施,就避免了複雜冗長的“分庫分表”方案。


  • 靈活支撐業務需求:儲存和SQL層都可以實現服務、儲存的彈性調整,靈活地支撐業務的需求。


  • 多儲存引擎相容:由於SQL和儲存層的分離,在保持SQL介面不變的情況下,底層儲存引擎可以支撐多個不同引擎,實現多種資料引擎的同時相容。


  • 完全相容已有應用:由於SQL層更多使用已有的標準SQL解析器,因此對於原有應用在SQL上可以實現完全的相容,沒有任何應用改造的投入。


  • 資料安全可用:分散式的儲存和松耦合的架構,資料擁有安全的多副本,松耦合則大大增強了整個系統的容錯性。相比傳統單點架構,可以很好的實現資料雙活甚至多活的架構,滿足“兩地三中心”“三地五中心”的合規監管安全要求。

 

雲資料庫應用場景

在新架構驅動下,雲資料庫目前在多個場景下已經開始實現落地應用。

 

傳統交易服務


在傳統中心化交易型業務中,高效能、高吞吐量的資料儲存與處理能力,ACID以及安全都是非常重要的特性。例如,在一個典型的銀行業務中,為了滿足高峰時期的線上交易量,交易型資料庫需要在億級記錄條數的資料庫中每秒處理上千比交易。同時,為了滿足生產系統的健壯性與可靠性,傳統交易服務對於底層資料儲存的安全性、高可用性、兩地三中心部署能力都有著非常明確的要求。

 

因此雲資料庫既需要將傳統交易型業務逐漸轉移至雲平臺,同時也需要在滿足安全性和合規監管方面,為使用者提供更好的支援。

 

歷史資料服務


近年來,隨著IT技術與大資料的不斷發展,越來越多的企業將資料作為自身寶貴的資產進行長期保留。這使得一些傳統應用程式的歷史資料包袱越來越重,最終資料庫不堪重負導致應用整體效能低下。另一方面,隨著大資料需求的不斷增加,曾經已經歸檔的資料需要重新線上以滿足線上化、實時化使用、查詢和分析等等要求,這就要求將原有龐大的離線資料進行“線上化”。這些需求使得歷史資料管理成為必須。


對於歷史資料服務來說,由於對外提供應用程式的直接訪問,其健壯性、可靠性、可配置一致性策略、效能與併發能力都是極為值得關註的。同時,相對傳統交易服務來說,強一致和ACID反倒並不是最關註的點。鑒於一些企業直接將部分報表和自助查詢執行在歷史服務平臺上,HTAP的能力也是值得關註的特性。

 

雲資料庫在擴充套件性和效能上透過分散式的架構滿足了這些需求,將歷史資料很好的管理起來。

 

實時線上服務


當前大部分企業的生產業務系統與後臺的資料加工、分析與查詢系統都是透過T+1的方式進行資料ETL。而最近隨著流處理技術的興起,越來越多的企業開始基於流處理技術構建T+0的資料匯流排,以實現不同業務流程之間實時資料對接。譬如說,使用者資產檢視就可以利用流處理技術,在提供使用者全資產檢視查詢的優秀使用者體驗的同時,大幅度減輕其對後臺生產系統造成的查詢壓力。


對於實時線上服務來說,資料庫的層面最為關註效能、吞吐量、可靠性、與可用性。而對於強一致、ACID、與HTAP來說並不構成其最重要的特性。


線上業務的資料多樣化和效能都需要雲架構的資料庫提供更靈活高效的支援。

影像儲存服務


很多行業在業務運營中會產生大量紙質憑證,在資訊化處理和監管要求下,這些紙質的憑證都需要掃描成影像檔案並長期儲存。隨著網際網路技術以及集中作業中心等理念的深入推廣,大量行業普遍需要建設統一的影像管理平臺。


對於典型的影像平臺來說,其儲存的資料總體量極大,使用傳統儲存的單位成本很高,需要進行生命週期管理時對運維又非常複雜。因此,對於逐年遞增的海量影像資料來說,大部分企業都存在查詢難、管理難、擴容難的幾大痛點。


同時,由於影像儲存服務已經成為很多流程的一部分,其穩定性、可靠性與健壯性與核心交易系統處於同一級別。因此,影像儲存服務最關註的層面在於可靠性、一致性、可擴充套件性、吞吐量、以及非結構化儲存的多模特性。而其對於交易的ACID、HTAP等特性並不重點關註。

小結

雲資料庫是未來資料庫發展的一個重要方向,雲資料庫架構隨著雲化要求也需要進行相應的迭代,未來在雲資料庫架構的演進還會隨著需求的變化而持續發展。


其中對於多模資料引擎、計算儲存分離等將是雲資料庫技術演進的重點方向。


巨杉也會持續關註架構的迭代演進,同時也在技術和架構上針對雲架構進行更多的創新。


作者簡介:王濤

SequoiaDB聯合創始人&CTO;。


推薦閱讀

更多私有雲解決方案詳細介紹,請點選原文連結參看“VMware雲資料中心(私有雲)解決方案詳解”相關資料。



溫馨提示:

請搜尋“ICT_Architect”“掃一掃”二維碼關註公眾號,點選原文連結獲閱讀原文瞭解更多

求知若渴, 虛心若愚

贊(0)

分享創造快樂