雲數據庫架構演進與實踐

現在，大型企業如金融企業和銀行等，在下一代的微服務架構轉型要求下，須要基礎軟件和數據平臺可以實現原生的雲化，以知足微服務架構的需求。

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

主要特色包括，每個微服務是一個獨立的自治系統，能夠不依賴外部組件獨立運行；對應用只暴露接口，用戶能夠靈活的調整過每一個微服務的使用；業務粒度足夠小。

 

在企業架構「雲化」的過程當中，數據庫的雲化是最爲重要也是難度較大的一個部分。數據庫雲平臺（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等特性並不重點關注。

 

 

小結

雲數據庫是將來數據庫發展的一個重要方向，雲數據庫架構隨着雲化要求也須要進行相應的迭代，將來在雲數據庫架構的演進還會隨着需求的變化而持續發展。

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

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