ShardingSphere 看這一篇就夠了

2021 年 7 月 4 日
筆記
資料庫

1、什麼是shardingSphere

Apache ShardingSphere 是一套開源的分散式資料庫中間件解決方案組成的生態圈，它由 JDBC、Proxy 和 Sidecar（規劃中）這 3 款相互獨立，卻又能夠混合部署配合使用的產品組成。它們均提供標準化的數據分片、分散式事務和資料庫治理功能，可適用於如 Java 同構、異構語言、雲原生等各種多樣化的應用場景。

Apache ShardingSphere 定位為關係型資料庫中間件，旨在充分合理地在分散式的場景下利用關係型資料庫的計算和存儲能力，而並非實現一個全新的關係型資料庫。它通過關注不變，進而抓住事物本質。關係型資料庫當今依然佔有巨大市場，是各個公司核心業務的基石，未來也難於撼動，我們目前階段更加關注在原有基礎上的增量，而非顛覆。

Apache ShardingSphere 5.x 版本開始致力於可插拔架構，項目的功能組件能夠靈活的以可插拔的方式進行擴展。目前，數據分片、讀寫分離、多數據副本、數據加密、影子庫壓測等功能，以及 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 與協議的支援，均通過插件的方式織入項目。開發者能夠像使用積木一樣訂製屬於自己的獨特系統。Apache ShardingSphere 目前已提供數十個 SPI 作為系統的擴展點，仍在不斷增加中。

ShardingSphere 已於2020年4月16日成為 Apache 軟體基金會的頂級項目。

1、sharding-JDCB

定位為輕量級Java框架，在Java的JDBC層提供的額外服務。它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅動，完全兼容JDBC和各種ORM框架。

適用於任何基於JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
支援任何第三方的資料庫連接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
支援任意實現JDBC規範的資料庫。目前支援MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92標準的資料庫。

2、sharding-proxy

