借生態力量,openGauss突破性能瓶頸

語言: CN / TW / HK

一些耳熟能詳的數據庫,比如MySQL、PostgreSQL、SQL Server、Microsoft Access等等,都屬於 SQL (Structured Query Language,結構化查詢語言)數據庫。

但是,當要快速處理極大的數據量時,被提起的往往是架構靈活、易於擴展的 NoSQL。對於獨攬穩定性近五十年的 SQL 數據庫來説,易擴展和高性能似乎總是跟它無緣。

歷久彌堅的 SQL

SQL 最初創建於 1970 年代,因其查詢語言擺脱了對數學邏輯和符號的依賴,使得沒有經過數學或計算機編程專業培訓的普通開發者也能很容易使用,很快便成為關係型數據庫事實上的標準編程語言。尤其是隨着 Web 應用程序和 MySQL、PostgreSQL和 SQLite 等開源項目的興起,SQL 在 1990 年代後期更是呈爆炸式增長。

沒幾年後,SQL 結結實實迎來了一次打擊。

二十世紀初,互聯網和萬維網實現了蓬勃發展,數據生成的數量之多和速度之快,讓 SQL 數據庫處理不過來。於是,新生的互聯網巨頭開始琢磨能否採用其他方式來解決這個問題。

在 Google,索引萬維網所涉及的大量數據促使該公司開發新的海量數據存儲方法,例如 Google 文件系統 (GFS) 和MapReduce。這些技術引導開源社區開發出了 Hadoop。Hadoop 也不負眾望,扛起了這面大旗。這嚴重挑戰了關係型數據庫市場的企業數據倉庫部分。

 

在亞馬遜,由於維護“always-on”事務系統的需求與關係型數據庫的一致性模型不匹配,轉而開發了自己的“eventually consistent”的 數據庫系統——Dynamo。受 Dynamo 的啟發,Cassandra 和其他幾個早期的 NoSQL 數據庫系統也相繼問世。

這些 NoSQL 數據庫憑藉其靈活的架構讓它收穫了諸多追隨者。當面臨流量大幅增加,NoSQL 數據庫可以水平擴展,只需增加服務器的數量即可。

而 SQL 數據庫就只能通過垂直擴展,即通過增強硬件能力,比如通過增加單個服務器上的 CPU、RAM、SSD 等來處理。由於大部分數據倉庫都建立在專門的基礎架構上,這就意味着SQL 數據庫處理大量數據的成本可能非常高。

在執行更復雜的大數據工作負載方面,SQL 數據庫要面臨另一個問題是,原始數據必須首先通過稱為 ETL(提取、轉換和加載)的清理和結構化過程,然後才能將其放入倉庫。但是這種數據預處理可能會受到錯誤的困擾。此外,它永久消除了所有潛在有價值的原始數據,同時限制瞭如何查詢“乾淨和簡單”的結果數據。

這麼説起來,SQL 面對 NoSQL 的進攻,似乎毫無反擊之力。

事實並非如此,因為開發人員很快就發現, NoSQL 看起來很完美,但執行起來並沒有那麼容易:每個 NoSQL 數據庫都提供了自己獨特的查詢語言,學習成本很高且難以進行大規模協作;將這些數據庫連接到應用程序的難度更高了,導致大量脆弱的glue code(即膠水代碼,也叫粘合代碼,用途是粘合那些可能不兼容的代碼);缺乏第三方生態系統,要求公司開發自己的運營和可視化工具。

而且,這些新的 NoSQL 語言也沒有完全開發。例如,在關係數據庫中為 SQL 添加必要的特性(比如JOIN)已經有多年的工作;NoSQL 語言的不成熟意味着應用程序級別需要更高的複雜性;缺乏 JOIN 也導致了非規範化,從而導致數據膨脹和僵化。

早在 2008 年,David J. DeWitt 和 Michael Stonebraker 兩個人在《MapReduce:倒退的一大步》文章中如此評價 MapReduce :

  • 大規模數據密集型應用程序編程範式的巨大倒退;

  • 次優實現,因為它使用蠻力而不是索引;

  • 一點都不新穎——它代表了近 25 年前開發的眾所周知的技術的具體實現;

  • 缺少當前 DBMS 中常規包含的大多數功能;

  • 與 DBMS 用户依賴的所有工具不兼容。

