我們在講的 Database Plus，到底能解決什麼樣的問題？

背景

一直以來，大一統還是碎片化，是資料庫發展趨勢的兩種最主流預測。隨著數字化程式的推進，單一場景無法滿足應用多樣化的需求，資料庫碎片化已呈不可逆的趨勢。在當前，市場佔有率最高的商用資料庫—— Oracle 並沒有明顯短板的情況下，各種全新的資料庫依舊如雨後春筍般層出不窮。如今，DB-Engines 上已有超過 300 餘種資料庫參與排名。

應用場景的不斷擴張，加速了資料庫碎片化的程式，資料庫的架構、協議、功能、適用場景也愈加多樣化。在資料庫架構方面，基於單機系統演進而來的集中式資料庫與原生面向分散式的新一代資料庫並存；在資料庫協議方面，MySQL 和 PosrtgreSQL 這兩大主要開源生態以及周邊廠商所提供的服務生態也在全球資料庫體系中各自佔有一席之地；每種資料庫的獨特功能和適用場景，也在相關的領域大放異彩。

在企業的應用現狀中，資料庫的多元並存已是常態。在網際網路行業中，以 MySQL + 資料分片中介軟體作為核心業務儲存的架構模式為主，以 GreenPlum、HBase、Elasticsearch、Clickhouse 等其他大資料生態作為分析型資料的計算引擎為輔助。與此同時，一些遺留系統（如：透過 .NET 轉型時遺留的 SQLServer、或透過外採而遺留的 Oracle）的資料庫仍在執行；在金融行業中，核心交易系統仍然大量使用 Oracle 或 DB2，新業務向 MySQL 或 PostgreSQL 遷移，部分業務則逐漸嘗試使用自主研發的資料庫。除了交易型資料庫，分析型資料庫的種類則更加繁多。

因此，碎片化是資料庫領域的大勢所趨，單一品類的資料庫無法適用於所有場景，只能適用於某一種或某幾種擅長的場景。

資料庫碎片化帶來的問題

隨著企業採用的資料庫種類不斷增加，各種問題和痛點也隨之出現。

1. 架構選型困難

當應用架構為了適應更加靈活多變的業務需求，將架構設計從單體式向服務化再到微服務進行轉化之後，用於儲存業務核心資料的資料庫則成為分散式系統的下一個焦點。

相對比無狀態的應用，具有狀態的資料庫的設計難度則有過之而無不及。分而治之是分散式系統的最佳實踐，顯然，資料庫體系也不能簡單的用單一產品以及一體化叢集來響應所有的服務請求。

首先，單一品類的資料庫無法滿足業務應用的全部需求，在高吞吐量、低延時、分散式無感知、強一致性、運維友好度甚至穩定性等方面難以做到面面俱到。一個應用需要多種資料庫共存的可能性尚且不高，但多個應用混用多種資料庫的可能性則大大提升。

其次，無論是單機資料庫，還是 All in One 的分散式資料庫叢集，都難以成為眾多微服務應用後端的唯一儲存支撐。單機資料庫無法承載越來越大的資料量和訪問量，所以越來越多的應用選擇採用分散式解決方案。然而，多應用使用統一的資料庫叢集，在 CPU、記憶體、磁碟、網路等方面的負載無法做到完全隔離。一個應用的超額資源使用，可能會導致眾多毫不相干的應用服務質量下降。

如今，大部分分散式資料庫的搭建成本相當高，在計算節點、儲存節點和治理節點都需要備份和冗餘的獨立伺服器。如果要為每一個微服務都搭建一套獨立的分散式資料庫，一定會造成非必要的資源消耗，最終導致企業無法承受。

最後，大量企業採用單元化架構。基於資料分片的解決方案，將資料庫的拆分和單元化一併放到應用端解決。隨著資料庫數量的增多，架構設計的複雜度會呈指數級增長。長此以往，業務開發團隊將無法把精力集中在最擅長的業務研發層面，反而需要花費大量精力投入到基礎元件的維護。儘管 Apache ShardingSphere 的資料分片功能可以較好解決相關問題，但面對更多元的資料庫，僅支援單一品類資料庫的水平分片能力是遠遠不夠的。

2. 技術挑戰眾多

