分庫分表之第三篇

分庫分表之第三篇

• 3. Sharding-JDBC執行原理
• 3.1 基本概念
• 3.2. SQL解析
• 3.3.SQL路由
• 3.4. SQL改寫
• 3.6.結果歸併
• 3.7 總結

 

3. Sharding-JDBC執行原理

3.1 基本概念

在瞭解Sharding-JDBC的執行原理前，須要瞭解如下概念 ：
邏輯表
水平拆分的數據表的總稱。例 ：訂單數據表根據主鍵尾數拆分爲1-張表，分別是t_order_0、t_order_1到t_order_9，他們的邏輯表名爲t_order。
真實表
在分片的數據庫中真實存在的物理表。即上個實例中的t_order_0到t_order_9。
數據節點
數據分片的最小物理單元。由數據源名稱和數據表組成，例如 ：ds_0.t_order_0。
綁定表
指分片規則一致的主表和子表。例如 ：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); 

廣播表
指全部的分片數據源中都存在的表，表結構和表中的數據在每一個數據庫中均徹底一致。適用於數據量不大且須要與海量數據的表進行關聯查詢的場景，例如 ：字典表。
分片鍵
用於分片的數據庫字段，是將數據庫（表）水平拆分的關鍵字段。例如 ：將訂單表中的訂單主鍵的尾數取模分片，則訂單主鍵爲分片字段。SQL中若是無分片字段，將執行全路由，性能較差。除了對單分片字段的支持，Sharding-JDBC也支持根據多個字段進行分片。
分片算法
經過分片算法將數據分片，支持經過=、BETWZEEN和IN分片。分片算法須要應用方開發者自行實現，可實現的靈活度很是高。包括 ：精確分片算法、範圍分片算法、複合分片算法等。例如 ：where order_id = ？將採用精確分片算法，where order_id in （？，？，？）將採用精確分片算法，where order_id BETWEEN ？and ？將採用範圍分片算法，複合分片算法用於分片鍵有多個複雜狀況。
分片策略
包含分片鍵和分片算法，因爲分片算法的獨立性，將其獨立抽離。真正可用於分片操做的是分片鍵 + 分片算法，也就是分片策略。內置的分片策略大體可分爲尾數取模、哈希、範圍、標籤、時間等。由用戶方配置的分片策略則更加靈活，經常使用的使用行表達式配置分片策略，它採用Groovy表達式表示 ：如 ：t_user_$->{u_id % 8}表示t_user表根據u_id摸8，而分紅8張表，表名稱爲t_user_0到t_user_7。
自增主鍵生成策略
經過在客戶端生成自增主鍵替換以數據庫原生自增主鍵的方式，作到分佈式主鍵無重複。

3.2. SQL解析

當Sharding-JDBC接受到一條SQL語句時，會陸續執行SQL解析 =》查詢優化 =》SQL路由 =》SQL改寫 =》結果歸併，最終返回執行結果。

SQL解析過程分爲詞法解析和語法解析。詞法解析器用於將SQL拆解爲不可再分的院子符號，稱爲Token。並根據不一樣數據庫方言所提供的字典，將其歸類爲關鍵字、表達式、字面量和操做符。再使用語法解析器將SQL轉換爲抽象語法樹。
例如，如下SQL：

SELECT id, name FROM t_user WHERE status = 'ACTIVE' AND age > 18 

解析以後的爲抽象語法樹見下圖 ：

爲了便於理解，抽象語法樹中的關鍵字的Token用綠色表示，變量的Token用紅色表示，灰色表示須要進一步拆分。
最後，經過對抽象語法樹的遍歷去提煉分片所需的上下文，並標記有可能須要SQL改寫（後邊介紹）的位置。供分片使用的解析上下文包含查詢選擇項（Select Items）、表信息（Table）、分片條件（Sharding Condition）、自增主鍵信息（Auto increment Primary Key）、排序信息（Order By）、分組信息（Group By）以及分頁信息（Limit、Rownum、Top）。

3.3.SQL路由