SQL 依靠自身的獨特價值——高標準化、強穩定性、強大的生態,讓它在這場爭霸賽中捍衞了昔日榮光,直到今天依然堅挺。在DB-Engines 的 2021 年 9 月最受歡迎的數據庫管理系統列表的前 10 個結果中,有六個是關係型或基於 SQL。

當 SQL 擁有高性能

在與 NoSQL 搶市場的過程中,為 SQL 充當護城河的,仍然是那些傳統的優勢。對於什麼類型的數據庫適合用於並行處理和大規模大數據解決方案這一問題, 答案大概率會是 NoSQL。

那麼,SQL 就註定與易擴展和高性能無緣嗎?

2022 年 4 月,Apache ShardingSphere 社區公開表示,Apache ShardingSphere與openGauss 合作的分佈式解決方案在TPC-C測試中,使用 16 台服務器得到了平均超過1000萬tpmC 的結果。其中,在單機性能方面,openGauss 充分利用了多核 CPU 的性能,實現兩路鯤鵬 128 核達到 150 萬 tpmC,內存優化表(MOT)引擎達到 350 萬 tpmC。

1000萬 tpmC ,意味着什麼呢?意味着行業同等規模下性能最好。這一解決方案歷時近一年,滿足了 openGauss 在海量數據場景下關於性能、可用性以及運維成本這三方面的訴求。

2021 年 5 月份,全球頂級開源分佈式數據庫生態項目 ShardingSphere 與頂級單機開源數據庫 openGauss 的正式開展社區層面的合作。在合作前期,雙方就技術可行性、兼容性等問題展開了維持兩三個月的深度討論,並在討論的基礎上共同開發出了首個ShardingSphere 與 openGauss 兼容的版本。不過這個版本的性能卻不盡如人意,在運行過程中性能損耗過高。

接下來的大半年時間,ShardingSphere 與openGauss社區專家不斷磨合,在技術、部署結構等方面調優,最終讓 ShardingSphere-JDBC 連接 openGauss 的性能損耗成功降至10%以下,ShardingSphere-Proxy的性能損耗是降到了 40% 以下。

作為Apache ShardingSphere 的 PMC,吳偉傑最初負責在 Apache ShardingSphere 上實現深度適配 openGauss 的協議。在 7 月 14 日舉行的openGauss 開發者峯會上,他透露了很多技術實現的細節。

作為一個典型的關係型數據庫,增強 openGauss 性能最直接、有效的方式就是在垂直空間擴展,如在鯤鵬 128 核的環境下還不夠用,那就使用256 核。但垂直擴展的空間也是有限的,不可能無限地把CPU 核數往上堆疊。就算把核數疊上去,程序也不一定能能充分地利用如此多的資源。

因此, ShardingSphere 採用的是另一種方式——對 openGauss 進行數據分片,即在水平方向上進行擴展,使總共 8000 倉數據(超過800GB)被分散在 8 台 openGauss節點。吳偉傑表示:“數據分片的難點並不是如何把數據分散到各個地方,而是當數據被分散到各個存儲節點以後,數據庫如何快速且正確地找到它。這其中涉及到多表關聯、子查詢等複雜的 SQL 能力,而在已實現數據分片的環境下,這些能力也會受到不同程度的限制。”不過,ShardingSphere 能夠透明化分庫分表所帶來的影響,讓使用方儘量像使用一個數據庫一樣使用水平分片之後的數據庫集羣,這也是 ShardingSphere 在水平分片場景下的價值所在。

此外,在讀寫分離、彈性伸縮、傳輸協議等方面,ShardingSphere 都對 openGauss 進行了深度適配。以協議適配為例,吳偉傑也分享了開發思路:

“PG 數據庫執行批量插入時,需要多次發送 Bind 和 Execute。因為在PG的協議層面,每個 Bind 最多隻有一組參數。當要插入 100 行數據,PG 就會連續發送 100 次 Bind  和 Execute。