當碎片化資料庫共存成為常態時，研發人員的學習與開發成本將不可避免地持續增長。儘管資料庫大多支援 SQL 的操作方式，但各資料庫間仍有大量 SQL 方言的差異。除此之外，各資料庫間驅動程式的使用方式也或多或少存在不同。

因此如需精細化使用每一種資料庫，必定會佔用研發工程師大量的精力，且沉澱下來的知識和經驗不易傳承；如果採用粗粒度的標準模式統一使用異構資料庫，將會湮沒資料庫自身的特點，而無法發揮其應有的作用。

3. 運維複雜度高

掌握各種資料庫特徵，並結合實際場景制定行之有效的運維規範，需要大量時間和實踐經驗的積累。除了最基本的運維工作，資料庫周邊配套工具的差異性也非常大。透過周邊配套工具所組成的監控、備份及其他自動化運維等工作，隨著資料庫種類的增加將會產生巨大的運維成本。

4. 資料庫間缺乏協作和統管能力

站在資料庫的角度，其首要目標是完善自身的能力，而非面向其他資料庫的線上協作能力。跨越異構資料庫的關聯查詢、分散式事務等功能，是無法在資料庫本身實現的。

與相對標準的 SQL 不同，資料庫自身的協議和周邊生態工具缺乏統一的標準。對異構資料庫的統一管控能力也受到越來越多的關注。但遺憾的是，資料庫上層標準的缺失，使得資料庫間的協作和統管能力難以取得有效的推進。

Database Plus 是什麼？

Database Plus 是一種分散式資料庫系統的設計理念。旨在碎片化的異構資料庫上層構建生態，在最大限度複用資料庫原生存算能力的前提下，進一步提供面向全域性的擴充套件和疊加計算能力。使應用與資料庫間的互動面向 Database Plus 構建的標準，從而遮蔽資料庫碎片化對上層業務帶來的差異化影響。

『連線、增強、可插拔』是定義 Database Plus 核心價值的三個關鍵詞。

1. 連線：打造資料庫上層標準

相對於提供一個全新的標準，Database Plus 更傾向於提供一個可以適配於各種資料庫 SQL 方言和訪問協議的中間層，提供開放的介面用於對接各種資料庫。

由於資料庫訪問協議的實現，Database Plus 和資料庫在使用體驗上並無二致，可以支援任意的開發語言和資料庫訪問客戶端。

除此之外，Database Plus 能夠最大限度支援 SQL 方言間的相互轉換。可以將 SQL 解析而成的 AST（抽象語法樹）根據其他資料庫方言的規則重新生成 SQL。SQL 方言轉換的能力，打通了連線異構資料庫之間相互訪問的通道，使用者可以使用任意一種 SQL 方言訪問異構的底層資料庫。

『資料庫閘道器』是對連線的最佳詮釋。在資料庫上層打造開放對接的通用層，將碎片化資料庫的全部訪問流量彙集於此，是 Database Plus 為資料庫碎片化提供解決方案的前提條件。

2. 增強：資料庫計算增強引擎

資料庫經歷了數十年的發展，其自身具備了查詢最佳化器、事務引擎、儲存引擎等久經考驗的存算能力和設計模型。在 IT 領域，資料庫的設計和使用方式已深入人心，不可動搖。隨著分散式和雲原生時代的到來，將資料庫原有的計算和儲存能力全部打散，並織入分散式和雲原生級別的全新能力，會不可避免的重複造輪子。

因此，Database Plus 採用了既重視傳統資料庫的實踐經驗，又適配於新一代分散式資料庫的設計理念。無論是集中式還是分散式的資料庫，Database Plus 都能複用資料庫的儲存和原生計算能力，並在其基礎之上提供全域性化的能力增強。

全域性化的能力增強主要在分散式、資料控制和流量控制三個方面。

無論是原生面向分散式的資料庫，還是基於集中式資料庫作為基石的分散式擴充套件方案，都離不開分而治之這個分散式系統永恆不變的設計原理。 資料分片、彈性伸縮、高可用、讀寫分離、分散式事務、以及基於垂直拆分的異構資料庫聯邦查詢等功能，都是 Database Plus 在分散式的異構資料庫全域性層面下所能夠提供的能力。它的關注點不在於資料庫自身，而是站在碎片化的資料庫上層，關注於多個資料庫之間的全域性協作能力。

