StoneDB 是一款兼容 MySQL 的開源 HTAP 數(shù)據(jù)庫。StoneDB 的整體架構(gòu)分為三層，分別是應(yīng)用層、服務(wù)層和存儲引擎層。應(yīng)用層主要負責客戶端的連接管理和權(quán)限驗證；服務(wù)層提供了 SQL 接口、查詢緩存、解析器、優(yōu)化器、執(zhí)行器等組件；Tianmu 引擎所在的存儲引擎層是 StoneDB 的核心，數(shù)據(jù)的組織和壓縮、以及基于知識網(wǎng)格的查詢優(yōu)化均是在 Tianmu 引擎實現(xiàn)。

本文主要為大家介紹 StoneDB 的讀操作、寫操作執(zhí)行過程，方便大家了解引擎架構(gòu)、內(nèi)部邏輯和各個功能模塊。

Tianmu 引擎架構(gòu)

1.Tianmu 存儲引擎在 Server 組件中的位置

2.Tianmu 引擎架構(gòu)圖

3.Tianmu 引擎各個模塊介紹

Tianmu Parser

解析客戶端傳來的 SQL ，進行關(guān)鍵字提取、解析，生成解析樹。解析的詞包括 select、update、delete、or、group by 等，對不支持的語法會向客戶端拋出異常：ERROR：You have an error in your SQL syntax.

比如，執(zhí)行如下語句：

在分析器中就通過語義規(guī)則器將 select、from、where 這些關(guān)鍵詞提取和匹配出來， MySQL 會自動判斷關(guān)鍵詞和非關(guān)鍵詞，將用戶的匹配字段和自定義語句識別出來。這個階段也會做一些校驗，比如校驗當前數(shù)據(jù)庫是否存在 user 表，同時假如 user 表中不存在 userId 這個字段同樣會報錯：unknown column in field list.

解析入口：

Tianmu Optimizer

對于來自客戶端的請求，首先由查詢優(yōu)化器進行基于知識網(wǎng)格的優(yōu)化，產(chǎn)生執(zhí)行計劃后再交給執(zhí)行引擎去處理。基于知識網(wǎng)格中的信息進行粗糙集（Rough Set）構(gòu)建，并確定此次請求所需使用到的數(shù)據(jù)包。

優(yōu)化入口：

Insert Buffer

InnoDB 的 insert buffer 是為輔助索引的插入做的優(yōu)化設(shè)計，而 Tianmu 的 insert buffer 是為整張表的插入做的優(yōu)化設(shè)計。當向表插入數(shù)據(jù)時，數(shù)據(jù)先暫存到 Tianmu 的 insert buffer，然后再從 insert buffer 批量刷新到磁盤，從系統(tǒng)的表現(xiàn)來看是吞吐量提高了。如果不經(jīng)過 insert buffer，而是直接寫入磁盤，由于 Tianmu 不支持事務(wù)，只能一行接著一行往磁盤寫入，系統(tǒng)的吞吐量是不高的，插入效率固然不高。Tianmu 的 insert buffer 由變量 stonedb_insert_delayed 控制，默認為 on 表示開啟。

插入緩存入口：

Knowledge Grid Manager

Tianmu 引擎利用知識網(wǎng)格架構(gòu)來對查詢優(yōu)化器、計劃執(zhí)行和壓縮算法等提供支持。知識網(wǎng)格是 Tianmu 引擎進行快速數(shù)據(jù)查詢的關(guān)鍵，在查詢計劃分析與構(gòu)建過程中，通過知識網(wǎng)格可以消除或大量減少需要解壓的數(shù)據(jù)塊，降低 IO 消耗，提高查詢響應(yīng)時間和網(wǎng)絡(luò)利用率。對于大部分統(tǒng)計/聚合性查詢，Tianmu 引擎往往只需要使用知識網(wǎng)格就能返回查詢結(jié)果（而不需要讀取數(shù)據(jù)）， 這種情況下在 1s 時間內(nèi)就可以返回查詢結(jié)果。

入口函數(shù)：

Knowledge Grid

Knowledge Grid，即知識網(wǎng)格，是 Tianmu 引擎進行快速數(shù)據(jù)查詢的關(guān)鍵，在查詢計劃分析與構(gòu)建過程中，通過知識網(wǎng)格可以消除或大量減少需要解壓的數(shù)據(jù)塊，降低 IO 消耗，提高查詢響應(yīng)時間和網(wǎng)絡(luò)利用率。?

KN Node

Knowledge Node（KN Node），即知識節(jié)點，除了基礎(chǔ)元數(shù)據(jù)外，還包括數(shù)據(jù)特征以及更深度的數(shù)據(jù)統(tǒng)信息，知識節(jié)點在數(shù)據(jù)查詢/裝載過程中會動態(tài)計算。

DPN

Data Pack Node（DPN），即數(shù)據(jù)包節(jié)點，又叫元數(shù)據(jù)節(jié)點（Metadata Node，MD Node），與數(shù)據(jù)包（DP）之間保持一一對應(yīng)關(guān)系，數(shù)據(jù)包節(jié)點中包含了其對應(yīng)數(shù)據(jù)包的元數(shù)據(jù)信息。

數(shù)據(jù)結(jié)構(gòu)：

獲取DPN：

Data Pack