定位為透明化的資料庫代理端，提供封裝了資料庫二進位協議的服務端版本，用於完成對異構語言的支援。目前先提供MySQL/PostgreSQL版本，它可以使用任何兼容MySQL/PostgreSQL協議的訪問客戶端(如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。

嚮應用程式完全透明，可直接當做MySQL/PostgreSQL使用。
適用於任何兼容MySQL/PostgreSQL協議的的客戶端。

3、sharding-sidecar

定位為Kubernetes的雲原生資料庫代理，以Sidecar的形式代理所有對資料庫的訪問。通過無中心、零侵入的方案提供與資料庫交互的的嚙合層，即Database Mesh，又可稱數據網格。

Database Mesh的關注重點在於如何將分散式的數據訪問應用與資料庫有機串聯起來，它更加關注的是交互，是將雜亂無章的應用與資料庫之間的交互有效的梳理。使用Database Mesh，訪問資料庫的應用和資料庫終將形成一個巨大的網格體系，應用和資料庫只需在網格體系中對號入座即可，它們都是被嚙合層所治理的對象。

4、三個組件的對比

5、混合架構

Sharding-JDBC採用無中心化架構，適用於Java開發的高性能的輕量級OLTP應用；Sharding-Proxy提供靜態入口以及異構語言的支援，適用於OLAP應用以及對分片資料庫進行管理和運維的場景。

ShardingSphere是多接入端共同組成的生態圈。通過混合使用Sharding-JDBC和Sharding-Proxy，並採用同一註冊中心統一配置分片策略，能夠靈活的搭建適用於各種場景的應用系統，架構師可以更加自由的調整適合於當前業務的最佳系統架構。

2、核心概念

1、邏輯表

水平拆分的資料庫（表）的相同邏輯和數據結構表的總稱。例：訂單數據根據主鍵尾數拆分為10張表，分別是t_order_0到t_order_9，他們的邏輯表名為t_order。

2、真實表

在分片的資料庫中真實存在的物理表。即上個示例中的t_order_0到t_order_9。

3、數據節點

數據分片的最小單元。由數據源名稱和數據表組成，例：ds_0.t_order_0。

4、綁定表

指分片規則一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，則此兩張表互為綁定表關係。綁定表之間的多表關聯查詢不會出現笛卡爾積關聯，關聯查詢效率將大大提升。舉例說明，如果SQL為：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在不配置綁定表關係時，假設分片鍵order_id將數值10路由至第0片，將數值11路由至第1片，那麼路由後的SQL應該為4條，它們呈現為笛卡爾積：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置綁定表關係後，路由的SQL應該為2條：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

其中t_order在FROM的最左側，ShardingSphere將會以它作為整個綁定表的主表。所有路由計算將會只使用主表的策略，那麼t_order_item表的分片計算將會使用t_order的條件。故綁定表之間的分區鍵要完全相同。

5、廣播表

指所有的分片數據源中都存在的表，表結構和表中的數據在每個資料庫中均完全一致。適用於數據量不大且需要與海量數據的表進行關聯查詢的場景，例如：字典表。

6、分片鍵

用於分片的資料庫欄位，是將資料庫(表)水平拆分的關鍵欄位。例：將訂單表中的訂單主鍵的尾數取模分片，則訂單主鍵為分片欄位。 SQL中如果無分片欄位，將執行全路由，性能較差。除了對單分片欄位的支援，ShardingSphere也支援根據多個欄位進行分片。

7、分片演算法

通過分片演算法將數據分片，支援通過=、>=、<=、>、<、BETWEEN和IN分片。分片演算法需要應用方開發者自行實現，可實現的靈活度非常高。

目前提供4種分片演算法。由於分片演算法和業務實現緊密相關，因此並未提供內置分片演算法，而是通過分片策略將各種場景提煉出來，提供更高層級的抽象，並提供介面讓應用開發者自行實現分片演算法。

精確分片演算法

對應PreciseShardingAlgorithm，用於處理使用單一鍵作為分片鍵的=與IN進行分片的場景。需要配合StandardShardingStrategy使用。
範圍分片演算法

對應RangeShardingAlgorithm，用於處理使用單一鍵作為分片鍵的BETWEEN AND、>、<、>=、<=進行分片的場景。需要配合StandardShardingStrategy使用。
複合分片演算法

對應ComplexKeysShardingAlgorithm，用於處理使用多鍵作為分片鍵進行分片的場景，包含多個分片鍵的邏輯較複雜，需要應用開發者自行處理其中的複雜度。需要配合ComplexShardingStrategy使用。
Hint分片演算法

對應HintShardingAlgorithm，用於處理使用Hint行分片的場景。需要配合HintShardingStrategy使用。

8、分片策略

包含分片鍵和分片演算法，由於分片演算法的獨立性，將其獨立抽離。真正可用於分片操作的是分片鍵 + 分片演算法，也就是分片策略。目前提供5種分片策略。

標準分片策略

對應StandardShardingStrategy。提供對SQL語句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支援。StandardShardingStrategy只支援單分片鍵，提供PreciseShardingAlgorithm和RangeShardingAlgorithm兩個分片演算法。PreciseShardingAlgorithm是必選的，用於處理=和IN的分片。RangeShardingAlgorithm是可選的，用於處理BETWEEN AND, >, <, >=, <=分片，如果不配置RangeShardingAlgorithm，SQL中的BETWEEN AND將按照全庫路由處理。
複合分片策略

對應ComplexShardingStrategy。複合分片策略。提供對SQL語句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支援。ComplexShardingStrategy支援多分片鍵，由於多分片鍵之間的關係複雜，因此並未進行過多的封裝，而是直接將分片鍵值組合以及分片操作符透傳至分片演算法，完全由應用開發者實現，提供最大的靈活度。
行表達式分片策略

對應InlineShardingStrategy。使用Groovy的表達式，提供對SQL語句中的=和IN的分片操作支援，只支援單分片鍵。對於簡單的分片演算法，可以通過簡單的配置使用，從而避免繁瑣的Java程式碼開發，如: t_user_$->{u_id % 8} 表示t_user表根據u_id模8，而分成8張表，表名稱為t_user_0到t_user_7。
Hint分片策略

對應HintShardingStrategy。通過Hint指定分片值而非從SQL中提取分片值的方式進行分片的策略。
不分片策略

對應NoneShardingStrategy。不分片的策略。

Tags: 資料庫