下一代資料庫分片架構的演進與革新

重點概述

• 資料分片是指將資料拆分到多臺計算機上，可以是水平分片，也可以是垂直分片；資料分割槽是指將資料拆分為不同的資料子集，但都儲存在單個數據庫例項中。

• Database Plus 概念用於建立分散式資料庫系統，其含義並不僅僅侷限於分片，定位也在資料庫管理系統之上。

• 作為分散式資料庫中介軟體，Apache ShardingSphere 為解決資料分片問題而生，並支援資料加密、影子庫、分散式系統認證和分散式治理等功能。

• ShardingSphere 架構包括四層， 即基礎層、儲存層、功能層及解決方案層。

• ShardingSphere 還持 DistSQL（全稱：Distributed SQL），這種 SQL 方言被用於操作和管理 ShardingSphere 的所有功能。

當下，手機和網際網路已經成為人們的日常工作和生活的必需品，每時每刻都在產生巨量的資料。對於網站和商業服務而言，每週擁有數十億級別的訪問體量並不罕見——當然，這還只是冰山一角。

例如北美的『黑色星期五』和國內的『11.11』等購物狂歡節，則是傳統零售業適應數字化世界的絕佳案例。正如零售行業的轉型一樣，如今的傳統企業必須學會從容應對新的需求和挑戰，才能成功實現其商業目標。

因此，傳統企業必須想清楚一個問題，即在特定節日舉辦線上促銷活動，往往會匯聚難以想象的流量到達資料庫叢集。這對企業的資料庫效能帶來了極大的考驗，能否在段時間內處理掉這些巨量資料，將是直接決定這次線上促銷活動的關鍵因素。

談到資料庫解決方案，不同的商業案例有不同的選擇，包括從 NoSQL 產品（如 MongoDB 、 Cassandra 、 Amazon DynamoDB 等），到 NewSQL 產品（ 如最近流行的 Amazon Aurora 或 CockroachDB ）。但除了這些優秀的解決方案外，一些行業也會考慮在現有資料庫叢集的基礎上進行面向業務的透明化分片操作。根據 DB-Engines 釋出的資料庫流行趨勢排名來看，儘管許多新型資料庫產品正在衝擊全球資料庫市場，但傳統關係型資料庫仍然佔據著相當大的市場份額。

考慮到資料庫所面臨的新挑戰，我們認為，通過新的實用理念，以一種高效且低成本的方式來優化各類資料庫的使用體驗，增強現有資料庫的效能，資料庫透明化分片是最佳答案之一。

DB-Engines 釋出的資料庫流行趨勢排名

說到這個話題，聯想到的最佳技術之一就是將資料分成獨立的行和列。這種將大型資料庫表分成多個小表的做法被稱為分片，根據技術實現的不同，可以被分為垂直分片和水平分片兩種。標記這些表的術語可以主觀地定義為“VS1”代表垂直分片，“HS1”代表水平分片， “1” 代表第一個表或第一個物件集合，以此類推。這些資料子集被稱為該表的原集。

分片和分割槽的區別是什麼？分片和分割槽都是將大型資料集分解成較小的資料集，但兩者區別的關鍵在於，分片意味著資料分佈在多臺計算機上，無論水平分片還是垂直分片。而分割槽則是指資料庫被分成不同的子集，但儲存在一個數據庫中，也被稱為資料庫例項。

由於資料分片是將資料切開並存儲在不同的機器下，因此其具有以下優點：

• 可使多個獨立的資料庫管理系統成為分散式系統

• 擴充套件資料庫系統的儲存容量

• 流量均勻分佈在不同分片上

• 高可用

然而，分片架構並不完美，也具有以下問題：

• 具有複雜的路由/查詢拓撲

• 使分散式資料庫叢集管理複雜化

• 查詢開銷相對較大

• 不完全支援所有本地 SQL。在已有的分散式資料庫系統上採用分片架構還可能會導致 SQL 相容性問題。新建立的分片資料庫後，此前執行良好的 SQL 有可能無法執行。

分片：從一到多

絕大多數情況下，無論技術領域還是生活中，能夠適應各種場合的“銀彈”解決方案是不存在的。因此應在全面分析的基礎上，完全瞭解需求和場景後才能做出最佳選擇。

一般來說，分片架構的優勢是大於其劣勢的。資料庫行業中，許多優秀產品都採用的分片架構，比如 Citus 或 Vitess  。雖有在架構層面上有各自的定義，但其在本質上都是基於資料庫分片架構。

