16 臺伺服器達成 1000 萬 tpmC！挑戰分散式資料庫效能極限

近日， Apache ShardingSphere 社群與 openGauss 社群再度展開合作，Apache ShardingSphere + openGauss 的分散式解決方案，突破了單機效能瓶頸，使用 16 臺伺服器在超過 1 小時的測試中，得到了平均超過 1000 萬 tpmC 的結果。

ShardingSphere + openGauss，達成 1000 萬 tpmC

在本次測試中，openGauss 社群基於標準 BenchmarkSQL 5.0 工具，進行本輪 TPC-C 測試。

在單機效能方面，openGauss 突破了多核 CPU 的瓶頸，實現兩路鯤鵬 128 核達到 150 萬 tpmC，記憶體優化表(MOT)引擎達到 350 萬 tpmC。但業務場景及使用者體驗對於效能的追求是無止境的，尤其在如今海量資料的場景下，追求效能極限仍然是每一款資料庫的目標。

在此情況下，openGauss 團隊採用了 7 臺機器執行適配了 ShardingSphere-JDBC 的 BenchmarkSQL 測試工具，連線 8 臺 openGauss 資料庫，並部署了 1 臺 ShardingSphere-Proxy 用於資料初始化、一致性校驗等維護操作。通過資料分片能力，ShardingSphere 使總共 8000 倉資料(超過 800 GB)被分散在 8 臺 openGauss 節點。在完美 Sharding 的情況下進行持續超過 1 小時的測試後，得到了平均超過 1000 萬 tpmC 的結果，行業同等規模下效能最好。

這極大突破了 openGauss 現有的效能極限，突破了單機效能瓶頸，滿足 openGauss 在海量資料場景下關於效能、可用性以及運維成本這三方面的訴求。兩者的結合，正在持續挑戰分散式資料庫的效能極限。

ShardingSphere 與 openGauss 的生態合作

Apache ShardingSphere 社群自 2021 年起就開始與 openGauss 社群展開密切合作。

隨著業務場景的細分以及資料體量的增長，將資料集中儲存至單一節點的傳統解決方案，已經難以在效能、可用性和運維成本等方面滿足業務需求。誠然，資料分片能力能夠解決單機資料庫在效能、可用性以及單點備份恢復等問題，但也帶來了分散式架構較高的系統複雜性。

作為 Database Plus 理念的提出者和實踐者，Apache ShardingSphere 旨在構建異構資料庫上層的標準和生態，以疊加擴充套件資料分片、彈性伸縮、資料加密等更多計算能力為基礎，站在資料庫的上層視角來關注資料庫之間的協作方式，以能夠合理且充分地利用資料庫計算與儲存能力。目前，Apache ShardingSphere 已經形成了微核心 & 可插拔架構模型，並在此基礎上持續完善核心及功能層面的能力，為企業及開發者使用者提供更多更靈活的解決方案，以滿足在不同場景下的特定需求。

得益於 ShardingSphere 可插拔架構的設計理念，在 ShardingSphere 中實現對 openGauss 的支援無須進行額外改造，只需要基於 ShardingSphere 各個模組所提供的 SPI 擴充套件點，增加對應 openGauss 資料庫的實現。 在 Apache ShardingSphere 5.0.0 版本，已正式完成對 openGauss 資料庫的支援。

雙方在合作過程中，通過將 openGauss 強大的單機效能與 Apache ShardingSphere 生態所提供的分散式能力結合，打造出了適用於高併發 OLTP 場景的國產分散式資料庫解決方案;除功能層面的合作外，ShardingSphere 與 openGauss 在效能方面不斷磨合，充分利用 openGauss 核心技術的創新， 不斷地將 ShardingSphere 與 openGauss 組成的國產分散式資料庫解決方案的功能與效能推向極致，此次關於 TPC-C 的效能測試，就是雙方密切合作的一次典型案例。

使用 ShardingSphere 打造基於 openGauss 的分散式資料庫解決方案

當然，Apache ShardingSphere 的能力不僅有資料分片，還有讀寫分離、資料加密、影子庫等功能，在不同的場景下各項功能既可以單獨使用，也可以結合使用，使用者完全可以按照自己的需求組合 ShardingSphere 的能力。

Apache ShardingSphere 目前提供兩種接入方式，分別為 ShardingSphere-JDBC 和 ShardingSphere-Proxy。在業務中使用 ShardingSphere-JDBC 對資料庫輕鬆進行分庫分表以及讀寫分離等透明化操作，來解決其對於“高併發”、“低延遲” 場景的需求。同時在 JDBC 的基礎上，ShardingSphere 提供 Proxy 端的部署模式，將資料庫部分能力和操作部署在 Proxy 層面，讓使用者可以像使用原生資料庫一樣使用 Apache ShardingSphere，為使用者帶來更加優質的使用體驗。

因此，建議 ShardingSphere-JDBC 和 ShardingSphere-Proxy 混合部署使用，這樣可以實現維護友好與效能兼顧的平衡。

在 openGauss 的體系中，Apache ShardingSphere 能夠通過水平拆分以使 openGauss 的計算與儲存能力實現線性擴充套件，效能也隨著擴充套件準線性增長，從而有效解決單表資料量膨脹問題;此外結合業務流量，靈活平滑進行資料節點的擴縮容，智慧讀寫分離，實現分散式資料庫的自動負載均衡。

後續發展

本次 Apache ShardingSphere 與 openGauss 兩家社群的合作，向外界展示了開源社群之間的合作潛力。隨著應用場景的細化以及資料體量的增長，未來對於資料庫效能的要求只會更高。 此次合作的成功只是雙方構築資料庫協作生態的一個開始，相信 ShardingSphere 與 openGauss 這種合作模式，一定會有更加廣闊的發展空間。

關於 openGauss

openGauss 是一款開源的關係型資料庫管理系統，它具有多核高效能、全鏈路安全性、智慧運維等企業級特性，融合了華為在資料庫領域多年的核心經驗，在架構、事務、儲存引擎、優化器及 ARM 架構上進行了適配與優化。

關於 TPC-C

TPC-C(Transaction Processing Performance Council Benchmark C)用於比較線上事務處理(OLTP)系統效能的基準測試標準規範，由 TPC 於 1992 年釋出，目前最新的規範為 2010 年更新的 TPC-C v5.11。TPC-C 具有多種事務型別、複雜的資料庫和整體執行結構。TPC-C 涉及五個不同型別和複雜性的併發事務的混合，事務會實時執行或進入佇列延遲執行。資料分佈在資料庫九種型別的表中，表的資料量各不相同。TPC-C 以每分鐘事務數(tpmC, transactions per minute C)衡量。雖然 TPC-C 模擬了批發供應商的業務，但 TPC-C 並不限於任何特定業務部門的活動，而是代表必須管理、銷售或分銷產品或服務的任何行業。

特別提醒：本網資訊來自於網際網路，目的在於傳遞更多資訊，並不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，並請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯絡我們，本站將會在24小時內處理完畢。