除了分散式增強之外，資料控制和流量控制的增強能力均處於豎井化範疇。面向資料控制的增量能力包括：資料加密、資料脫敏、資料水印、資料溯源、SQL 審計等；面向流量控制的增量能力包括：影子庫、灰度釋出、SQL 防火牆、黑白名單、熔斷限流等。這些均屬於資料庫生態層所提供的能力，然而在資料庫碎片化的態勢下，為每一種資料庫提供全量的增強能力的工作量十分巨大，且缺失統一的實現標準。Database Plus 透過提供支點，將支援的資料庫種類和增強功能相疊加，以排列組合的方式提供給使用者使用。

3. 可插拔：構建資料庫功能生態

不斷增加的資料庫型別對接和增強功能織入，會使 Database Plus 通用層逐漸趨於臃腫。 連線和增強的可插拔化，既是 Database Plus 通用層維持小而美的基石，也是擴充套件生態無限化的有效保障。可插拔的體系，為 Database Plus 通用層提供了外掛生態無限擴張的可能，使用者只需根據自身需求裁減外掛即可。

透過可插拔體系，Database Plus 將能夠真正的構建面向資料庫的功能生態，將異構資料庫的全域性能力統一納管。它不僅面向集中式資料庫的分散式化，也同時面向分散式資料庫的豎井功能一體化。

微核心設計和可插拔架構是 Database Plus 理念的核心價值，它面向通用的平臺層，而非某項具體功能。

ShardingSphere 在 Database Plus 方向的探索

Apache ShardingSphere 專案歷史悠久，從開源伊始的資料庫分片中介軟體，到如今 Database Plus 理念的奠基者和實踐者，它的前進步伐從未放緩。目前，Apache ShardingSphere 遵循 Database Plus 理念，已完成了 Database Plus 三大核心價值下的大部分基礎設施建設。

1. 連線層

ShardingSphere 已支援 MySQL、PostgreSQL、openGauss 等資料庫協議，以及 MySQL、PostgreSQL、openGauss、SQL Server、Oracle 和所有支援 SQL92 標準的 SQL 方言。

連線層抽象的頂層介面可供其他資料庫開放對接，包括：資料庫協議、SQL 解析和資料庫訪問等。

2. 增強層

ShardingSphere 的功能增強劃分為核心層和可選功能層。

核心層包含查詢最佳化器、分散式事務、執行引擎、許可權引擎等與資料庫核心強相關的功能，以及排程引擎、分散式治理等與分散式強相關的功能。核心功能的每個模組都必須存在，但可以切換至不同的實現型別。以查詢最佳化器為例，如果待執行 SQL 可以完美下推至後端資料庫，則採用基於原始 SQL 與資料庫互動的計算下推引擎；如果待執行 SQL 需要跨越多資料來源進行關聯查詢，則採用基於查詢計劃樹與資料庫互動的聯邦查詢引擎。

可選功能層的功能模組由開源社群沉澱而形成。除了最具代表性的資料分片和讀寫分離之外，高可用、彈性伸縮、資料加密、影子庫等功能模組，都在逐步的完善之中。

3. 可插拔層

從最初的 MySQL + 資料分片為核心的架構模型，到如今的微核心 + 可插拔架構，專案進行了徹底的改造。從提供連線的資料庫種類和增強功能到核心能力，ShardingSphere 全部面向可插拔。

ShardingSphere 的架構核心外圍，由微核心、可插拔介面、外掛實現這三層模型組成，層次之間單項依賴，微核心對外掛功能完全無需感知，外掛之間也無需相互依賴。對於一個擁有 200+ 模組的大型專案來說，架構的解耦和隔離，是社群開放協作、將錯誤影響範圍降低至最小的有效保障。

小結

Database Plus 是 ShardingSphere 的理論支撐，ShardingSphere 是 Database Plus 理念的最佳實踐。隨著 ShardingSphere 的越來越成熟，Database Plus 的拼圖也會越來越豐滿。

Database Plus 帶來的優勢

Database Plus 帶來眾多的優勢，受限於篇幅，無法在文中一一列舉。下面僅從影響系統架構設計和技術選型方面進行闡述。