Citus 通過管理協調器（代理）叢集來分佈 PostgreSQL 叢集，而 Vitess 則對 MySQL 進行分片，Citus 和 Vitess 都專注於為傳統但被廣泛應用的關係型資料庫提供高效且低成本的分散式解決方案。實際上，分片架構也是大多數 NoSQL 和 NewSQL 產品的基礎，不過，這就是另一個關於 NoSQL 和 NewSQL 的分片話題。本文重點討論關係型資料庫的分片以及經典分片技術的創新。

資料分片的起因在於資料庫對分散式需求越來越高。隨著業務的發展，越來越多與資料庫相關配套的服務能力開始引起企業的關注，如隱私保護、SQL 審計、租戶、分散式認證等。這些能力無一例外都反映出現實世界對資料庫的新需求。如何處理這些新需求是所有不同型別的資料庫產品不可避免要回答的問題。那，這些問題是否可以通過資料庫分片解決方案來解決？

分片似乎需要進一步發展才能應對這些挑戰，而這就是本文的主題：資料庫分片架構的下一代演進發展，將邁向何方？

我的答案是將 Database Plus 作為建立分散式資料庫系統的指導性概念，其不僅僅是面向分片，更是定位在資料庫系統層面之上。

Database Plus 構想是一種分散式資料庫系統的設計理念，在已經呈現出碎片化趨勢的資料庫之上建立使用和互動的標準層與生態層，在資料庫之上構建全新的連線關係。通過提供統一標準化的資料庫使用規範，Database Plus 理念可面向上層應用提供無感知的資料增強服務，是所有應用和資料庫之間的互動直接面向 Database Plus 所構建的標準層，從而遮蔽資料庫碎片化對上層業務帶來的差異化影響。最終形成一個生態環境，其中的應用程式只需要與標準化服務對話，而非為不同資料庫提供不同的服務。

這個想法是由 Apache ShardingSphere PMC 提出，在歷經一年左右時間釋出的 5.0.0 GA 版本中在架構層實現了 Database Plus 理念。

早在 3.x 和 4.x 釋出階段，Apache ShardingSphere 就被定義為分散式資料庫中介軟體（分片架構），只用於解決分片問題。但隨著社群的發展，越來越多開發者的加入，Apache ShardingSphere 已侷限於分片領域，資料加密、影子庫、分散式認證、分散式治理等眾多功能的上線正在將 Apache ShardingSphere 推向解決資料庫行業新挑戰的最前沿。這些功能的變化無一例外都超出了傳統分片概念的範疇，所以，分片只是 Database Plus 的其中一部分。

Apache ShardingSphere 的 Database Plus 架構演變之路

Apache ShardingSphere 作為案例支援了我的論點：簡單而經典的分片架構，其潛力和所能實現的可能將會大大超出預期。其核心機制通過代理或驅動程式引導所有流量，然後通過解析 SQL 並定位每個資料庫的位置，它就能輕而易舉地執行以下任務：

• 理解使用者的資料期望

• 劫持並修改流量

• 將修改後的查詢重新路由到某個資料庫

• 合併或修改某一個結果的元資料和資料

• 監控計算節點（代理）和儲存節點（資料庫）的狀態

• 收集分散式系統的變化或常規資訊

• 使用機器學習（Machine Learning）技術提供定製化建議

正是基於這些核心作業，Apache ShardingSphere 的產品才能解決使用者面臨的資料庫產品痛點。

從最初的分片功能到資料加密 、影子庫 、分散式認證、分散式治理等都是基於以上的必要步驟。Apache ShardingSphere 的架構基於 Database Plus 概念，所有的功能都以外掛形式呈現，在這個分散式系統中使用者可根據自身需要隨時新增或刪除功能外掛，因此這些增強功能具有極強的靈活性。有些使用者可能只想使用資料庫分片功能，而有些使用者可能只需要資料加密。使用者需求是多種多樣且從未停止變化的，為此，Database Plus 可以完全面向用戶定製，並不斷開發新的外掛（功能），使其能夠具體靈活地逐一滿足使用者的不同需求。

架構

ShardingSphere 的四層架構如下圖 1 所示：

ShardingSphere 的四層架構

基礎層:提供驅動或代理等多種接入端，靈活地滿足使用者在不同場景下的需求。

