1. 程式人生 > 實用技巧 >sharding-jdbc(一)

sharding-jdbc(一)

1、ShardingSphere簡介

sharding-jdbc是ShardingSphere的其中一個模組,摘抄官網一段簡介:

(官方中文文件:https://shardingsphere.apache.org/document/current/cn/overview/

ShardingSphere是一套開源的分散式資料庫中介軟體解決方案組成的生態圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(計劃中)這3款相互獨立的產品組成。 他們均提供標準化的資料分片、分散式事務和資料庫治理功能,可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

ShardingSphere定位為關係型資料庫中介軟體,旨在充分合理地在分散式的場景下利用關係型資料庫的計算和儲存能力,而並非實現一個全新的關係型資料庫。 它與NoSQL和NewSQL是並存而非互斥的關係。NoSQL和NewSQL作為新技術探索的前沿,放眼未來,擁抱變化,是非常值得推薦的。反之,也可以用另一種思路看待問題,放眼未來,關注不變的東西,進而抓住事物本質。 關係型資料庫當今依然佔有巨大市場,是各個公司核心業務的基石,未來也難於撼動,我們目前階段更加關注在原有基礎上的增量,而非顛覆。

2、sharding-jdbc簡介

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

  • 適用於任何基於Java的ORM框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
  • 基於任何第三方的資料庫連線池,如:DBCP, C3P0, BoneCP, Druid, HikariCP等。
  • 支援任意實現JDBC規範的資料庫。目前支援MySQL,Oracle,SQLServer和PostgreSQL。

功能列表:

資料分片

  • 分庫 & 分表
  • 讀寫分離
  • 分片策略定製化
  • 無中心化分散式主鍵

分散式事務

  • 標準化事務介面
  • XA強一致事務
  • 柔性事務

資料庫治理

  • 配置動態化
  • 編排 & 治理
  • 資料脫敏
  • 視覺化鏈路追蹤
  • 彈性伸縮(規劃中)

3、sharding-jdbc核心概念

  • 邏輯表(LogicTable):進行水平拆分的時候同一型別(邏輯、資料結構相同)的表的總稱。例:訂單資料根據主鍵尾數拆分為10張表,分別是t_order_0t_order_9,他們的邏輯表名為t_order
  • 真實表(ActualTable):在分片的資料庫中真實存在的物理表。即上個示例中的t_order_0t_order_9
  • 資料節點(DataNode):資料分片的最小單元。由資料來源名稱和資料表組成,例:ds_0.t_order_0
  • 動態表(DynamicTable):邏輯表和物理表不一定需要在配置規則中靜態配置。如,按照日期分片的場景,物理表的名稱隨著時間的推移會產生變化。
  • 繫結表(BindingTable):指分片規則一致的主表和子表。例如: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的條件。故繫結表之間的分割槽鍵要完全相同。

  • 分片鍵(ShardingColumn):分片欄位用於將資料庫(表)水平拆分的欄位,支援單欄位及多欄位分片。例如上例中的order_id。
  • 分片演算法(ShardingAlgorithm):進行水平拆分時採用的演算法,分片演算法需要應用方開發者自行實現,可實現的靈活度非常高。目前提供4種分片演算法。由於分片演算法和業務實現緊密相關,因此並未提供內建分片演算法,而是通過分片策略將各種場景提煉出來,提供更高層級的抽象,並提供介面讓應用開發者自行實現分片演算法。
1、精確分片演算法
對應PreciseShardingAlgorithm,必選,用於處理使用單一鍵作為分片鍵的=與IN進行分片的場景。需要配合StandardShardingStrategy使用。
 
2、範圍分片演算法
對應RangeShardingAlgorithm,可選,用於處理使用單一鍵作為分片鍵的BETWEEN AND進行分片的場景。如果不配置RangeShardingAlgorithm,
SQL中的BETWEEN AND將按照全庫路由處理。需要配合StandardShardingStrategy使用。
3、複合分片演算法 對應ComplexKeysShardingAlgorithm,用於處理使用多鍵作為分片鍵進行分片的場景,包含多個分片鍵的邏輯較複雜,需要應用開發者自行處理其中的複雜度。
需要配合ComplexShardingStrategy使用。
4、Hint分片演算法 對應HintShardingAlgorithm,用於處理使用Hint行分片的場景。需要配合HintShardingStrategy使用。

  • 分片策略(ShardingStrategy):包含分片鍵和分片演算法,由於分片演算法的獨立性,將其獨立抽離。真正可用於分片操作的是分片鍵 + 分片演算法,也就是分片策略。目前提供5種分片策略。
1、標準分片策略
對應StandardShardingStrategy。提供對SQL語句中的=, IN和BETWEEN AND的分片操作支援。StandardShardingStrategy只支援單分片鍵,
提供PreciseShardingAlgorithm和RangeShardingAlgorithm兩個分片演算法。PreciseShardingAlgorithm是必選的,用於處理=和IN的分片。
RangeShardingAlgorithm是可選的,用於處理BETWEEN AND分片,如果不配置RangeShardingAlgorithm,SQL中的BETWEEN AND將按照全庫路由處理。
2、複合分片策略 對應ComplexShardingStrategy。複合分片策略。提供對SQL語句中的=, IN和BETWEEN AND的分片操作支援。ComplexShardingStrategy支援多分片鍵,
由於多分片鍵之間的關係複雜,因此並未進行過多的封裝,而是直接將分片鍵值組合以及分片操作符透傳至分片演算法,完全由應用開發者實現,提供最大的靈活度。
3、行表示式分片策略 對應InlineShardingStrategy。使用Groovy的表示式,提供對SQL語句中的=和IN的分片操作支援,只支援單分片鍵。對於簡單的分片演算法,可以通過簡單的配置使用,
從而避免繁瑣的Java程式碼開發,如: t_user_$->{u_id % 8} 表示t_user表根據u_id模8,而分成8張表,表名稱為t_user_0到t_user_7。 4、Hint分片策略 對應HintShardingStrategy。通過Hint而非SQL解析的方式分片的策略。 5、不分片策略 對應NoneShardingStrategy。不分片的策略。

4、sharding-jdbc架構圖:

由圖可知,在sql執行過程中需要經過幾個過程:

例如現在有一條查詢語句:

select * from t_user where id=10

進行了分庫分表操作,2個庫ds0,ds1,採用的分片鍵為id,邏輯表為t_user,真實表為t_user_0、t_user_1兩張表,分庫、分表演算法為均為取餘(%2)。

  • sql解析:通過解析sql語句提取分片鍵列與值進行分片,例如比較符 =、in 、between and,及查詢的表等。
  • sql改寫:根據解析結果,及採用的分片邏輯改寫sql,上例經過sql改寫後,真實語句為:
select * from t_user_0 where id=10
  • sql路由:找到sql需要去哪個庫、哪個表執行語句,上例sql根據採用的策略可以得到將在ds0庫,t_user_0表執行語句。
  • sql執行:執行改寫後的sql。
  • 結果歸併:當我們執行某些複雜語句時,sql可能會在多個庫、多個表中執行,sql分別對應執行後會對結果集進行歸併操作,得到最終的結果。

原文連結:https://blog.csdn.net/u013308490/article/details/94598606