Data Pack（DP），即數(shù)據(jù)包，數(shù)據(jù)包用于存放實際數(shù)據(jù)，是最底層的數(shù)據(jù)存儲單元，每列按照65536行切分成一個數(shù)據(jù)包。每個數(shù)據(jù)包比列更小，具有更高的壓縮比，而每個數(shù)據(jù)包又比每行更大，具有更好的查詢性能。數(shù)據(jù)包是知識網(wǎng)格的解壓縮單元。

?獲取 DP：

CMAP

字符過濾，粗糙集過濾尋找可疑包，生成字符位圖文件。

HIST

整形過濾，粗糙集過濾尋找可疑包，生產(chǎn)直方圖文件。

Replication Manager

StoneDB 復制引擎， StoneDB 本身與常見關(guān)系數(shù)據(jù)庫的高可用架構(gòu)一樣（例如 MySQL ），為了保證強一致性，都會將數(shù)據(jù)更新在 Master 上執(zhí)行，然后通過復制技術(shù)將副本導入到 Slave 節(jié)點。但是與 MySQL 標準的 binlog 復制不同，Tianmu 引擎中存儲的不是原始數(shù)據(jù)，而是壓縮后的數(shù)據(jù)塊（DP） 。此時如果使用 binlog 的方式來進行復制，會導致網(wǎng)絡(luò)上產(chǎn)生大量數(shù)據(jù)流量。為了解決這一點，Tianmu 實現(xiàn)了基于壓縮后數(shù)據(jù)塊的高效數(shù)據(jù)復制支持，相對于 binlog 復制，該技術(shù)可以大大降低網(wǎng)絡(luò)傳輸所需的數(shù)據(jù)量。

Compress&Decompress

數(shù)據(jù)壓縮和解壓模塊，Tianmu 基于列數(shù)據(jù)類型和特定領(lǐng)域優(yōu)化的壓縮算法，因為列中所有記錄的類型一致，可以基于數(shù)據(jù)類型選擇壓縮算法，列中重復值越高壓縮效果越好。除了常規(guī)的壓縮算法外，針對特殊場景提供高效的壓縮算法，如 Email 地址, ?IP 地址, URL 等 。

壓縮入口：

解壓入口：

讀操作執(zhí)行過程

對于來自客戶端的請求，首先由查詢優(yōu)化器進行基于知識網(wǎng)格的優(yōu)化，產(chǎn)生執(zhí)行計劃后再交給執(zhí)行引擎去處理。

?基于知識網(wǎng)格中的信息進行粗糙集（Rough Set）構(gòu)建, 并確定此次請求所需使用到的數(shù)據(jù)包（DP）。

?基于知識節(jié)點和數(shù)據(jù)包節(jié)點，確定查詢涉及到的數(shù)據(jù)包集合，并將數(shù)據(jù)包歸類:

?相關(guān) DP：滿足查詢條件限制的 DP（直接讀取并返回）；

?可疑 DP：DP 中部分數(shù)據(jù)滿足查詢條件（解壓后進行處理再返回）；

?不相關(guān) DP：與查詢條件完全不相關(guān)（直接忽略）。

執(zhí)行計劃構(gòu)建時, 會完全規(guī)避不相關(guān) DP，僅讀取并解壓相關(guān) DP，按照特定情況決定是否讀取可疑 DP。例如，對于一個查詢請求，通過 Knowledge Grid 可以確定 3 個相關(guān)和 1 個可疑 DP。如果此請求包含聚合函數(shù)，此時只需要解壓可疑 DP 并計算聚合值，再結(jié)合 3 個相關(guān) DP 的數(shù)據(jù)包節(jié)點 （DPN）中的統(tǒng)計值即可得出結(jié)果。如果此請求需要返回具體數(shù)據(jù)，那么無論相關(guān) DP 還是可疑 DP，都需要讀取數(shù)據(jù)塊并解壓縮，以獲得結(jié)果集。

?如果查詢請求的結(jié)果可以直接從 DPN 中產(chǎn)生（例如 count, max, min 等操作），則直接返回元信息節(jié)點中的數(shù)據(jù),無需訪問物理數(shù)據(jù)文件。

例如：SELECT count(*) FROM employees where?salary?< 2500：

• 通過 Knowledge Grid 知識，查找包含 salary < 2500 的 DP，此處可以看到只有 A/B/C 三個 DP 涉及到該查詢。

• DP A 與 B 屬于相關(guān) DP， 只需直接從對應(yīng)的 DPN 中獲取 count 值即可。

• DP C 屬于不相關(guān) DP，需要讀取數(shù)據(jù)塊并解壓，執(zhí)行函數(shù)計算后才能返回結(jié)果集。

• 這里只有 DP C 會被讀取并解壓，DP A 與 B 并不消耗 IO 資源。

  
  

執(zhí)行代碼：

寫操作執(zhí)行過程

來自客戶端的請求經(jīng)過連接器、分析器后，由查詢優(yōu)化器進行基于知識網(wǎng)格的優(yōu)化，產(chǎn)生執(zhí)行計劃，經(jīng)過數(shù)據(jù)的壓縮、校驗后再交給執(zhí)行引擎去處理。

Tianmu 執(zhí)行引擎將數(shù)據(jù)組織為兩個層次：物理存儲介質(zhì)上的的數(shù)據(jù)塊（Data Pack，DP），內(nèi)存上的知識網(wǎng)格層（Knowledge Grid，KG）。

入口函數(shù)：

StoneDB 現(xiàn)已開源，歡迎大家在 GitHub 上關(guān)注~

https://github.com/stoneatom/stonedb