儲存層：支援所有資料庫功能，並有可能支援更多的功能。

功能層：提供各種滿足使用者需求的功能外掛，使用者可高度靈活地選擇和組合外掛。

解決方案層：為終端使用者提供面向具體行業（包括金融、電子商務和娛樂等）和麵向特定場景的標準化產品解決方案（如分散式資料庫解決方案、資料庫加密解決方案或資料庫閘道器解決方案）。

多接入端混合模式生產可用

ShardingSphere-JDBC 和 ShardingSphere-Proxy 經過五年的打磨和測試，目前已經可以投入生產使用，很多社群使用者已提供了相關的使用者案例，其可行性也已經得到了驗證。

不同 ShardingSphere 客戶端之間可共享核心功能，因此使用者可以選擇混合部署模式，平衡查詢效能和管理便利性（如下圖 2 所示）。

ShardingSphere-JDBC 和 ShardingSphere-Proxy 的混合部署

DistSQL 用於標準化叢集管理

Apache ShardingSphere 社群實現了一種新的 SQL 方言，即 DistSQL （全稱為 Distributed SQL），用於操作管理 ShardingSphere 的所有功能。

SQL 是與資料庫互動的傳統標準方法。然而，在分散式資料庫系統中有許多新的功能驅動我們創造出一種 SQL 方言來配置和使用這些新功能。

DistSQL 允許使用者使用類似 SQL 的命令來建立、修改或刪除分散式資料庫和表，或者對資料進行加解密，此外包括上文提到的所有功能都可以用 DistSQL 來進行。

使用中的 DistSQL

分散式治理能力

分散式資料庫系統治理能力是減輕分散式叢集管理難題的必要條件。在計算和儲存分離的 ShardingSphere 生態系統中，在 5.0 新版本中對分散式治理能力進行了極大增強：

• 資料庫（即儲存節點）和 Proxy/JDBC（即計算節點）的分散式治理

• 線上使用者元資料 DDL 變更

• 開/關執行中的儲存節點和計算節點

• 熔斷及停用

• 高可用

此外，計劃中的新功能分散式也將在近期釋出。

ShardingSphere 的分散式治理

部署注意事項

雖然上面列舉了許多 Apache ShardingSphere 的優點，但是也有一些限制需要提前考慮。在部署 ShardingSphere 之前，請仔細考慮以下事項：

• 一些複雜的本地 SQL，特別是關聯不同分片的 SQL 語句，在執行可能存在耗時長、成本高等相關問題。所以建議採用面向業務的分片策略來預防這類情況的發生，避免處理過於的複雜 SQL。

• Proxy 模式會產生更多地網路資源開銷，因此官方更推薦使用 混合模式部署 。

• 分散式事務會大大降低 TPS 或 QPS。

• 在分片之間獲得一致的時間點快照是很有挑戰性的。

實際案例

本節將提供兩個實際案例，演示如何用可連線 ShardingSphere 生態中一切元素的 DistSQL 建立一個分散式資料庫和加密表。

分散式資料庫解決方案

這一部分將通過案例演示如何利用 DistSQL 來建立一個分散式資料庫。使用者和應用程式可訪問 Proxy 來建立邏輯表（即分散式表），該表已經在不同的伺服器之間被分片，使用者沒有必要關注這些分片，應用程式會自動操作管理該邏輯表。

前提條件：

• 部署 MySQL 例項並建立兩個 MySQL 資料庫

• 部署 ShardingSphere Proxy

過程：

1. 登入代理 CLI 需執行此 SQL 命令：

mysql -h127.0.0.1 -uroot -P3307 -proot

2. 使用 DistSQL 註冊兩個 MySQL 資料庫。

ADD RESOURCE ds_0( HOST=127.0.0.1, PORT=3306, DB=demo_ds_0, USER=root, PASSWORD=root );

ADD RESOURCE ds_1 ( HOST=127.0.0.1, PORT=3306, DB=demo_ds_1, USER=root, PASSWORD=root ) ;

1. 使用 DistSQL 建立分片規則

CREATE SHARDING TABLE RULE t_order( RESOURCES(ds_0,ds_1), SHARDING_COLUMN=order_id, TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=4)), GENERATED_KEY(COLUMN=order_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123))) );

1. 基於前一步的分片規則去建立分片表