1. 精細化適配靈活多變的應用場景

使用者可以根據自身需求定製化使用相應功能，資料分片不再是使用 ShardingSphere 的必要條件，獨立使用資料加密功能的使用者已不在少數。ShardingSphere 的可插拔能力不僅限於資料庫接入層和功能增強模組本身，每個功能模組的內部也能夠基於可插拔架構靈活配置。

以資料分片為例，作為資料分片模組的可插拔部分，分片演算法可以由使用者自定義配置，無論是標準的雜湊、範圍、時間等分片演算法，還是自定義分片演算法，使用者都可以根據業務場景需要自由靈活配置，最大限度切合業務場景。

2. 面向架構師的微服務後端支撐能力

Apache ShardingSphere 是微服務後端的資料庫單元化最佳方案。正如前文所述，不同的微服務共享一套分散式資料庫叢集，無論從架構設計的不對稱性，還是資源隔離的不可控性，都不能稱之為完善和優雅的解決方案。為每一組微服務搭建一套分散式資料庫叢集，則又會造成非必要的資源浪費。

相對於重量級的分散式資料庫叢集，ShardingSphere-Proxy 所佔用的資源節省很多，為每個微服務叢集獨享一套資料庫叢集奠定良好基礎。但如果微服務拆分足夠精細，為每一組微服務搭建一套 ShardingSphere-Proxy 的額外資源佔用依舊不可小覷。在這種情況下，可以考慮使用佔用資源更少的 ShardingSphere-JDBC，它作為類庫與應用程式碼部署在一起，無需額外佔用資源。

ShardingSphere-Proxy 和 ShardingSphere-JDBC 不僅可以透過混合使用的方式，來滿足使用者的使用友好度、跨語言適配、高效能、資源節省等各方面需求；還可以透過 Traffic Rule 讓 ShardingSphere-Proxy 和 ShardingSphere-JDBC 在不同特徵的 SQL 請求中相互路由，以最小化應用資源佔用所帶來的影響。

Traffic Rule 可以根據使用者自定義的 SQL 特徵（如：聚合計算、無分片鍵的全路由查詢等），將佔用更多計算資源的請求傳送至獨佔資源的 ShardingSphere-Proxy，而將交易型的輕量級操作保留在微服務應用端。這與邊緣計算的理念不謀而合，ShardingSphere-JDBC 在微服務應用端的算力和邊緣計算節點有異曲同工之妙。用於中心計算的 ShardingSphere-Proxy 可以根據業務自身需要，部署獨立的叢集服務於多組微服務。

透過靈活使用 ShardingSphere-Proxy、ShardingSphere-JDBC 和 Traffic Rule，這套組合將能夠不斷激發著架構師的設計靈感和創造力。開句玩笑，正確使用 ShardingSphere 進行優雅的系統設計，可以被當作優秀架構師的准入線。

3. DistSQL 為 DBA 帶來資料庫原生操作體驗

面對資料分片、資料加密等增強功能，Apache ShardingSphere 之前版本主要採用 YAML 的方式進行配置。對於開發工程師來說，靈活的 YAML 配置使用起來得心應手，但對於 DBA 而言，YAML 的配置方式卻存在諸多不便。除了改變了 DBA 的日常 SQL 操作習慣之外，無法對接諸如許可權、安全、工單、監控、審計等第三方系統，也讓此前的 ShardingSphere 難以適用於生產環境的運維管控。

全新版本的 Apache ShardingSphere 增加了 DistSQL 的操作方式。使用者可以完全透過 SQL 在任意的資料庫終端（如：MySQL Cli、Navicat 等）操作增強功能。資料分片、資料加密、讀寫分離等所有的強功能都擁有與之相匹配的 DistSQL，使用 DBA 所熟悉的 CREATE/ALTER/DROP/SHOW 等 SQL 語法即可完成全部功能的配置。DistSQL 同樣支援授權語句的管控，也可以透過對接 SQL 審計平臺記錄所有使用者的操作記錄。

資料庫表結構是 Database 的後設資料，增強功能配置是 Database Plus 的後設資料。 DistSQL 的出現，不僅提升了使用者友好度，也補全了 Apache ShardingSphere 上線和運維的最終拼圖。

