【研發分享】StoneDB如何給Tianmu引擎增加delete功能（調研之旅）

StoneDB 作為開源專案，一直秉持開源開放的基本原則，我們的社區版代碼現在已經完全在 Github 上開源，并不斷提高代碼的可讀友好性，同時，為了讓大家更好地理解我們是如何打造一款一體化 HTAP 開源資料庫的，我們會定期把一些核心技術的研發實作思路分享給大家，也算是拋磚引玉，如果讀者有更好的實作思路，也歡迎與我們溝通，甚至可以參與到我們社區版的開發中~

Tianmu 引擎是 StoneDB 團隊自研的一款列式存盤引擎，在6月初剛開源時，并不支持 delete 功能，對此很多用戶都提出了需求的意見，所以我們當時也把 delete 功能列入到我們的年度 Roadmap里了，預計在10月20號的 StoneDB_5.7_v1.0.1 正式版本中，上線此功能，第一期，我將分享一下對 delete 功能的調研情況，

前置知識：資料庫中洗掉資料的三種方式
以 Mysql 5.7 為例，資料庫洗掉資料的方式一共有三種：

1. delete
2. truncate
3. drop

以上三種方式都可以洗掉資料，但是使用場景是不同的，

對于整個表進行洗掉的執行速度來說：

drop > truncate >> delete

DELETE

delete 是屬于資料庫的 DML 操作語言，一般是根據條件逐行進行洗掉，

使用 delete 洗掉資料時，資料庫只能洗掉資料不能洗掉表的結構，并且會觸發資料庫的事務機制，

delete 執行時，會先將所洗掉資料快取到 rollback segment 中，事務 commit 之后生效，

在 InnoDB 中，使用 delete 其實并不會真正的把資料洗掉，是一種邏輯刪，資料庫底層實際上只是給洗掉的資料做了一個已洗掉的標記，因此，洗掉資料后的表占空間大小和洗掉前是一樣的，

TRUNCATE

truncate 屬于資料庫 DDL 定義語言，不走事務，原資料不放到 rollback segment 中，操作不觸發 trigger，執行后立即生效，無法找回（慎用 洗掉執行后，資料就沒了，不可恢復），

truncate 洗掉表會立刻釋放磁盤空間，truncate table其實有點類似于drop table 然后 create,只不過這個 create table 的程序做了優化，比如表結構檔案之前已經有了等等，所以速度上是接近 drop table 的速度；

DROP

drop 屬于資料庫 DDL 定義語言，同 truncate ，執行后立即生效，無法找回，

drop table table_name立刻釋放磁盤空間，drop 陳述句將洗掉表的結構、被依賴的約束(constraint)、觸發器(trigger)、索引(index)；依賴于該表的存盤程序/函式將保留,但是變為 invalid 狀態，

Tianmu 引擎對 delete 功能的調研
Tianmu 是一個列式存盤引擎，列式存盤的出現主要是為了方便快捷查詢和高效存盤大量同型別的資料而設計的，主要使用場景就是 OLAP，下面是 OLAP場景的部分關鍵特征：

• 絕大多數是讀請求，
• 資料以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新，
• 已添加到資料庫的資料不能修改，
• 對于讀取，從資料庫中提取相當多的行，但只提取列的一小部分，
• 列中的資料相對較小：數字和短字串(例如，每個URL 60個位元組)，
• 處理單個查詢時需要高吞吐量(每臺服務器每秒可達數十億行)，
• 事務不是必須的，
• 對資料一致性要求低，

而 OLAP 場景下，對于資料的 delete 的操作可以說沒有或者頻率很小，列式存盤對比行式存盤來說并不擅長資料的增刪改，如果是為了極致的查詢性能，完全可以舍棄 DML 操作（比如初期的 ClickHouse 也不支持 delete），但是為了功能的完整性，我們初期就放開了 insert 和 update 的功能，不過沒有對 delete 功能進行支持，

隨著用戶的呼聲越來越多，我們開始對各個有列式存盤的資料庫進行了一個調研，如下表所示：

目前行業現狀

通過分析目前行業內支持列式存盤的主流資料庫，大部分都是支持的，就算不支持直接 delete,也是支持 DML 同步的，所以 Tianmu 引擎的 delete 功能確實有必要進行開發支持，

主流列式資料庫的 delete 方案

openGauss

存盤結構

openGauss 列存盤引擎的底層存盤結構與 Tianmu 引擎類似 ，存盤基本單位是CU（Compression Unit，壓縮單元），即表中一列的一部分資料組成的壓縮資料塊，行存引擎中是以行作為單位來管理，而當使用列存盤時，整個表整體被按照不同列劃分為若干個 CU，


每個 CU 對應一個 CUDesc 的記錄，在 CUDesc 里記錄了整個 CU 的事務時間戳資訊、CU 的大小、存盤位置、magic 校驗碼、min/max 等資訊，

