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

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

Tianmu 引擎架構(gòu)

1.Tianmu 存儲(chǔ)引擎在 Server 組件中的位置

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

3.Tianmu 引擎各個(gè)模塊介紹

Tianmu Parser

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

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

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

解析入口：

Tianmu Optimizer

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

優(yōu)化入口：

Insert Buffer

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

插入緩存入口：

Knowledge Grid Manager

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

入口函數(shù)：

Knowledge Grid

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

KN Node

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

DPN

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

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

獲取DPN：

Data Pack

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

?獲取 DP：

CMAP

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

HIST

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

Replication Manager

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

Compress&Decompress

數(shù)據(jù)壓縮和解壓模塊，Tianmu 基于列數(shù)據(jù)類(lèi)型和特定領(lǐng)域優(yōu)化的壓縮算法，因?yàn)榱兄兴杏涗浀念?lèi)型一致，可以基于數(shù)據(jù)類(lèi)型選擇壓縮算法，列中重復(fù)值越高壓縮效果越好。除了常規(guī)的壓縮算法外，針對(duì)特殊場(chǎng)景提供高效的壓縮算法，如 Email 地址, ?IP 地址, URL 等 。

壓縮入口：

解壓入口：

讀操作執(zhí)行過(guò)程

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

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

?基于知識(shí)節(jié)點(diǎn)和數(shù)據(jù)包節(jié)點(diǎn)，確定查詢(xún)涉及到的數(shù)據(jù)包集合，并將數(shù)據(jù)包歸類(lèi):

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

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

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

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

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

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

• 通過(guò) Knowledge Grid 知識(shí)，查找包含 salary < 2500 的 DP，此處可以看到只有 A/B/C 三個(gè) DP 涉及到該查詢(xún)。

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

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

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

  
  

執(zhí)行代碼：

寫(xiě)操作執(zhí)行過(guò)程

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

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

入口函數(shù)：

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

https://github.com/stoneatom/stonedb