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），即資料包，資料包用於存放實際資料，是最底層的數據儲存單元，每列按照65536行切分成一個數據包。每個資料包比列更小，具有更高的壓縮比，而每個資料包又比每行更大，具有更好的查詢效能。資料包是知識網格的解壓縮單元。

獲取 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

StoneDB 現已開源，歡迎大家在 GitHub 上關注~

http://github.com/stoneatom/stonedb

新增微信小助手，進群與數百位資料庫從業者共話真正的HTAP