什麼是 Chunk
TiDB 2.0 中,我們引入了一個叫 Chunk 的資料結構用來在記憶體中儲存內部資料,用於減小記憶體分配開銷、降低記憶體佔用以及實現記憶體使用量統計/控制,其特點如下:
-
只讀
-
不支援隨機寫
-
只支援追加寫
-
列存,同一列的資料連續的在記憶體中存放
Chunk 本質上是 Column 的集合,它負責連續的在記憶體中儲存同一列的資料,接下來我們看看 Column 的實現。
1. Column
Column 的實現參考了 Apache Arrow,Column 的程式碼在 這裡。根據所儲存的資料型別,我們有兩種 Column:
-
定長 Column:儲存定長型別的資料,比如
Double
、Bigint
、Decimal
等 -
變長 Column:儲存變長型別的資料,比如
Char
、Varchar
等
哪些資料型別用定長 Column,哪些資料型別用變長 Column 可以看函式 addColumnByFieldType 。
Column 裡面的欄位非常多,這裡先簡單介紹一下:
-
length
用來表示這個 Column 有多少行資料。
-
nullCount
用來表示這個 Column 中有多少
NULL
資料。 -
nullBitmap
用來儲存這個 Column 中每個元素是否是
NULL
,需要特殊注意的是我們使用 0 表示NULL
,1 表示非NULL
,和 Apache Arrow 一樣。 -
data
儲存具體的資料,不管定長還是變長的 Column,所有的資料都儲存在這個 byte slice 中。
-
offsets
給變長的 Column 使用,儲存每個資料在 data 這個 slice 中的偏移量。
-
elemBuf
給定長的 Column 使用,當需要讀或者寫一個資料的時候,使用它來輔助 encode 和 decode。
1.1 追加一個定長的非 NULL 值
追加一個元素需要根據具體的資料型別呼叫具體的 append 方法,比如: appendInt64、appendString 等。
一個定長型別的 Column 可以用如下圖表示:
我們以 appendInt64 為例來看看如何追加一個定長型別的資料:
-
使用
unsafe.Pointer
把要 append 的資料先複製到 elemBuf 中; -
往 nullBitmap 中 append 一個 1。
上面第 1 步在 appendInt64
這個函式中完成,第 2、3 步在 finishAppendFixed 這個函式中完成。其他定長型別元素的追加操作非常相似,感興趣的同學可以接著看看 appendFloat32、appendTime 等函式。
1.2 追加一個變長的非 NULL 值
而一個變長的 Column 可以用下圖表示:
我們以 appendString 為例來看看如何追加一個變長型別的資料:
-
把資料先 append 到 data 中;
-
往 nullBitmap 中 append 一個 1;
上面第 1 步在 appendString 這個函式中完成,第 2、3 步在 finishAppendVar 這個函式中完成。其他邊長型別元素的追加操作也是非常相似,感興趣的同學可以接著看看 appendBytes、appendJSON 等函式。
1.3 追加一個 NULL 值
我們使用 appendNull 函式來向一個 Column 中追加一個 NULL
值:
-
往 nullBitmap 中 append 一個 0;
-
如果是定長 Column,需要往 data 中 append 一個 elemBuf 長度的資料,用來佔位;
-
如果是變長 Column,不用往 data中 append 資料,而是往 offsets 中 append 當前 data 的 size 作為下一個元素在 data 中的起始點。
2. Row
如上圖所示:Chunk 中的 Row 是一個邏輯上的概念:Row 中的資料儲存在 Chunk 的各個 Column 中,同一個 Row 中的資料在記憶體中沒有連續儲存在一起,我們在獲取一個 Row 物件的時候也不需要進行資料拷貝。提供 Row 的概念是因為運算元執行過程中,大多數情況都是以 Row 為單位訪問和運算元據,比如聚合,排序等。
Row 提供了獲取 Chunk 中資料的方法,比如 GetInt64、GetString、GetMyDecimal 等,前面介紹了往 Column 中 append 資料的方法,獲取資料的方法可以由 append 資料的方法反推,程式碼也比較簡單,這裡就不再詳細介紹了。
3. 使用
目前 Chunk 這個包只對外暴露了 Chunk, Row 等介面,而沒有暴露 Column,所以,寫資料呼叫的是在 Chunk 上實現的對 Column 具體函式的 warpper,比如 AppendInt64;讀資料呼叫的是在 Row 上實現的 Getxxx 函式,比如 GetInt64。
執行框架簡介
1. 老執行框架簡介
在重構前,TiDB 1.0 中使用的執行框架會不斷呼叫 Child 的 Next 函式獲取一個由 Datum 組成的 Row(和剛才介紹的 Chunk Row 是兩個資料結構),這種執行方式的特點是:每次函式呼叫只返回一行資料,且不管是什麼型別的資料都用 Datum 這個結構體來封裝。
這種方法的優點是:簡單、易用。缺點是:
-
如果處理的資料量多,那麼框架上的函式呼叫開銷將會非常大;
-
Datum 佔用的無效記憶體太大,記憶體浪費比較多(存一個 8 位元組的整數需要 56 位元組);
-
Datum 沒有重用,golang 的 gc 壓力大;
-
每個 Operator 一次只輸出一行資料,要進行更加快取友好的計算、更充分的利用 CPU 的 pipeline 非常困難;
-
Datum 中的 interface 型別的資料,統計它的記憶體使用量比較困難。
2. 新執行框架簡介
在重構後,TiDB 2.0 中使用的執行框架會不斷呼叫 Child 的 NextChunk 函式,獲取一個 Chunk 的資料。
這種執行方式的特點是:
-
每次函式呼叫返回一批資料,資料量由一個叫
tidb_max_chunk_size
的 session 變數來控制,預設是 1024 行。因為 TiDB 是一個混合 TP 和 AP 的資料庫,對於 AP 型別的查詢來說,因為計算的資料量大,1024 沒啥問題,但是對於 TP 請求來說,計算的資料量可能比較少,直接在一開始就分配 1024 行的記憶體並不是最佳的實踐( 這裡 有個 github issue 討論這個問題,歡迎感興趣的同學來討論和解決)。 -
Child 把它產出的資料寫入到 Parent 傳下來的 Chunk 中。
這種執行方式的好處是:
-
減少了框架上的函式呼叫開銷。比如同樣輸出 1024 行結果,現在的函式呼叫次數將會是以前的 1/1024。
-
記憶體使用更加高效。Chunk 中的資料組織非常緊湊,存一個 8 位元組的整數幾乎就只需要 8 位元組,沒有其他額外的記憶體開銷了。
-
減輕了 golang 的 gc 壓力。Chunk 佔用的記憶體可以不斷地重複利用,不用頻繁的申請新記憶體,從而減輕了 golang 的 gc 壓力。
-
查詢的執行過程更加快取友好。如我們之前所說,Chunk 按列來組織資料,在計算的過程中我們也儘量按列來計算,這樣既能讓一列的資料儘量長時間的待在 Cache 中,減輕 Cache Miss 率,也能充分利用起 CPU 的 pipeline。這一塊在後續的原始碼分析文章中會有詳細介紹,這裡就不再展開了。
-
記憶體監控和控制更加方便。Chunk 中沒有使用任何 interface,我們能很方便的直接獲取一個 Chunk 當前所佔用的記憶體的大小,具體可以看這個函式:MemoryUsage。關於 TiDB 記憶體控制,我們也會在後續文章中詳細介紹,這裡也不再展開了。
3. 新舊執行框架效能對比
採用了新的執行框架後,OLAP 型別語句的執行速度、記憶體使用效率都有極大提升,從 TPC-H 對比結果 看,效能有數量級的提升。
作者:張建