SQL路由就是把針對邏輯表的數據操做映射到對數據結點操做的過程。
根據解析上下文匹配數據庫和表的分片策略，並生成路由路徑。對於攜帶分片鍵的SQL，根據分片鍵操做符不一樣能夠劃分爲單片路由（分片鍵的操做符是等號）、多片路由（分片鍵的操做符是IN）和範圍路由（分片鍵的操做符是BETWEEN），不攜帶分片鍵的SQL則採用廣播路由。根據分片鍵進行路由的場景可分爲直接路由、標準路由、笛卡爾積路由等。
標準路由
標準路由是Sharding-JDBC最爲推薦使用的分片方式，它的使用範圍是不包含關聯查詢或僅包含綁定表之間關聯查詢的SQL。當分片運算符是等於號時，路由結果將落入單庫（表），當分片運算符是BETWEEN或IN時，則路由結果不必定落入惟一的庫（表），所以這條邏輯SQL最終可能被拆分爲多條用於執行的真實SQL。舉例說明，若是按照order_id的奇數和偶數進行數據分片，一個單表查詢的SQL以下 ：

SELECT * FROM t_order WHERE order_id IN (1, 2); 

那麼路由的結果應爲 ：

SELECT * FROM t_order_0 WHERE order_id IN (1, 2); SELECT * FROM t_order_1 WHERE order_id IN (1, 2); 

綁定表的關聯查詢與單表查詢複雜度和性能至關。舉例說明，若是一個包含綁定表的關聯查詢的SQL以下 ：

SELECT * FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE order_id IN (1, 2); 

那麼路由的結果應爲 ：

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); 

能夠看到，SQL拆分的數目與單表是一致的。
笛卡爾路由
笛卡爾路由是最複雜的狀況，它沒法根據綁定表的關係定位分片規則，所以非綁定表之間的關聯查詢須要拆解爲笛卡爾積組合執行。若是上個示例中的SQL並未配置綁定表關係，那麼路由的結果應爲 ：

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); SELECT * FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); SELECT * FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE order_id IN (1, 2); 

笛卡爾路由查詢性能較低，需謹慎使用。
全庫表路由
對於不攜帶分片鍵的SQL，則採用廣播路由的方式。根據SQL類型又能夠劃分爲全庫表路由、全庫路由、全實例路由、單播路由和阻斷路由這5種類型。其中全庫表路由用於處理對數據庫中與其邏輯表相關的全部真實表的操做，主要包括不帶分片鍵的DQL（數據查詢）和DML（數據操縱），以及DDL（數據定義）等。例如 ：

SELECT * FROM t_order WHERE good_prority IN (1, 10); 

則會遍歷全部數據庫中的全部表，逐一匹配邏輯表和真實表名，可以匹配得上則執行。路由後成爲

SELECT * FROM t_order_0 WHERE good_prority IN (1, 10); SELECT * FROM t_order_1 WHERE good_prority IN (1, 10); SELECT * FROM t_order_2 WHERE good_prority IN (1, 10); SELECT * FROM t_order_3 WHERE good_prority IN (1, 10); 

3.4. SQL改寫

工程師面向邏輯表書寫的SQL，並不可以直接在真實的數據庫中執行，SQL改寫用於將邏輯SQL改寫爲在真實數據庫中能夠正確執行的SQL。
如一個簡單的例子，若邏輯SQL爲 ：

SELECT order_id FROM t_order WHERE order_id=1; 

假設該SQL配置分片鍵order_id，而且order_id=1的狀況，將路由至分片表1。那麼改寫以後的SQL應該爲 ：

SELECT order_id FROM t_order_1 WHERE order_id=1; 

再好比，Sharding-JDBC須要在結果歸併時獲取相應數據，但該數據並未能經過查詢的SQL返回。這種狀況主要是針對GROUP BY和ORDER BY。結果歸併時，須要根據GROUP_BY和ORDER_BY的字段項進行分組和排序，但若是原始SQL的選擇項中若並未包含分組項或排序項，則須要對原始SQL進行改寫。先看一下原始SQL中帶有結果歸併所需信息的場景 ：

SELECT order_id, user_id FROM t_order ORDER BY user_id; 