每張列存表還配有張 Delta 表，Delta 表自身為行存盤表，當有少量的資料插入到一張列存表時，資料會被暫時放入 Delta 表，等到達閾值或滿足一定條件或操作時再行整合為 CU 檔案，Delta 表可以避免單點資料操作帶來的很重的 CU 操作與開銷，

delete 策略

CU 中資料的洗掉，實際上是標記洗掉，洗掉操作，相當于是更新了 CUDesc 表中 CU 對應 CUDesc 記錄的 delete bitmap（洗掉位圖）結構，標記列中某行對應資料已被洗掉，而 CU 檔案資料不會被更改，這樣可以避免洗掉操作帶來的 IO 放大以及解壓、壓縮的高額 CPU 開銷，這樣的設計，也可以使得對于同一個 CU 的 select（查詢）和 delete（洗掉）互不阻塞，提升并發能力，列存盤 CU 中資料更新，則是遵循 append-only（僅允許追加）原則的，即 CU 檔案僅會向后進行延展擴充，亦或是啟用新的 CU 檔案，而不是在對應行在 CU 中的位置就地更新，

ClickHouse

存盤結構

ClickHouse 支持在建表時，指定將資料按照某些列進行 sort by，排序后，保證了相同 sort key 的資料在磁盤上連續存盤，且有序擺放，在進行等值、范圍查詢時，where 條件命中的資料都緊密存盤在一個或若干個連續的 Block 中，而不是分散的存盤在任意多個 Block， 大幅減少需要 IO 的 block 數量，另外，連續 IO 也能夠充分利用作業系統 page cache的預取能力，減少 page fault，

delete 策略

特點：缺少高頻率，低延遲的修改或洗掉已存在資料的能力，僅能用于批量洗掉或修改資料，

ClickHouse是個分析型資料庫，OLAP場景下，資料一般是不變的，因此 ClickHouse 對 update、delete 的支持是比較弱的，實際上并不支持標準的 update、delete 操作，

ClickHouse 通過 alter 方式實作更新、洗掉，它把 update、delete 操作叫做 mutation(突變)，

標準SQL的更新、洗掉操作是同步的，即客戶端要等服務端回傳執行結果（通常是int值），而ClickHouse的update、delete是通過異步方式實作的，當執行update陳述句時，服務端立即回傳，但是實際上此時資料還沒變，而是排隊等著，

Mutation具體程序

首先，使用where條件找到需要修改的磁區；然后，重建每個磁區，用新的磁區替換舊的，磁區一旦被替換，就不可回退；對于單獨一個磁區，是原子性的；但對于整個 mutation，如果涉及多個磁區，則不是原子性的，

PolarDB In-Memory Column Index

存盤結構

特點：PolarDB 將列存實作為 InnoDB 的二級索引，
在 PolarDB 中所有 Primary Index 和 Secondary Index 都實作為一個 B+Tree，列索引在定義上是一個 Index，但其實是一個虛擬的索引，用于捕獲對該索引覆寫列的增刪改操作，

實作為 InnoDB 二級索引方案的優點：

• 查詢執行器的工程實作非常簡單
• 可以復用 InnoDB 的事務處理框架
• 可以復用 InnoDB 的資料編碼格式
• DDL 陳述句操作非常靈活
• 可以復用 InnoDB 的 Redo 事務日志模塊
• 二級索引與主表有一樣的生命周期，方便管理

PolarDB In-Memory Column Index 的存盤使用了無序且追加寫的格式，

列索引中記錄按 RowGroup 進行組織，每個 RowGroup 中不同的列會各自打包形成 DataPack，

每個 RowGroup 都采用追加寫，分屬每個列的 DataPack 也是采用追加寫模式，

對于一個列索引，只有個 Active RowGroup 負責接受新的寫入，

當該 RowGroup 寫滿之后即凍結，其包含的所有 DataPack 會轉為壓縮格保存到磁盤上，同時記錄每個資料塊的統計資訊便于過濾，

列存 RowGroup 中每新寫入一行都會分配一個 RowID 用作定位，屬于一行的所有列都可以用該 RowID 計算定位，同時系統維護 PK 到 RowID 的映射索引，以支持后續的洗掉和修改操作，

delete 策略

在 PolarDB In-Memory Column Index 中，洗掉操作只需要設定一個洗掉標記位，更新操作采用標記洗掉的方式來支持，對于更新操作，首先根據 RowID 計算出其原始位置并設定洗掉標記，然后在 ActiveRowGroup 中寫入新的資料版本，

當一個 RowGroup 中的無效記錄超過一定閾值，則會觸發后臺異步 compaction 操作，其作用一方面是回收空間，另一方面可以讓有效資料存盤更加緊湊，提升分析型查詢的效率，

各列式存盤的delete方案匯總

好了，以上就是我對 delete 功能的一個調研情況，下一期我將分享一下，Tinamu 引擎實作 delete 的具體思路，

作者：李紅建（空海）

編輯：宇亭

標籤：其他

上一篇：Doris開發手記4：倍速性能提升，向量化匯入的性能調優實踐

下一篇：Databend 存盤架構總覽