“而openGauss 則在協議上有所創新,它創造了一個叫 Batch Bind 的協議消息。與普通的 Bind 相比,Batch Bind 一次性可以同時傳輸多組參數,類似於批處理。原來要發送100多個包,但現在只需要通過一個包,減少了很多像消息頭之類的網絡開銷。

“與此同時,ShardingSphere 在 Batch Bind 方面也做了很多優化。比如,當 openGauss 以批量協議的方式把數據發到 ShardingSphere-Proxy 的時候,ShardingSphere-Proxy也同樣可以使用批量協議把這些請求分發到多個 openGauss 數據庫。”

為什麼是 openGauss?

那麼,為什麼是 openGauss ?

ShardingSphere社區認為,作為企業的基石,關係數據庫仍然佔據着巨大的市場份額。但ShardingSphere 本身作為一款開源分佈式數據庫生態項目,其本身在底層數據庫之上的定位,使其具備了面向底層關係數據庫提供擴展數據分片、彈性伸縮、數據加密等增強型計算能力,讓整個分佈式系統中已有數據庫的計算和存儲能力利用得更加合理、高效。如其所云:“ShardingSphere 更傾向於關注原生數據庫的能力增量,而不是市場格局的徹底顛覆。”

而 openGauss 是國內為數不多的高性能關係型開源數據庫之一,有着華為多年的深厚積累,並且已經支持了國內主流服務器芯片架構和操作系統。

今年 3 月上線的openGauss 3.0 版本,在“高性能、高可靠、高安全、高智能”四個方面持續創新。在高性能方面,優化執行技術持續突破,多場景性能持續穩步提升;高可用方面,持續升級,提供全方位高可用能力;高智能方面,AI-Native技術持續領先,內核與AI進一步融合;高安全方面,全方位安全引擎,全程密態,提供極致的安全體驗。

此外,還針對應用場景進行重大升級,包括推出面向邊緣場景的輕量化版本,完備的集羣管理組件,以及支持MySQL語法兼容和數據遷移等。openGauss持續打造面向數字基礎設施的開源數據庫,從數據中心到邊緣,構建多場景支持能力。

這是一次 openGauss 強大的單機性能與 Apache ShardingSphere 生態所提供的分佈式能力的完美結合,才打造出了一個適用於高併發 OLTP 場景的國產分佈式數據庫解決方案。據瞭解,所有合作成果在 Apache ShardingSphere 5.0.0 版本已經有所體現。

《説苑·談叢》有云:循流而下,易以至;倍風而馳,易以遠。藉助生態夥伴的力量,化短板為優勢,即使是SQL也能實現易擴展和高性能。這也是openGauss不斷強調打造數據庫技術生態的原因。

在去年12月舉辦的openGauss Summit峯會上,openGauss提出了技術願景:以內核為基礎,水平擴展能力,垂直擴大應用場景,聯合數據庫產業鏈上下游創新,打造數據庫技術生態。

目前,openGauss已在中國郵政儲蓄銀行、民生銀行、中國移動、中國電信、中國聯通、國家電網等企業用户廣泛應用。例如,中國郵政儲蓄銀行基於企業級開源數據庫openGauss,已於今年4月全量上線新一代個人業務核心系統,系統性能提升5倍,支取和查詢等高頻業務的響應時間縮短25%,支持日均20億筆海量交易。郵儲銀行也是首個完成核心替代,並上線新一代個人業務核心系統的國有大行。

據瞭解,僅僅在過去半年間,適配行業的解決方案數量從去年底200多個快速增加到當前超過350個。如今,隨着越來越多的力量加入openGauss生態,這一願景正在不斷付諸現實。

信息技術應用創新產業國產化勢在必行,數據庫作為基礎軟件之一,是其中的重要一環。作為國產開源數據庫的佼佼者,openGauss必將攜手生態夥伴,共同為夯實我國數字基礎設施底座貢獻一份力量,為中國數字經濟發展注入新動能。