
StoneDB 的整體架構分為三層,分別是應用層、服務層和存盤引擎層,應用層主要負責客戶端的連接管理和權限驗證;服務層提供了 SQL 介面、查詢快取、決議器、優化器、執行器等組件;Tianmu 引擎所在的存盤引擎層是 StoneDB 的核心,資料的組織和壓縮、以及基于知識網格的查詢優化均是在 Tianmu 引擎實作,下面為大家詳細介紹 StoneDB 整體架構中的主要特性,
列式存盤
StoneDB 創建的表在磁盤上是以列模式進行存盤的,由于關系型資料庫中每一列的資料型別都相同,所以這種連續的空間存盤與行式存盤相比,更加能夠實作資料的高壓縮比,在讀取資料方面,如果只想查詢一個欄位的結果,在行式存盤中,引擎層向服務層回傳的是一整行的資料,需要消耗更多的網路帶寬和 IO,而列式存盤只需要回傳一個欄位,極大減少了網路帶寬和 IO 的消耗,另外,列式存盤無需再為列創建索引和維護索引,
| id | name | age |
|---|---|---|
| 1 | Jack | 37 |
| 2 | Rose | 18 |
| 3 | Jason | 26 |

資料壓縮
上面提到同一資料型別的列存盤在一起,能夠實作資料的高壓縮比,StoneDB 會根據不同的資料型別選擇不同的壓縮演算法,目前支持的壓縮演算法主要有 PPM、LZ4、B2、Delta 等,資料被壓縮后,資料量變得更小,在讀取資料時,對網路帶寬和磁盤 IO 的壓力也就越小,由于列式存盤相比行式存盤有十倍甚至更高的壓縮比,StoneDB 可以節省大量的存盤空間,降低存盤成本,
知識網格管理
當表的資料量達到千萬、億級,在做統計分析類查詢時,使用 MySQL 的 InnoDB 存盤引擎或其它關系型資料庫的行式存盤引擎可能需要幾分鐘到幾十分鐘才能得到結果集,這是因為基于成本的優化器需要根據表或者索引的統計資訊生成執行計劃,然后再去讀取資料,中間程序會發生 IO,如果統計資訊不準,生成了一個錯誤的執行計劃,那么可能會發生更多的 IO,而 StoneDB 的 Tianmu 引擎在相同的資料量下,比 MySQL 的 InnoDB 存盤引擎或或其它關系型資料庫的行式存盤引擎要快數十倍,Tianmu 引擎除了列式存盤、資料壓縮特性外,還有知識網格技術,在了解知識網格前,需要了解以下幾個基本概念,
Data Pack
資料包用于存放實際資料,是最底層的資料存盤單元,每列按照65536行切分成一個資料包,每個資料包比列更小,具有更高的壓縮比,而每個資料包又比每行更大,具有更好的查詢性能,資料包是知識網格的解壓縮單元,
粗糙集是一門數學學科,用來研究不完整的資料,不精確的知識表達、學習、歸納等的一套理論,在 StoneDB 中,粗糙集用于對資料包的劃分,根據 SQL 的查詢條件的資料在資料包中的確認范圍,資料包分為以下幾類:
1)不相關的資料包:表示不滿足查詢條件的資料包,這類資料包直接被忽略,
2)相關的資料包:表示滿足查詢條件的資料包,如果要查詢相關的資料包里面的具體資料,需要對資料包進行解壓縮,如果根據資料包的元資料節點就能得到資料,那么就不需要解壓縮資料包,
3)可疑的資料包:表示資料包中的資料部分滿足查詢條件,需要進一步解壓縮資料包才能得到滿足條件的資料,

