之前的刪除策略及相關問題
作者:莫毅華
日期:2019-12-18
之前的刪除策略及相關問題
在《Managing Data in Massive-Scale Vector Search Engine》中,我們提到了資料檔案的刪除機制。刪除包括軟刪除和硬刪除。對資料表執行刪除作業後,資料表會被標記為軟刪除。之後的搜尋或更新作業將不再允許。但是,在刪除之前開始的查詢作業仍可執行。只有當查詢作業完成時,該表才會真正連同元資料和其他檔案一起刪除。
那麼,標記為 soft-delete 的檔案何時會被真正刪除?在 0.6.0 之前,策略是軟刪除 5 分鐘後檔案才會被真正刪除。下圖顯示了該策略:
5 分鐘
這個策略的前提是查詢通常不會超過 5 分鐘,並不可靠。如果查詢持續超過 5 分鐘,查詢就會失敗。原因是查詢開始時,Milvus 會收集可搜尋的檔案資訊,並建立查詢任務。然後,查詢排程器逐一將檔案載入記憶體,並逐一搜尋檔案。如果載入檔案時檔案已不存在,查詢就會失敗。
延長時間可能有助於降低查詢失敗的風險,但也會造成另一個問題:磁碟使用量過大。原因是當有大量向量插入時,Milvus 會不斷合併資料檔案,即使沒有查詢發生,合併後的檔案也不會立即從磁碟移除。如果資料插入太快和/或插入的資料量太大,額外的磁碟使用量可能達到數十 GB。請參考下圖為例:
結果
如上圖所示,第一批插入的資料 (insert_1) 被刷新到磁碟並成為 file_1,然後 insert_2 成為 file_2。負責檔案組合的線程將檔案合併為 file_3。然後,file_1 和 file_2 被標記為軟刪除。第三批插入資料變成 file_4。該線程將檔案_3 和檔案_4 合併為檔案_5,並將檔案_3 和檔案_4 標記為軟刪除。
同樣地,insert_6 和 insert_5 合併。在 t3 中,file_5 和 file_6 被標記為軟刪除。在 t3 和 t4 之間,雖然許多檔案被標記為軟刪除,但它們仍在磁碟中。檔案在 t4 之後被真正刪除。因此,在 t3 和 t4 之間,磁碟使用量為 64 + 64 + 128 + 64 + 196 + 64 + 256 = 836 MB。插入的資料為 64 + 64 + 64 + 64 = 256 MB。磁碟使用量是插入資料大小的 3 倍。磁碟的寫入速度越快,特定時段內的磁碟使用量就越高。
0.6.0 中刪除策略的改進
因此,我們在 v0.6.0 中改變了刪除檔案的策略。硬刪除不再使用時間作為觸發器。取而代之的是,當檔案不被任何任務使用時才是觸發因素。
新策略
假設插入兩批向量。在 t1 給出查詢請求,Milvus 取得兩個要查詢的檔案 (file_1 和 file_2,因為 file_3 仍然不存在。)接著,後端線程開始合併兩個檔案,查詢同時執行。當 file_3 產生時,file_1 和 file_2 會被標記為軟刪除。在查詢之後,沒有其他任務會使用 file_1 和 file_2,因此它們會在 t4 時被硬刪除。t2 和 t4 之間的間隔非常小,取決於查詢的間隔。如此一來,未使用的檔案就會被及時移除。
至於內部實作,則使用軟體工程師所熟悉的參考計數來判斷檔案是否可以被硬刪除。使用比較來解釋,當玩家在遊戲中有生命時,他仍然可以玩。當生命數變為 0 時,遊戲結束。Milvus 會監控每個檔案的狀態。當某個檔案被某個任務使用時,該檔案就會增加一條生命。當檔案不再使用時,會從檔案移除生命。當檔案被標記為軟刪除,且 life 數為 0 時,該檔案就可以進行硬刪除。
相關部落格
- 0.6.0 中刪除策略的改進
- 相關部落格
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word