什麼是異質性記憶體儲存引擎？

敬請知悉，美光最近向開放原始碼社群發佈異質性記憶體儲存引擎 (HSE)。我們的設計著重提供能提高儲存級記憶體 (SCM) 和 SSD 效能的解決方案，並透過降低寫入放大率，延長 SSD 的有效壽命，同時進行大規模部署。與舊款儲存引擎相比，HSE 通常多次有利於 Yahoo! Cloud Serving Benchmark (YCSB) 等工作負載。

什麼是異質性記憶體儲存引擎 (HSE)？

為什麼是異質性？ 美光擁有廣泛的 DRAM、SCM 和 SSD 產品組合，為我們帶來構建儲存引擎的見解和專業知識，以智慧方式管理不同記憶體和儲存媒體類型的資料放置。不同於針對硬碟編寫的傳統儲存引擎，HSE 從頭開始設計，利用 SCM 和 SSD 的高吞吐量和低延遲。

採用

HSE 利用離散媒體類型優勢，支援兩種媒體類別的資料儲存：「暫存」媒體類別和「容量」媒體類別。暫存媒體類別通常配置到高效能（IOPS 和／或 MB/s）、低延遲和高寫入耐用性媒體（例如 SCM 或採用 NVMe™ 的資料中心級 SSD）上執行。用於經常性短期存取的資料會分配至暫存媒體類別，而非經常性長期資料通常會配置到容量媒體類別層級，以較低成本、較低寫入耐用性媒體（例如四層單元 [QLC] SSD）執行。這使 HSE 能夠實現高輸送量和低延遲，同時節省較低耐用性媒體的寫入週期。

可配置的耐用度層

HSE 耐用度層是使用者可配置的邏輯建構，常駐在暫存媒體類別上。耐用度層提供使用者可定義之資料持久性，其中使用者指定在系統故障（如斷電）時可能損失的資料的毫秒數之上限。

資料最初從 DRAM 擷取至耐用度層。儲存裝置從更快的暫存媒體類別中配置，以滿足耐用度層的低延遲、高吞吐量要求。與傳統的預寫日誌 (WAL) 不同，此耐用度層可避免傳統日誌記錄常見的「雙寫入問題」，大幅減少寫入放大現象。

資料老化

隨著儲存的資料老化，資料會遷移至系統的多層，並作為垃圾收集的一部分重新寫入，以優化查詢效能（完成時間）。以下是高階流程：

需要儲存新資料時，會先寫入耐用度層。

隨著資料老化，資料會重新寫入容量媒體類別，作為後台維護作業。

隨著新資料到達，新資料可能會使現有資料過時（透過更新或刪除先前寫入的記錄）。維護作業定期掃描現有資料，以啟用空間回收。如果大部分的資料現在無效或過時，這些作業透過僅重新寫入仍然有效的資料來恢復空間 — 釋放舊資料佔用的所有空間（即垃圾收集）。為了有效率地服務查詢，我們亦會安排有效的資料，以便輕鬆進行掃描。

有效資料會重新組織為層級，以加快查詢處理速度。在整個過程中，鍵和值資料被隔離為單獨的流 — 鍵被寫入暫存媒體類別，以加快查詢速度。最終，底層的較舊資料被寫入指定的容量媒體類別裝置。

於處理查詢及從兩個媒體類別中讀取資料時，索引會按頁面被快取至 DRAM。假設系統 DRAM 可用，LRU （最近最少使用）演算法可動態排列索引，以促進索引追蹤，將最熱門的（即最常訪問的索引）固定在記憶體中。

媒體類別效能

我們的測試設定使用一台搭載 NVMe™ 的美光 9300 SSD 作為暫存媒體類別裝置，而使用四台美光 5210 SATA QLC SSD 作為容量媒體類別裝置。我們使用 Yahoo！® 雲端服務基準（YCSB）以比較每秒的作業和 99.9% 的尾部延遲：

• 首次運行：四個美光 5210 QLC SSD 配置為容量媒體類別裝置
• 第二次運行：四個 5210 SSD 配置為容量媒體類別裝置，一台搭載 NVMe 的美光 9300 SSD 配置為暫存媒體類別裝置

我們在運行 YCSB 工作負載 A、B、C、D 和 F 時，兩種配置的執行緒數均相同¹。表 1 總結了數個 YCSB 工作負載組合，以及取自 YCSB 文件的應用程式範例。表 2 至表 4 分享有關硬體、軟體和基準組態的其他測試詳情。

1. 工作負載 E 因其未得到廣泛支持而未經過測試

2. 不同的組態可能會顯示不同的結果。

吞吐量

YCSB 首先載入資料庫。這是 100% 插入工作負載量。在組合中加入 9300 可將載入 2TB 資料庫所需的時間縮短四倍。

圖 1 顯示了五個 YCSB 工作負載的負載階段和運行階段的吞吐量。對於工作負載 A（50% 更新）和工作負載 F（50% 插入）等寫入密集型工作負載，加入美光 9300 作為暫存媒體類別，分別將整體吞吐量提高 2.3 和 2.1 倍。工作負載 B 和 D（5% 更新/插入）顯示更小的吞吐量提升，因為這其中 95% 的工作負載讀取幾乎完全來自包含容量媒體類別的 5210 SSD。

延遲

圖 2 顯示 99.9% 的讀取（尾部）延遲。加入 9300 後，所有工作負載的讀取尾部延遲都會大幅改善（2 至 3 倍）（工作負載 C 除外，這是 100% 讀取）。回顧一下，新到達的寫入首先被 9300 吸收，隨著資料老化，在後台逐步寫入 5210。關鍵資料（索引）會寫入 9300，加快第二個組態的查詢速度。小部分讀取由 9300 而非 5210 進行處理（視讀取資料的查詢分佈和年齡而定）。

此外，藉由減少 5210 的寫入次數，即使是 5210 所進行的讀取亦會減少受到持續寫入造成的爭用，因此尾部讀取延遲較低。插入/更新延遲不會顯示，因為它們在執行階段的兩種組態中相似。

寫入位元組

最終，我們在執行每個工作負載的過程中測量了寫入 5210 的資料量。加入 9300 作為暫存媒體類別會減少寫入 5210 的位元組數，保留寫入週期並延長 5210 的寫入壽命。在負載期間（僅插入階段），寫入 5210 的位元組數會減少 2.4 倍，如表 5 所示。

圖 3 顯示 YCSB 工作負載運行階段期間寫入的 GB 總數。請注意，這包括使用者和後台寫入。除工作負載 C（100% 讀取）外，其他工作負載顯示，透過在組態中加入一個 9300，寫入 5210 的總位元組數至少減少兩倍。

未來工作

作為未來工作的一部分，我們希望擴展 HSE API 的特定方面，以增強其使用，例如提供自訂媒體類別策略，讓應用程式擁有更多控制權。例如，如果應用程式建立的鍵值儲存區（KVS，相當於關係資料庫中的表格）僅用於索引，可指定特定 KVS 應使用暫存媒體類別來加快查詢速度。如果索引 KVS 的大小因變得太大而無法在暫存裝置上容納，應用程式可指定使用暫存媒體但退回至容量媒體的策略。我們還可能會引入預先定義的媒體類別策略範本，並擴展 HSE API，允許應用程式根據其需求使用它們。請務必與外界保持聯繫，瞭解潛在發展。