背景介紹
StoneDB 是一款兼容 MySQL 的開源 HTAP 資料庫，StoneDB 的整體架構分為三層，分別是應用層、服務層和存盤引擎層，應用層主要負責客戶端的連接管理和權限驗證；服務層提供了 SQL 介面、查詢快取、決議器、優化器、執行器等組件；Tianmu 引擎所在的存盤引擎層是 StoneDB 的核心，資料的組織和壓縮、以及基于知識網格的查詢優化均是在 Tianmu 引擎實作，
本文主要為大家介紹 StoneDB 的讀操作、寫操作執行程序，方便大家了解引擎架構、內部邏輯和各個功能模塊，
一、Tianmu 引擎架構
1 Tianmu 存盤引擎在 Server 組件中的位置
2 Tianmu 引擎架構圖
3 Tianmu 引擎各個模塊介紹
Tianmu Parser
決議客戶端傳來的 SQL ，進行關鍵字提取、決議，生成決議樹，決議的詞包括 select、update、delete、or、group by 等，對不支持的語法會向客戶端拋出例外：ERROR：You have an error in your SQL syntax.
比如，執行如下陳述句：
select * from user where userId =1234;
在分析器中就通過語意規則器將 select、from、where 這些關鍵詞提取和匹配出來， MySQL 會自動判斷關鍵詞和非關鍵詞，將用戶的匹配欄位和自定義陳述句識別出來，這個階段也會做一些校驗，比如校驗當前資料庫是否存在 user 表，同時假如 user 表中不存在 userId 這個欄位同樣會報錯：unknown column in field list.
決議入口：
parse_sql()
Tianmu Optimizer
對于來自客戶端的請求，首先由查詢優化器進行基于知識網格的優化，產生執行計劃后再交給執行引擎去處理，基于知識網格中的資訊進行粗燥集（Rough Set）構建，并確定此次請求所需使用到的資料包，
優化入口：
optimize_select()
Insert Buffer
InnoDB 的 insert buffer 是為輔助索引的插入做的優化設計，而 Tianmu 的 insert buffer 是為整張表的插入做的優化設計，當向表插入資料時，資料先暫存到 Tianmu 的 insert buffer，然后再從 insert buffer 批量重繪到磁盤，從系統的表現來看是吞吐量提高了，如果不經過 insert buffer，而是直接寫入磁盤，由于 Tianmu 不支持事務，只能一行接著一行往磁盤寫入，系統的吞吐量是不高的，插入效率固然不高，Tianmu 的 insert buffer 由變數 stonedb_insert_delayed 控制，默認為 on 表示開啟，
插入快取入口：
Engine::insert_buffer
Knowledge Grid Manager
Tianmu 引擎利用知識網格架構來對查詢優化器、計劃執行和壓縮演算法等提供支持，知識網格是 Tianmu 引擎進行快速資料查詢的關鍵，在查詢計劃分析與構建程序中，通過知識網格可以消除或大量減少需要解壓的資料塊，降低 IO 消耗，提高查詢回應時間和網路利用率， 對于大部分統計/聚合性查詢，Tianmu 引擎往往只需要使用知識網格就能回傳查詢結果（而不需要讀取資料）， 這種情況下在 1s 時間內就可以回傳查詢結果，
入口函式：
RCAttr::ApproxAnswerSize
Knowledge Grid
Knowledge Grid，即知識網格，是 Tianmu 引擎進行快速資料查詢的關鍵，在查詢計劃分析與構建程序中，通過知識網格可以消除或大量減少需要解壓的資料塊，降低 IO 消耗，提高查詢回應時間和網路利用率，
KN Node
Knowledge Node（KN Node），即知識節點，除了基礎元資料外，還包括資料特征以及更深度的資料統資訊，知識節點在資料查詢/裝載程序中會動態計算，
DPN
Data Pack Node（DPN），即資料包節點，又叫元資料節點（Metadata Node，MD Node），與資料包（DP）之間保持一一對應關系，資料包節點中包含了其對應資料包的元資料資訊，
資料結構：
struct DPN{}
獲取DPN：
DPN &get_dpn
Data Pack
Data Pack（DP），即資料包，是存盤的最底層，列中每份大小固定的單元組成一個資料塊，
DP 是存盤的最底層，列中每份大小固定的單元組成一個資料塊，資料塊比列更小，具有更好的壓縮比率，又比磁盤默認存盤單元單元更 大,具有更好的查詢性能， 物理資料按固定資料塊存盤 (DP)、 資料塊大小固定(典型值128KB)、優化 IO 效率、提供基于塊 (Block) 的高效壓縮/加密演算法，
獲取 DP：
Pack *get_pack(size_t i)
CMAP
字符過濾，粗糙集過濾尋找可疑包，生成字符位圖檔案，
RSIndex_CMap::RSIndex_CMap;
HIST
整形過濾，粗糙集過濾尋找可疑包，生產直方圖檔案，
RSIndex_Hist::RSIndex_Hist
Replication Manager
StoneDB 復制引擎， StoneDB 本身與常見關系資料庫的高可用架構一樣（例如 MySQL ），為了保證強一致性，都會將資料更新在 Master 上執行，然后通過復制技術將副本匯入到 Slave 節點，但是與 MySQL 標準的 binlog 復制不同，Tianmu 引擎中存盤的不是原始資料，而是壓縮后的資料塊（DP） ，此時如果使用 binlog 的方式來進行復制，會導致網路上產生大量資料流量，為了解決這一點，Tianmu 實作了基于壓縮后資料塊的高效資料復制支持，相對于 binlog 復制，該技術可以大大降低網路傳輸所需的資料量，
Compress&Decompress
資料壓縮和解壓模塊，Tianmu 基于列資料型別和特定領域優化的壓縮演算法，因為列中所有記錄的型別一致，可以基于資料型別選擇壓縮演算法，列中重復值越高壓縮效果越好，除了常規的壓縮演算法外，針對特殊場景提供高效的壓縮演算法，如 Email 地址, IP 地址, URL 等 ，
壓縮入口：
Compress()
解壓入口：
CprsErr Decompress
二、讀操作執行程序
對于來自客戶端的請求，首先由查詢優化器進行基于知識網格的優化，產生執行計劃后再交給執行引擎去處理，
- 基于知識網格中的資訊進行粗燥集（Rough Set）構建, 并確定此次請求所需使用到的資料包（DP），
- 基于知識節點和資料包節點，確定查詢涉及到的資料包集合，并將資料包歸類:
- 相關 DP：滿足查詢條件限制的 DP（直接讀取并回傳）；
- 可疑 DP：DP 中部分資料滿足查詢條件（解壓后進行處理再回傳）
- 不相關 DP：與查詢條件完全不相關（直接忽略），
執行計劃構建時, 會完全規避不相關 DP，僅讀取并解壓相關 DP，按照特定情況決定是否讀取可疑 DP，例如，對于一個查詢請求，通過 Knowledge Grid 可以確定 3 個相關和 1 個可疑 DP，如果此請求包含聚合函式，此時只需要解壓可疑 DP 并計算聚合值，再結合 3 個相關 DP 的資料包節點 （DPN）中的統計值即可得出結果，如果此請求需要回傳具體資料，那么無論相關 DP 還是可疑 DP，都需要讀取資料塊并解壓縮，以獲得結果集，
-
如果查詢請求的結果可以直接從 DPN 中產生（例如 count, max, min 等操作），則直接回傳元資訊節點中的資料，無需訪問物理資料檔案，
例如：SELECT count(*) FROM employees where salary < 2500： -
通過 Knowledge Grid 知識，查找包含 salary < 2500 的 DP，此處可以看到只有 A/B/C 三個 DP 涉及到該查詢，
-
DP A 與 B 屬于相關 DP， 只需直接從對應的 DPN 中獲取 count 值即可，
-
DP C 屬于不相關 DP，需要讀取資料塊并解壓，執行函式計算后才能回傳結果集，
-
這里只有 DP C 會被讀取并解壓，DP A 與 B 并不消耗 IO 資源，
執行代碼：
Engine::HandleSelect();
Engine::GetTableShare();
class ColumnShare;
ColumnShare::map_dpn();
ColumnShare::read_meta();
ColumnShare::scan_dpn();
TableShare::TableShare();
RCAttr::RoughCheck;
RSIndex_CMap::RSIndex_CMap;
CprsErr Decompress;
TempTable::SendResult();
三、寫操作執行程序
來自客戶端的請求經過連接器、分析器后，由查詢優化器進行基于知識網格的優化，產生執行計劃，經過資料的壓縮、校驗后再交給執行引擎去處理，
Tianmu 執行引擎將資料組織為兩個層次：物理存盤介質上的的資料塊（Data Pack，DP），記憶體上的知識網格層（Knowledge Grid，KG），
入口函式：
write_row
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/501952.html
標籤：MySQL
下一篇：5.1 主鍵約束