CREATE TABLE `t_order` ( `order_id` int NOT NULL, `user_id` int NOT NULL, `status` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

1. 顯示資源、分片資料庫及分片表

sql SHOW SCHEMA RESOURCES;

SHOW DATABASES;

SHOW TABLES;

1. 顯示分片表

SHOW TABLES;

以下是 MySQL 中的表:

以下是 ShardingSphere-Proxy 中的表：

1. 刪除分片表

DROP TABLE t_order;

資料加密

這個例子將演示如何用 DistSQL 建立加密表。在 Apache ShardingSphere 中，是通過 ShardingSphere-Proxy 來實現資料加解密的功能，因此應用程式不需要進行任何編碼重構，只需將明文傳送到 Proxy 端就會被加密，之後 Proxy 端會將加密文字重新發送到資料庫中。此外，使用者也可自定義配置選擇哪張表的哪一列，以及何種加密演算法來實現資料加密。

前提條件：

• 部署 MySQL 例項並建立兩個 MySQL 資料庫

• 部署 ShardingSphere-Proxy

過程：

1. 登入 Proxy CLI 需執行以下命令：

mysql -h127.0.0.1 -uroot -P3307 -proot

1. 通過 DistSQL 新增資源。

ADD RESOURCE ds_0 ( HOST=127.0.0.1, PORT=3306, DB=ds_0, USER=root, PASSWORD=root );

1. 建立加密規則。

CREATE ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=AES,PROPERTIES('aes-key-value'='123456abc')))));

SHOW ENCRYPT TABLE RULE t_encrypt;

1. 建立加密表

CREATE TABLE `t_encrypt` ( `order_id` int NOT NULL, `user_plain` varchar(45) DEFAULT NULL, `user_cipher` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

以下是 MySQL 中的結果：

在此表中插入資料：

INSERT INTO `t_encrypt` VALUES(1,"abc");

What exactly happened in MySQL:

在 MySQL 中實現的內容包括：

1. 修改加密規則

ALTER ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=MD5)) ));

SHOW ENCRYPT RULES;

1. 刪除加密規則

DROP ENCRYPT RULE t_encrypt;

基於 Database Plus 理念，將分片、加密等其它功能部署在資料庫之上的生態中，不需對底層資料庫做出任何改變，操作和使用成本都較低，對上層使用者完全無感知，能夠消除使用者對底層資料架構不穩定的但又，進而減輕企業採用全新分散式資料庫過程中所帶來的沉重負擔，是滿足使用者不斷變化的切實有效方法之一。

我作為 Apache ShardingSphere PMC 撰寫此文可能會顯得有些偏心，但我之所以選擇全身心投入到這個開源專案中，是因為它具有極大的創新潛力去應用於各類生產場景中，從而能夠解決現實世界資料庫領域的相關問題。

縱觀過去的職業生涯，在這個世界上網際網路普及率最高的社會之一——中國，我一直在管理和利用公司的大資料，因此我很清楚不斷調整的生產需求以及海量業務資料帶來的挑戰，對於當下已有資料庫解決方案之間存在的矛盾與距離。

當然我也並沒有絕對地說，Database Plus 就是解決雲時代所面臨新資料挑戰的最佳或唯一的方法，但的確可以將其視為一種具有前景的創新解決方案。

最後，我想再分享關於資料分片的看法。分片是解決網際網路發展所帶來新挑戰的眾多方法之一，專家們可能會說，資料庫分片架構已經過時了，但實際卻並非如此。分片架構可能聽起來不那麼高大上，也沒有沒有其他解決方案的花裡胡哨，但它兼具有效性和實用性的特點是毋庸置疑的。

近期分片架構實現了重大的創新，分片架構的發展超出了以往的想象。也許這就是為什麼分片架構在希望實現高度可擴充套件性的區塊鏈公司中越來越受歡迎的原因。

作者

潘娟 | Trista Pan

SphereEx 聯合創始人兼 CTO; AWS Data Hero; Apache ShardingSphere PMC 成員; 中國木蘭開源社群導師。曾任京東科技高階 DBA，負責京東數科的智慧資料庫平臺的設計開發，目前專注於分散式資料庫和中介軟體生態系統，以及開源社群運營。致力於開源事業，作為 Apache ShardingSphere 排名第二的貢獻者，曾獲得 “2020 年中國開源先鋒 ” 和 “2021 年中國 OSCAR 開源先鋒”榮譽，經常受邀參加資料庫及資料庫架構領域相關會議併發言分享個人見解。