Taurus2.0垃圾回收compactor優化方案

1.?? 簡介

TaurusDB是一種基于MySQL的計算與存儲分離架構的云原生數據庫，一個集群中包含多個存儲幾點，每個存儲節點包含多塊磁盤，每塊磁盤對應一個或者多個slicestore的內存邏輯結構來管理. 在taurus的slicestore中將數據劃為多個slice進行管理，每個slice的大小是10G，Taurus架構圖如下：

TauruDB的存儲層支持append-only寫和隨機讀，最小數據存儲邏輯單元為plog，每個slice中包含多個plog，默認每個plog的大小為64M。slice中的plog主要用來存放page。Plog中存放中不同版本的page，有些老page已經過期，需要刪除；有些page是新page，需要被保留下來。

Compator主要用來清理plog中過期的page，把一個plog上所有沒有過期的page搬移到一個新plog，老的plog刪除掉。

Compactor的任務需要頻繁訪問內存中索引結構和讀寫plog中的page頁，這兩部分都屬于整個系統中關鍵資源，鎖競爭的壓力比較大，會直接影響性能，所以compactor的優化方案主要圍繞減少內存訪問和磁盤IO，需要考慮以下幾個點：

A、 選取的清理的plog集最優問題，每次回收需要搬運有效page，搬運的有效page數越少，磁盤IO就越小。如何每次調度都選取到垃圾量最大的一批plog；

B、 垃圾量是否分布均勻，如何讓垃圾集中到一起，回收垃圾集中的plog，提高回收效率；

C、 回收周期是固定的，怎么樣保證在每個周期內，都能取到最優plog集；

2.?? 關鍵點1-全局調度

全局調度的方案增大plog垃圾量的排序范圍，從slice的范圍增大到slicestore的范圍。因為考慮到后面需要針對單個磁盤進行“加速回收”，所以不擴大到一個存儲節點的全局范圍。

全局調度方案按照slicestore來選取回收plog，先遍歷所有的slicestore，然后在slicestore內部進行垃圾量排序，選取最多的若干個plog進行回收；

優點：有效避免一個slicestore中由于垃圾分布不均勻引起的plog的無效搬運，減少對plog的讀寫產生的IO；

缺點：排序范圍增大后，排序算法會增加CPU的消耗；

3.?? 關鍵點2-排序算法優化

原始方案中在slice內部對plog按照垃圾量排序采用C++標準庫排序（std::sort），該算法內部基于快速排序、插入排序和堆排序實現。原始方案中每個slice中最多存有160個plog，小數據量的排序或許效率影響不大，但是一個slicestore中存儲成百上千的slice，排序算法的效率問題就值得關注。

Taurus設計了一種topN算法，能夠提升該場景下的效率。假設需要在n個元素中選取m個最大的元素，兩種算法的時間復雜度和空間復雜度：

C++標準庫排序時間復雜度為O(nlogn)，空間復雜度為O(nlogn)；

topN算法排序時間復雜度為O(nlogm),空間復雜度為O(1);

Compactor應用場景中，n和m相差幾個數量級，topN算法在時間和空間上都更具優勢。

優點：減少時間復雜度和空間復雜度；

4.?? 關鍵點3-調度數優化

公共線程池分配給compactor的線程數是固定的，每個周期調度器生成一次任務。原始方案中compactor的每次生成的任務數由slice個數決定，會導致任務隊列中的任務數過多或者過少。過多的話會失去時效性，也就是說plog的垃圾量會隨著時間改變，如果在隊列個等待執行的時間太長，可能就不是當前最高垃圾量的plog，同時一次挑選的plog個數太多，會增加算法的時間和空間復雜度；過少的話，compactor線程沒有跑滿，會導致垃圾回收速度降低。

調度數優化也是基于全局調度優化，調度策略只需要保證在一個調度周期內，任務隊列中任務數剛好滿足compactor線程執行。假設有8個slicestore，分配了24個執行線程，每個線程每個調度周期完成一個plog的回收，則每個調度周期每個slicestore只需要生成3個任務。

調度數優化即記錄公共線程池中正在執行和準備執行的任務數，跟據記錄決定本輪調度生成多少個回收任務，從而保證執行線程剛好夠用，且不多不少。

優點：保證垃圾回收速度，最優回收的plog集，有效的減少page的搬運量。

5.?? 關鍵點4-冷熱分區優化

在數據庫系統中，數據的更新并不是相同頻率，一些數據頁更新或者寫入會更加頻繁（例如系統頁），這部分頁面被稱作熱頁，另外一些更新不頻繁的稱作冷頁。如果把冷頁和熱頁混合放到一起，就會導致更高的寫放大。舉個簡單的例子，假設有100個熱頁和10個冷頁，冷頁基本不更新但是每次垃圾回收，都需要重復把冷頁搬運一次。如果把冷頁單獨寫入一個plog，那么在垃圾回收階段，就可以減少重復搬運這部分冷頁，達到減少IO放大的效果。

優點：提高垃圾回收的效率和速度。

缺點：需要額外的內存記錄熱度信息。

6.?? 關鍵點5-磁盤逃生優化

為了后臺線程比如備份、快照、垃圾回收、頁面回放等線程有足夠的磁盤空間運行，在磁盤容量使用到達一定閾值，會置Full標志位，同時停止前臺IO。在極端情況下，磁盤使用到閾值前臺IO會出現斷崖式下跌為零：

為了避免在磁盤容量達到一定閾值之后前臺IO完全停止，在磁盤使用率未達到閾值時，就應該有相應的處理機制。比如說在磁盤使用率未達閾值時，增加如下處理：

A、 降低前臺IO，減少磁盤的壓力；

B、 加速垃圾回收，也就是TaurusDB中的compactor機制；

A點不涉及compactor的功能，所以本文先不涉及，下面主要介紹加速機制。

6.1 修改寫IO優先級

Compactor作為后臺線程，考慮到整個系統的效率，正常運行時plog寫IO優先級默認為low。在加速回收階段，plog的IO需要修改為high。

6.2 提高執行速度

前文可知，公共線程池為compactor分配固定數目執行線程，而且運行過程中只支持擴容不支持恢復。如果壓縮其他后臺任務的執行線程，對整個系統的影響太大，量也不易控制。所以不考慮。

考慮到過程中不能擴容，那就初始化就擴容，通過控制調度任務數控制任務執行速度。例如，假設compactor的運行線程在正常場景下為4個，加速狀態下需要增加到8個。可以在公共線程池中先分配8個線程，在正常場景下，控制任務隊列為4個，另外4個線程處于wait狀態，只會占用文件句柄，并不影響CPU。而在加速狀態下，控制任務隊列中的任務數為8，就可以實現上述的加速邏輯。

6.3 總結

提升寫IO的優先級能夠加速page的搬運，提升垃圾回收速度。通過控制調度任務數控制任務執行速度卻很難控制很精準，上下會有一定的小波動。

7.?? 總結

以上1-4個方案能有效的減少page的搬運數，達到減少IO的目的。方案5能夠處理磁盤容量緊急情況。目前本地測試，在500G的小數據集情況下，IO放大能減少到原來的1/6。系統資源占用減少到原來的1/3。

云數據庫 GaussDB(for MySQL) 數據庫 軟件開發云 磁盤 存儲

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。