4. Proxyless 模式提升效能至極致

在 Service Mesh 領域，最為經典就是 Istio + Envoy 架構搭配模式。它透過 Sidecar 的部署方式管理 Envoy，做到對應用的無侵入，稱之為 Proxy Service Mesh，降低了開發、使用和升級的成本，但由於在訪問鏈路中增加了 Proxy/Sidecar 這一層，使得效能有所下降。

而 Proxyless Service Mesh 則採用另一種設計模式，它始於 gRPC 對 xDS 協議的實現，Istio 新版本透過 gRPC + xDS 的方式，允許應用程式碼直接透過 Istio Agent 提供的 SDK 程式設計，有效提升了通訊效能。

在分散式資料庫領域，存算分離的架構設計模式已經深入人心。計算節點和儲存節點分離的設計，與 Proxy Service Mesh 的架構模型有些類似。ShardingSphere-Proxy 的設計完全契合了存算分離的架構模型，它有效降低了使用者的開發、使用和升級成本，卻不可避免帶來了一定的效能損耗。

對於效能延時敏感的應用而言，與 Proxyless Service Mesh 設計理念不謀而合的ShardingSphere-JDBC 無疑更加合適，其能夠將系統的效能發揮至極致。在近期使用 ShardingSphere + openGauss 測試 TPC-C 模型的結果中，得到了驚人的 16 臺伺服器超過 1000w tpmC 的測試結果，行業同等規模下效能最佳。

*文章參考： 16 臺伺服器達成 1000 萬 tpmC！挑戰分散式資料庫效能極限

小結

一直以來，先進的設計理念和創新均源於西方。但 gRPC 的 Proxyless 設計理念是近期才出現的，而 ShardingSphere-JDBC 則是專案在 2016 年開源伊始時就已經存在。 因此，ShardingSphere-JDBC 並未參考 Proxyless 的設計理念，它是基於當時國內網際網路業務對高併發和低延時的極致效能要求而誕生的。

至於 Database Plus 理念的設計，又何嘗不是如此。伴隨著網際網路的長期快速發展，業務的變化直接推動了技術的積累和成長，ShardingSphere 就是這一過程的最好例證，它的設計方案全部源自於真實業務場景。中國網際網路無疑是全球最全面的場景之一，在此類場景下誕生的設計理念，在全球範圍內也一定擁有十分廣闊的生長空間。

未來規劃

儘管在 Database Plus 理念的實踐道路上越走越遠，但 Apache ShardingSphere 仍然有大量的工作等待完成。資料庫閘道器和異構聯邦查詢，是完善 Database Plus 理念的重要功能拼圖。

1. 資料庫閘道器

Apache ShardingSphere 雖然支援異構資料庫的對接，但無法做到資料庫之間方言的相互轉換。在 ShardingSphere 的線路規劃中，SQL 方言轉換是實現資料庫閘道器的重要功能，使用者透過 PostgreSQL 的資料庫協議用 MySQL 方言訪問 MongoDB 將不再是難以實現的任務。

2. 異構聯邦查詢

Apache ShardingSphere 目前僅支援同構資料庫間的聯邦查詢。在 ShardingSphere 的線路規劃中，異構資料庫間的聯邦查詢也將被提上日程。使用者透過一條 SQL 關聯查詢 MySQL 和 HBase 的場景將不再遙遠。

寫在最後

Apache ShardingSphere 社群已在開源領域耕耘了 7 年的時間。長久的堅持，使社群愈加成熟，已呈開放和多元化的勢態。我們誠心誠意地歡迎有開源情懷和編碼熱情的朋友一起參與社群共建。

Apache ShardingSphere 的可插拔架構和資料分片哲學已在學術界獲得廣泛認可。在今年的資料庫領域頂級的會議 ICDE 中，已成功發表論文 “Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding”。

• 連結： ICDE 2022｜Apache ShardingSphere：一個功能全面和可插拔的資料分片平臺
• 專案地址：

歡迎點選連結，瞭解更多內容：

Apache ShardingSphere 官網：

Apache ShardingSphere GitHub 地址：https:

SphereEx 官網：

歡迎新增社群經理微信（ss_assistant_1）加入交流群，與眾多 ShardingSphere 愛好者一同交流。