分庫分表之第三篇

来源:https://www.cnblogs.com/haizai/archive/2019/12/22/12081107.html
-Advertisement-
Play Games

分庫分表之第三篇 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的執行原理前，需要瞭解以下概念 ： ...


分庫分表之第三篇

 

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執行 =》結果歸併


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 圖文結合深入理解 JS 中的 this 值
    圖文結合深入理解 JS 中的 this 值 在 中最常見的莫過於函數了，在函數(方法)中 的出現頻率特別高，那麼 到底是什麼呢，今天就和大家一起學習總結一下 中的 。 1. 初探this 在 中是一個關鍵字，不是變數也不是屬性名， 中不允許給this賦值。 它是函數運行時，在函數體內部自動生成的一個 ...
  • 聊一聊 JS 輸出為 [object object] 是怎麼回事？
    聊一聊 JS 輸出為 [object object] 是怎麼回事？ 今天在學習ES6中的 數據類型時，在寫demo時控制台輸出為 ，當時有點疑惑，查閱了相關資料後搞清楚了其中的原因。 在解釋之前，由於有些小伙伴可能還沒有接觸過ES6，所以先說一下上面用到的ES6的一些特性： const: 聲明一個常 ...
  • ES6+轉ES5（webpack+babel、指定多個js文件、自動註入）
    接續上篇ES6+轉ES5，本篇將使用webpack和babel將多個不同目錄下指定的多個ES6+語法的js文件編譯為ES5，並將編譯後的文件配置註入對應的html文件。 所需環境node、npm、設置淘寶鏡像請參考上篇進行安裝，地址：https://www.cnblogs.com/puyongson ...
  • html5+css3的神奇搭配
    1.關於浮動 浮動的元素會脫離標準文檔流（float）,從而不占據空間，實現了一行排列多個元素的效果 ，但是又導致上級元素height消失，處理這種情況的方法就是有兩種： 1.第一種在css里寫個偽類，哪些地方需要清除浮動，直接調用類名。 .clearfix::after{ display: blo ...
  • 基於jquery的提示框JavaScript 插件，類Bootstrap
    基於jquery的提示框JavaScript 插件，類Bootstrap [TOC] 源碼 github地址： "https://github.com/Ethan Xie/message" 實例 通過此此插件可以為提示欄添加自動/點擊消失的功能 用法 需引入message.css與message.j ...
  • vscode 同步擴展插件
    第一步： 在 VSCode 中，安裝用於同步配置的插件 settings sync 第二步：將 VSCode 配置上傳到 GitHub 完成這一步需要 GitHub token 和 GitHub gist 進入GitHub 設置界面 & 創建 GitHub token 在這裡找到之前你上傳 VSCo ...
  • 聊一聊 webpack 中的 preloading 和 Prefetching
    聊一聊 webpack 中的 preloading 和 Prefetching 提到 Preloading 和 Prefetching 就不得不先說一下代碼分割，通過下麵的例子我們來說明為什麼需要代碼分割？ 在首次訪問時， index.js 文件的大小為 2 MB，需要載入的大小是 2 MB 業務代 ...
  • Jenkins多環境持續集成架構實踐
    使用jenkins實現多分支、多環境，多項目、多套配置文件、多編程語言的應用"一鍵發佈"和"一鍵回滾"的架構實踐 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類