因爲user_id進行排序，在結果歸併中須要可以獲取到user_id的數據，而上面的SQL是可以獲取到user_id獲取的，所以無需補列。
若是選擇項中不包含結果歸併時所需的列，則須要進行補列，如如下SQL ：

SELECT order_id FROM t_order ORDER BY user_id; 

因爲原始SQL中並不包含須要在結果歸併中須要獲取的user_id，所以須要對SQL進行補列改寫。補列以後的SQL

SELECT order_id, user_id AS ORDER_BY_DERIVED_0 FROM t_order ORDER BY user_id; 

3.6.結果歸併

將從各個數據節點獲取的多數據結果集，組合成爲一個結果集並正確的返回至請求客戶端，稱爲結果歸併。
Sharding-JDBC支持的結果歸併從功能上可分爲遍歷、排序、分組、分頁和聚合5種類型，它們是組合而非互斥的關係。
歸併引擎的總體結構劃分以下圖 。

結果歸併從結構劃分可分爲流式歸併、內存歸併和裝飾者歸併。流式歸併和內存歸併是互斥的，裝飾者歸併能夠在流式歸併和內存歸併之上作進一步的處理。
內存歸併很容易理解，他是將全部分片結果集的數據都遍歷並存儲在內存中，再經過統一的分組、排序以及聚合等計算以後，再將其封裝成爲逐條訪問的數據結果集返回。

流式歸併是指每一次從數據庫結果集中獲取到的數據，都可以經過遊標逐條獲取的方式返回正確的單條數據，它與數據庫原生的返回結果集的方式最爲契合。
下邊舉例說明排序歸併的過程，以下圖是一個經過分數進行排序的示例圖，它採用流式歸併方式。圖中展現列3張表返回的數據結果集，每一個數據結果集已經根據分數排序完畢，可是3個數據結果集之間是無序的。將3個數據結果集的當前遊標指向的數據值進行排序，並放入優先級隊列，t_score_0的第一個數據值最大，t_score_2的第一個數據值次之，t_score_1的第一個數據值最小，所以優先級隊列根據t_score_0、t_score_2和t_score_1的方式排序隊列。

下圖則展示了進行next調用的時候，排序歸併是如何進行的。經過圖中咱們能夠看到，當進行第一次next調用時，排在隊列首位的t_score_0將會被彈出隊列，而且將當前遊標指向的數據值（也就是100）返回至查詢客戶端，而且將遊標下移一位以後，從新放入優先級隊列。而優先級隊列也會根據t_score_0的當前數據結果集指向遊標的數據值（這裏是90）進行排序，根據當前數值，t_score_0排列在隊列的最後一位。以前隊列中排名第二的t_score_2的數據結果集則自動排在隊列首位。
在進行第二次next時，只須要將目標排列在隊列首位的t_score_2彈出隊列，而且將其數據結果集遊標指向的值返回至客戶端，並下移遊標，繼續加入隊列排隊，以此類推。當一個結果集中已經沒有數據了，則無需再次加入隊列。

能夠看到，對於每一個數據結果集中的數據有序，而多數據結果集總體無序的狀況下，Sharding-JDBC無需將全部的數據都加載至內存便可排序。它使用的是流式歸併的方式，每次next僅獲取惟一正確的一條數據，極大的節省了內存的消耗。

裝飾者歸併是對全部的結果集歸併進行統一的功能加強，好比歸併時須要聚合SUM前，在進行聚合計算前，都會經過內存歸併或流式歸併查詢出結果集。所以，聚合歸併是在以前介紹的歸併類型之上追加的歸併能力，即裝飾者模式。

3.7 總結

經過以上內容介紹，相信你們已經瞭解到Sharding-JDBC基礎概念、核心功能以及執行原理。基礎概念 ：邏輯表、真實表、數據節點、綁定表、廣播表、分片鍵、分片算法、分片策略、主鍵生成策略核心功能 ：數據分片、讀寫分離執行流程 ：SQL解析 =》查詢優化 =》SQL路由 =》SQL改寫 =》SQL執行 =》結果歸併