Data Pack Node
資料包節點也稱為元資料節點,記錄了每個資料包中列的最大值、最小值、平均值、總和、總記錄數、null值的數量、壓縮方式、占用的位元組數,每一個元資料節點對應一個資料包,
Knowledge Node
元資料節點的上一層是知識節點,除了記錄資料包之間或者列之間關系的元資料集合,比如資料包的最小值與最大值范圍、列之間的關聯關系外,還記錄了資料特征以及更深度的統計資訊,大部分的知識節點資料是裝載資料的時候產生的,另外一部分是查詢的時候產生的,
知識節點的3種基本型別:
1)Histogram
資料型別為整型、日期型、浮點型的列的統計值以直方圖的形式存在,將一個資料包的最小值到最大值之間分為1024段,每段占用一個 bit,如果資料包中的實際值處于段中的范圍,則標記為1,否則標記為0,Histogam 在資料被加載時自動創建,
如下的例子中,說明資料包中有值落在0100和102301102400兩個區間,
| 0?100 | 101?200 | 201?300 | ... | 102301?102400 |
|---|---|---|---|---|
| 1 | 0 | 0 | ... | 1 |
如果想要執行以下 SQL:
select * from table where id>199 and id<299;
通過直方圖可知,這個查詢沒有在這個資料包命中,即當前資料包不滿足查詢條件,這個資料包直接被丟棄,
2)Character Map
資料型別為字串的列的字符映射表,統計當前資料包內 1~64 長度中 ASCII 字符是否存在,如果存在,則標記為1,否則標記為0,字符檢索時,按照字符順序依次對比字符標識值即可知道該資料包是否包含匹配資料,Character Map 在資料被加載時自動創建,
如下的例子中,說明 A 在字串的第1個和第64個位置,
| Char/Char pos | 1 | 2 | ... | 64 |
|---|---|---|---|---|
| A | 1 | 0 | ... | 1 |
| B | 0 | 1 | ... | 0 |
| C | 1 | 1 | ... | 1 |
| ... | ... | ... | ... | ... |
3)Pack to Pack
包對包關系表示不同表的兩個列之間的等值映射表,并以二進制矩陣的形式進行存盤,如果符合表關聯條件,則標記為1,否則標記為0,包對包關系能幫助在表關聯查詢的時候快速判斷出符合查詢條件的資料包,從而提升表關聯查詢的效率,表關聯查詢時,Pack to Pack 被自動創建,
如下的例子中,表關聯的查詢條件是"A.C=B.D",在 A.C1 這個資料包中,只有 B.D2 和 B.D5 這兩個資料包中有符合表關聯條件的值,
| B.D1 | B.D2 | B.D3 | B.D4 | B.D5 | |
|---|---|---|---|---|---|
| A.C1 | 0 | 1 | 0 | 0 | 1 |
| A.C2 | 1 | 1 | 0 | 0 | 0 |
| A.C3 | 1 | 1 | 0 | 1 | 1 |
Knowledge Grid
知識網格由元資料節點和知識節點組成,在做統計分析類查詢時,StoneDB 根據知識網格技術過濾掉不相關的資料包,如果只剩下相關資料包,那么只需要讀取元資料就能回傳查詢結果,這樣就消除了解壓縮資料包的程序和降低 IO 消耗,提高了查詢回應時間和網路利用率,
接下來,我們通過一個例子來理解一個查詢陳述句在存盤引擎層使用知識網格技術的查詢優化程序,
有如下的查詢陳述句和資料包節點的資料值分布范圍,
select min(t2.D) from t1,t2 where t1.B=t2.C and t1.A>15;
| Min. | Max. | |
|---|---|---|
| t1.A1 | 1 | 9 |
| t1.A2 | 10 | 30 |
| t1.A3 | 40 | 100 |
- 根據列 A 的 DPN 可知,t1.A1 屬于不相關的資料包,t1.A2 屬于可疑的資料包,t1.A3 屬于相關的資料包,這一步就過濾掉資料包 t1.A1,

| t2.C1 | t2.C2 | t2.C3 | t2.C4 | t2.C5 | |
|---|---|---|---|---|---|
| t1.B1 | 1 | 1 | 1 | 0 | 1 |
| t1.B2 | 0 | 1 | 0 | 0 | 0 |
| t1.B3 | 1 | 1 | 0 | 0 | 1 |
- 第一步已經過濾掉資料包 t1.A1,這一步就不需要對 t1.B1 和 t2.C1 做關聯對比,根據包對包關系的映射表可知,這一步過濾掉資料包 t2.C3 和 t2.C4,那么滿足關聯條件的資料包有 t2.C2 和 t2.C5,

| Min. | Max. | |
|---|---|---|
| t2.D1 | 0 | 500 |
| t2.D2 | 101 | 440 |
| t2.D3 | 300 | 6879 |
| t2.D4 | 1 | 432 |
| t2.D5 | 3 | 100 |
- 第一步和第二步已經過濾掉 D1、D3、D4,那么只剩下 D2 和D5,根據列 D 的 DPN 可知,D5 的最大值100小于 D2 的最小值101,這一步過濾掉資料包 D2,最后只剩下資料包 D5,根據元資料得到 D5 的最小值3,

高性能匯入
StoneDB 提供獨立的資料匯入客戶端,支持不同的資料源環境,支持多語言架構,資料在匯入前,首先會進行預處理,如資料壓縮和知識節點的構建,資料經過預處理后,進入存盤引擎無需再次執行決議、資料驗證以及事務處理等操作,
于StoneDB的任何問題,都可以加我V咨詢:StoneDB_2022 ,
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/502172.html
標籤:其他
