MySQL洗掉資料的方式

以MySQL 5.7為例，資料庫洗掉資料的方式一共有以下三種：

1. delete
2. truncate
3. drop

以上三種方式都可以洗掉資料，但是使用場景是不同的，
對于整個表進行洗掉的執行速度來說：
drop > truncate >> delete

MySQL洗掉資料的方式-delete

delete是屬于資料庫的DML操作語言，一般是根據條件逐行進行洗掉，
使用delete洗掉資料時，資料庫只能洗掉資料不能洗掉表的結構，并且會觸發資料庫的事務機制，
delete執行時，會先將所洗掉資料快取到rollback segment中，事務commit之后生效;
在InnoDB中，使用delete其實并不會真正的把資料洗掉，是一種邏輯刪，資料庫底層實際上只是給洗掉的資料做了一個已洗掉的標記，因此，洗掉資料后的表占空間大小和洗掉前是一樣的.

MySQL洗掉資料的方式-drop

drop屬于資料庫DDL定義語言，同 truncate ，執行后立即生效，無法找回，
drop table table_name立刻釋放磁盤空間 ,drop 陳述句將洗掉表的結構、被依賴的約束(constraint)、觸發器(trigger)、索引(index); 依賴于該表的存盤程序/函式將保留,但是變為 invalid 狀態，

洗掉資料的方式-TianMu 引擎的支持情況

目前StoneDB的TianMu引擎是支持 truncate 陳述句 和 drop 陳述句的，但是delete陳述句目前還不支持，

TianMu引擎需要不需要delete？

TianMu引擎設計的初衷

TianMu是一個列式存盤引擎，列式存盤的出現主要是為了方便快捷查詢和高效存盤大量同型別的資料而設計的,主要使用場景就是OLAP場景，下面是OLAP場景的部分關鍵特征：
①絕大多數是讀請求
②資料以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新，
③已添加到資料庫的資料不能修改，
④對于讀取，從資料庫中提取相當多的行，但只提取列的一小部分，
⑤列中的資料相對較小：數字和短字串(例如，每個URL 60個位元組)
⑥處理單個查詢時需要高吞吐量(每臺服務器每秒可達數十億行)
⑦事務不是必須的
⑧對資料一致性要求低

目前行業現狀

OLAP場景下 對于資料的delete的操作可以說沒有或者頻率很小，同時列式存盤對比行式存盤來說并不擅長資料的增刪改，如果是為了極致的查詢性能，完全可以舍棄 DML 操作，但是為了功能的完整性，提升產品的競爭力，目前我們也放開了 insert 和 單表的 update 的功能，delete功能暫時還不支持,未來我們將對改功能進行支持，

主流列式資料庫的delete方案

本節主要講以下三種列式存盤資料庫的delete方案：
?openGauss
?ClickHouse
?PolarDB

openGauss 列存盤引擎的方案

底層存盤結構

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

CU檔案本身結構，則如下圖所示，

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

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

洗掉策略

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

失效空間的清理

• 由于CU以及CUDesc的元資料管理模式，原有系統中的Vacuum機制實際上并不會非常有效的清除CU中已經失效的存盤空間，因為Lazy Vacuum（清理資料時，只是標識無用行的狀態可以錄入新資料，不會影響對表資料的操作）僅能在CUDesc級別進行操作，在多數場景下無法對CU檔案本身進行清理，列存盤內部如果要對列存資料表進行清理，需要執行Vacuum Full（除了清理無用行，還會合并資料塊，整個程序會鎖定表）操作，

ClickHouse delete 方案

特點：缺少高頻率，低延遲的修改或洗掉已存在資料的能力，僅能用于批量洗掉或修改資料，
資料有序存盤
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，但其實是一個虛擬的索引，用于捕獲對該索引覆寫列的增刪改操作，

如上圖所示，在PolarDB中所有Primary Index和Secondary Index都實作為一個B+Tree，而列索引在定義上是一個Index，但其實是一個虛擬的索引，用于捕獲對該索引覆寫列的增刪改操作，
對于上面的表其主表(Primary Index）包含（C1,C2,C3,C4,C5) 5列資料, Seconary Index索引包含(C2,C1) 兩列資料, 在普通二級索引中，C2與C1編碼成一行保存在B+tree中，而其中的列存索引包含(C2,C3,C4)三列資料. 在實際物理存盤時，會對三列進行拆分獨立存盤，每一列都會按寫入順序轉成列存格式，
列存實作為二級索引的另一個好處是執行器的工程實作非常簡單，在MySQL中已經存在覆寫索引的概念，即一個查詢所需要的列都在一個二級索引中存盤，則可以直接利用這個二級索引中的資料滿足查詢需求，使用二級索引相對于使用Primary Index可以極大減少讀取的資料量進而提升查詢性能，當一個查詢所需要的列都被列索引覆寫時，借助列存的加速作用，可以數十倍甚至數百倍的提升查詢性能，

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

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

列存資料組織

對ColumnIndex中每一列，其存盤都使用了無序且追加寫的格式，結合標記洗掉及后臺異步compaction實作空間回收，其具體實作上有如下幾個關鍵點：
列索引中記錄按RowGroup進行組織，每個RowGroup中不同的列會各自打包形成DataPack，
每個RowGroup都采用追加寫，分屬每個列的DataPack也是采用追加寫模式，對于一個列索引，只有個Active RowGroup負責接受新的寫入，當該RowGroup寫滿之后即凍結，其包含的所有Datapack會轉為壓縮格保存到磁盤上，同時記錄每個資料塊的統計資訊便于過濾，
列存RowGroup中每新寫入一行都會分配一個RowID用作定位，屬于一行的所有列都可以用該RowID計算定位，同時系統維護PK到RowID的映射索引，以支持后續的洗掉和修改操作，
洗掉操作只需要設定一個洗掉標記位，
更新操作采用標記洗掉的方式來支持，對于更新操作，首先根據RowID計算出其原始位置并設定洗掉標記，然后在ActiveRowGroup中寫入新的資料版本，
當一個RowGroup中的無效記錄超過一定閾值，則會觸發后臺異步compaction操作，其作用一方面是回收空間，另一方面可以讓有效資料存盤更加緊湊，提升分析型查詢單的效率，

delete 策略

洗掉操作只需要設定一個洗掉標記位，
更新操作采用標記洗掉的方式來支持，對于更新操作，首先根據RowID計算出其原始位置并設定洗掉標記，然后在ActiveRowGroup中寫入新的資料版本，
當一個RowGroup中的無效記錄超過一定閾值，則會觸發后臺異步compaction操作，其作用一方面是回收空間，另一方面可以讓有效資料存盤更加緊湊，提升分析型查詢的效率，

各列式存盤的delete方案匯總

TianMu引擎 delete 功能規劃

GitHub issue 鏈接：
https://github.com/stoneatom/stonedb/issues/343

TianMu引擎 delete 功能實作流程圖

標籤：其他

上一篇：FileMaker Pro 19 Advanced (資料庫工具)

下一篇：【StoneDB故障診斷】資料庫實體crash