借生態力量，openGauss突破效能瓶頸

一些耳熟能詳的資料庫，比如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必將攜手生態夥伴，共同為夯實我國數字基礎設施底座貢獻一份力量，為中國數字經濟發展注入新動能。