最近在可計(jì)算存儲(chǔ) CSD 2000上使用 BenchmarkSQL 和 sysbench 測(cè)試了一下 openGauss 數(shù)據(jù)庫，主要觀察在大數(shù)據(jù)量下 openGauss 在 CSD 2000 上數(shù)據(jù)存儲(chǔ)空間和性能相比普通SSD 的變化。這里分享一些測(cè)試數(shù)據(jù)和原理的思考，供對(duì)openGauss 和可計(jì)算存儲(chǔ) CSD 感興趣的朋友參考。

CSD 測(cè)試效果

測(cè)試場(chǎng)景簡(jiǎn)介

測(cè)試場(chǎng)景選擇了數(shù)據(jù)庫廠商經(jīng)常用的兩種標(biāo)準(zhǔn)場(chǎng)景。

§BenchmarkSQL TPC-C場(chǎng)景

TPC-C是衡量聯(lián)機(jī)事務(wù)處理（OLTP，OnlineTransaction Processing）系統(tǒng)的工業(yè)標(biāo)準(zhǔn)，是行業(yè)中公認(rèn)的權(quán)威和最為復(fù)雜的在線事務(wù)處理基準(zhǔn)測(cè)試。它通過模擬倉庫和訂單管理系統(tǒng)，測(cè)試廣泛的數(shù)據(jù)庫功能，包括查詢、更新和 mini-batch事務(wù)（隊(duì)列式小批量事務(wù)）。

TPC-C基準(zhǔn)測(cè)試模擬訂單錄入與銷售環(huán)境，測(cè)量每分鐘商業(yè)事務(wù)（tpmC）吞吐量。TPC-C 測(cè)試數(shù)據(jù)集規(guī)模由倉庫數(shù)決定，本次測(cè)試指定10000倉。一共有9張業(yè)務(wù)表，最大的表數(shù)據(jù)量是倉庫數(shù)*300K ，這里有30億。

開源的 TPC-C 測(cè)試工具有 BenchmarkSQL 和 sysbench。這里選擇BenchmarkSQL，官方下載地址：https://sourceforge.net/projects/benchmarksql/ 。測(cè)試方法參考o(jì)penGauss 官方文檔。

§sysbench OLTP 場(chǎng)景

sysbench 是一個(gè)開源的、模塊化的、跨平臺(tái)的多線程性能測(cè)試工具，可以用來進(jìn)行CPU、內(nèi)存、磁盤I/O、線程、數(shù)據(jù)庫的性能測(cè)試。目前支持的數(shù)據(jù)庫有 MySQL 、Oracle和Postgre SQL 。

sysbench oltp 基準(zhǔn)測(cè)試指定場(chǎng)景腳本（lua文件），輸出相應(yīng)的平均每秒事務(wù)數(shù)TPS、平均每秒請(qǐng)求數(shù)QPS、平均延時(shí)RT、99百分位延時(shí)等。sysbench 數(shù)據(jù)量是可以指定表的數(shù)量和每個(gè)表的數(shù)據(jù)量。本次測(cè)試指定100張表，每張表1億記錄。

sysbench 從開源網(wǎng)站github.com 下載，版本1.1.0 。

存儲(chǔ)空間壓縮效果

為了讓 SSD 讀寫能進(jìn)入穩(wěn)態(tài)，降低數(shù)據(jù)庫內(nèi)存和操作系統(tǒng)內(nèi)存對(duì)磁盤測(cè)試的影響，兩種測(cè)試場(chǎng)景的數(shù)據(jù)量都非常大。

§Benchmarksql TPC-C 場(chǎng)景：數(shù)據(jù)規(guī)模在 10000 倉庫，表的填充因子（FILLFACTOR）設(shè)置為 50，數(shù)據(jù)庫文件大小總計(jì)約 1882 GB，CSD 內(nèi)部實(shí)際使用空間約 602 GB 。CSD 壓縮比為 3.12 （壓縮比=壓縮前物理空間 / 壓縮后物理空間）。

§sysbench 場(chǎng)景：100表，每表 1 億數(shù)據(jù)，表的填充因子設(shè)置為 100 ，數(shù)據(jù)庫文件大小總計(jì)為 2565 GB，CSD 內(nèi)部實(shí)際使用空間約 810 GB 。CSD 壓縮比為 3.16 。

§sysbench 場(chǎng)景：100表，每表 1 億數(shù)據(jù)，表的填充因子設(shè)置為 75 ，數(shù)據(jù)庫文件大小總計(jì)為 3300 GB，CSD 內(nèi)部實(shí)際使用空間約 874 GB 。CSD 壓縮比為 3.77 。

普通的 SSD 沒有透明壓縮能力，內(nèi)部實(shí)際存儲(chǔ)空間也就等于上面“壓縮前大小”。CSD 2000 的透明壓縮能力顯著降低數(shù)據(jù)在 SSD 內(nèi)部的物理存儲(chǔ)空間，極大的降低了 存儲(chǔ)介質(zhì)NAND 消耗速度，降低 SDD GC 頻率，所以在 SSD 進(jìn)入穩(wěn)態(tài)后高并發(fā)讀寫時(shí)，性能也有明顯提升。

性能對(duì)比

兩種測(cè)試場(chǎng)景，在固定數(shù)據(jù)量的前提下，分別使用不同的客戶端并發(fā)數(shù)進(jìn)行測(cè)試，每次測(cè)試時(shí)間在10分鐘。

§TPC-C 性能，在 64 并發(fā)時(shí)提升幅度最大。

§SYSBENCH （FF=100）性能

注：FF，F(xiàn)ILLFACTOR 的簡(jiǎn)稱，填充因子，用于控制數(shù)據(jù)庫塊里 INSERT 的最大空間使用比例。

讀寫混合場(chǎng)景的每秒請(qǐng)求數(shù)QPS：

讀寫混合場(chǎng)景的平均延時(shí) RT：

§SYSBENCH （FF=75）性能

讀寫混合場(chǎng)景的每秒請(qǐng)求數(shù)QPS：

讀寫混合場(chǎng)景的平均延時(shí) RT：

上面只是取了 TPCC 和 sysbench oltp 讀寫混合場(chǎng)景。更多場(chǎng)景的測(cè)試信息請(qǐng)查看文末鏈接。從上圖可以看出：

§sysbench 相同的數(shù)據(jù)量（100億），不同的填充因子（FILLFACTOR）從 100 降到 75 時(shí)，不管是在普通 SSD 還是 CSD 上，性能都會(huì)提升。在普通盤上的代價(jià)就是存儲(chǔ)空間的增長(zhǎng)（從 2565G 漲到 3300G），但是在 CSD 上實(shí)際存儲(chǔ)空間的增長(zhǎng)卻很?。◤?810G 漲到 874G ）。

§不管是 TPC-C 還是 sysbench 的讀寫混合場(chǎng)景，當(dāng)并發(fā)超過 10 后，CSD 上的 QPS 或平均延時(shí)都會(huì)呈現(xiàn)優(yōu)勢(shì)并且逐步擴(kuò)大，直到到達(dá)一個(gè)拐點(diǎn)。

備注：這次性能測(cè)試場(chǎng)景數(shù)據(jù)量造的非常大（1.5T 以上），并且數(shù)據(jù)庫內(nèi)存不是很大(80G)，同時(shí)開啟了openGauss 的 full_page_writes ，沒有刻意對(duì) openGauss 做深入優(yōu)化。所以數(shù)據(jù)庫壓測(cè)的時(shí)候加在 SSD 上的讀寫壓力很大，整體呈現(xiàn) IO Bound 特點(diǎn)。這是為了模擬這種情形，即客戶生產(chǎn)業(yè)務(wù)應(yīng)用的數(shù)據(jù)庫并不一定總是很優(yōu)化，在性能出現(xiàn)問題的時(shí)候可能存儲(chǔ)的讀寫壓力很大，SSD 往往成為性能瓶頸。所以這里測(cè)試的結(jié)果值跟數(shù)據(jù)庫單純的做性能測(cè)試取得的峰值會(huì)有一定差異。我們重點(diǎn)關(guān)注相同的數(shù)據(jù)量相同的數(shù)據(jù)庫軟硬件配置在不同的 SSD 上的性能差異。

openGauss存儲(chǔ)特性簡(jiǎn)介

openGauss v2.1 的內(nèi)核是 Postgres 9.2.4 。openGauss 的存儲(chǔ)引擎支持三種類型：

§行存儲(chǔ)引擎：面向 OLTP 場(chǎng)景設(shè)計(jì)。如訂單、物流、金融交易系統(tǒng)。

§列存儲(chǔ)引擎：面向 OLAP 場(chǎng)景設(shè)計(jì)。如數(shù)據(jù)統(tǒng)計(jì)分析報(bào)表。

§內(nèi)存引擎：面向一些特殊場(chǎng)景對(duì)性能有極致要求。如銀行風(fēng)控等。

這里我主要測(cè)試的是行存儲(chǔ)引擎。行存儲(chǔ)引擎的特性很多，這里這聊它的數(shù)據(jù)存儲(chǔ)模型。openGauss 跟 PostgreSQL 一樣都是使用 B-Tree 模型。openGauss行存儲(chǔ)表支持多版本元組機(jī)制，即為同一條記錄保留多個(gè)歷史版本的物理元組，以應(yīng)對(duì)同一條記錄的讀、寫并發(fā)沖突（讀事務(wù)和寫事務(wù)工作在不同版本的物理元組上）。這種設(shè)計(jì)叫 astore 元組多版本機(jī)制。

astore存儲(chǔ)格式為追加寫優(yōu)化設(shè)計(jì)，其多版本元組產(chǎn)生和存儲(chǔ)方式如下圖所示。當(dāng)一個(gè)更新操作將v0版本元組更新為v1版本元組之后，如果v0版本元組所在頁面仍然有空閑空間，則直接在該頁面內(nèi)插入更新后的v1版本元組，并將v0版本的元組指針指向v1版本的元組指針。在這個(gè)過程中，新版本元組以追加寫的方式和被更新的老版本元組混合存放，這樣可以減少更新操作的I/O開銷。然而，需要指出的是，由于新、老版本元組是混合存放的，因此在清理老版本元組時(shí)需要的清理開銷會(huì)比較大。因此，astore存儲(chǔ)格式比較適合頻繁插入、少量更新的業(yè)務(wù)場(chǎng)景。

引用來源：《openGauss數(shù)據(jù)庫源碼解析系列文章——存儲(chǔ)引擎源碼解析（二）》

openGauss 表有個(gè)存儲(chǔ)參數(shù)填充因子（FILLFACTOR）可以指定每個(gè)頁里在插入數(shù)據(jù)時(shí)使用的最大空間比例。表默認(rèn)是 100% ，索引默認(rèn)是 90%。大量的 insert 可能會(huì)導(dǎo)致頁基本寫滿從而后期更新操作時(shí)就需要另外找新的頁存放新元組。適當(dāng)?shù)念A(yù)留一些空間能提升表的更新（update 和 delete）性能。PostgreSQL 或者 openGauss 用戶可能不會(huì)過多降低這個(gè)參數(shù)值，因?yàn)檫@會(huì)導(dǎo)致表和索引的存儲(chǔ)空間增加。但是如果數(shù)據(jù)庫存儲(chǔ)是帶透明壓縮的可計(jì)算型存儲(chǔ) CSD 時(shí)，這個(gè)空間擔(dān)心就是多余的。

可計(jì)算型存儲(chǔ) CSD 簡(jiǎn)介

常用壓縮方案

常用的數(shù)據(jù)壓縮方案有好幾種，業(yè)務(wù)根據(jù)自己需求和方案特點(diǎn)選擇。這里簡(jiǎn)單介紹一下各種方案特點(diǎn)：

§應(yīng)用（指數(shù)據(jù)庫）自己開啟壓縮，占用一定主機(jī) CPU 資源，損失一些性能。損失多少取決于壓縮算法和數(shù)據(jù)庫工程實(shí)現(xiàn)能力。隨著數(shù)據(jù)量增長(zhǎng)，性能損耗會(huì)加大，不具備線性擴(kuò)展能力。CPU 壓縮也會(huì)導(dǎo)致 CPU Cache Miss 事件增多。簡(jiǎn)單來說是犧牲CPU性能換存儲(chǔ)空間。

§使用 FPGA 加速卡壓縮。FPGA 卡自帶計(jì)算引擎，能減輕主機(jī) CPU 負(fù)載，在不少場(chǎng)景里很適合。不過 FPGA 卡會(huì)占用一個(gè) PCIe 插槽，且數(shù)據(jù)讀寫傳輸會(huì)占用內(nèi)存資源。數(shù)據(jù)鏈路也變長(zhǎng)。同樣受限于壓縮卡算力和帶寬，無法線性擴(kuò)展。

§CSD 透明壓縮。在 SSD 內(nèi)部引入計(jì)算引擎，數(shù)據(jù)按常規(guī)方法寫入 SSD，然后盤內(nèi)計(jì)算引擎對(duì)數(shù)據(jù)壓縮，寫入存儲(chǔ)物理介質(zhì)（NAND）。透明壓縮，應(yīng)用不需要修改。zero-copy技術(shù)，不需要額外數(shù)據(jù)傳輸。數(shù)據(jù)量增長(zhǎng)時(shí)，可以增加多塊 CSD 盤實(shí)現(xiàn)壓縮能力線性擴(kuò)展。

CSD 的透明壓縮做到應(yīng)用完全不用修改就可以用。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（使用B-Tree數(shù)據(jù)模型，如 ORACLE/MySQL/SQL Server/PostgreSQL）可以直接部署在 CSD 上使用，通常業(yè)務(wù)數(shù)據(jù)壓縮比能在 2.0 以上。雖然這些數(shù)據(jù)庫自身也有壓縮方案，但考慮到性能，客戶核心應(yīng)用在生產(chǎn)上不會(huì)開啟壓縮。一些 NewSQL 數(shù)據(jù)庫使用 LSM Tree 模型的，也自帶壓縮能力。如果數(shù)據(jù)庫強(qiáng)行開啟壓縮，那么數(shù)據(jù)文件在 CSD 上壓縮比還要根據(jù)實(shí)際情況看。這涉及到 CSD 壓縮的原理。

CSD 原理特性

§定長(zhǎng)塊 IO

當(dāng)給 SSD 盤做文件系統(tǒng)格式化時(shí)，默認(rèn)塊大小是 4KB（這個(gè)也可以改，具體要看操作系統(tǒng)是否支持）。應(yīng)用寫入數(shù)據(jù)時(shí)，每個(gè) IO 里實(shí)際有效數(shù)據(jù)大小可能小于或等于 4KB，不足 4KB 時(shí)會(huì)用空（0x0）補(bǔ)齊。文件系統(tǒng)上層的應(yīng)用（數(shù)據(jù)庫），為了減少 I/O 次數(shù)，數(shù)據(jù)庫的塊（或叫頁P(yáng)age）大小通常都比 4KB 大。如 ORACLE 和 PostgreSQL 默認(rèn)是 8KB ，MySQL 是 16KB ，openGauss 是 8KB 。數(shù)據(jù)庫軟件在管理數(shù)據(jù)存儲(chǔ)的時(shí)候，會(huì)有按塊大小補(bǔ)齊邏輯。此外，使用 B-Tree 模型管理數(shù)據(jù)的數(shù)據(jù)庫的塊通常有預(yù)留空間設(shè)計(jì)，以提升記錄更新的性能，減少數(shù)據(jù)塊或者索引塊不必要的頁分裂帶來的性能下降。這是用存儲(chǔ)空間換性能的做法。比如說 ORACLE 建表的 storage 參數(shù)的 PCTFREE，PostgreSQL 、openGauss的 storage 參數(shù) FILLFACTOR 。預(yù)留空間的比例需要在空間和性能之間權(quán)衡。這個(gè)在以前是個(gè)難題，不過數(shù)據(jù)放在 CSD 上后就不是問題了。因?yàn)樗杏糜谘a(bǔ)齊的空數(shù)據(jù)、數(shù)據(jù)庫塊里的預(yù)留空間（空數(shù)據(jù)），在 CSD2000 內(nèi)部都會(huì)被壓縮掉，沒有實(shí)際存儲(chǔ)成本。

§壓縮算法

當(dāng)然，壓縮收益還有一部分來自于業(yè)務(wù)數(shù)據(jù)和壓縮算法自身。以 TPC-C 產(chǎn)生的10000倉的數(shù)據(jù)為例，如果全部導(dǎo)出為 csv 文件，在 CSD2000 上大小有 729 GB，實(shí)際占用物理空間為 457 GB，壓縮比約 1.59 。當(dāng)將數(shù)據(jù)導(dǎo)入到 openGauss并設(shè)置 openGauss 表的 fillfactor 為 50 時(shí)，這份數(shù)據(jù)在 openGauss 的數(shù)據(jù)文件總計(jì) 1882 GB，該數(shù)據(jù)文件在 CSD 2000 上實(shí)際占用物理空間 602 GB，壓縮比約 3.13 。CSD 2000 內(nèi)部使用的壓縮算法是 zlib （gzip）。

除了 gzip/zlib 還有些常見的壓縮算法，如 lz4、snappy、zstd 。每個(gè)壓縮算法還有不同的壓縮 level。就默認(rèn) level 而言，實(shí)際經(jīng)驗(yàn)是 lz4、snappy壓縮比較快，對(duì) CPU 占用低，自然壓縮比也是很低。zstd、gzip 壓縮比較慢，對(duì) CPU 占用高，壓縮比很高。CSD 的透明壓縮是靠 SSD 內(nèi)部的計(jì)算引擎實(shí)現(xiàn)的（在 CSD 2000 內(nèi)部是有一個(gè) FPGA；在 CSD 3000 內(nèi)部是 ARM 芯片），不占用主機(jī) CPU 。下面表格是 sysbench 表導(dǎo)出 csv 文件后的壓縮比測(cè)試。

應(yīng)用（指數(shù)據(jù)庫）如果開啟壓縮，除了要消耗一部分 CPU 資源外，還會(huì)帶來一個(gè)問題就是數(shù)據(jù)讀寫過程中的壓縮和解壓縮會(huì)降低 CPU cache 的命中率。此外，當(dāng)一個(gè) 16K 的數(shù)據(jù)塊被壓縮后可能就不是 4KB 的整數(shù)了，在寫到文件系統(tǒng)里還是很可能有不少空數(shù)據(jù)，所以在數(shù)據(jù)庫壓縮后在 CSD 內(nèi)部還可以繼續(xù)壓縮一部分(還有一個(gè)原因就是壓縮算法之間的差異)。

這次沒有對(duì)比測(cè)試 openGauss 數(shù)據(jù)庫的壓縮效果。根據(jù)其他數(shù)據(jù)庫的測(cè)試經(jīng)驗(yàn)。如果數(shù)據(jù)庫使用 lz4 壓縮，在 CSD2000 內(nèi)部還會(huì)有 1.54 的壓縮比。有些數(shù)據(jù)庫使用 LSM Tree 模型，數(shù)據(jù)是分層壓縮的，不同層的壓縮算法還可以不一樣，這些數(shù)據(jù)在 CSD 內(nèi)部的壓縮效果就取決于數(shù)據(jù)庫里使用用不同壓縮算法的數(shù)據(jù)占比了。

§壓縮比

CSD 2000 提供了命令可以直接看具體的文件的實(shí)際物理空間和壓縮比，以及整個(gè) SSD 盤的實(shí)際物理空間和壓縮比。當(dāng)業(yè)務(wù)數(shù)據(jù)是變化的時(shí)候，CSD 2000 上觀察到的壓縮比是浮動(dòng)的，每個(gè)業(yè)務(wù)都不一樣。下圖是客戶的業(yè)務(wù)數(shù)據(jù)壓縮比經(jīng)驗(yàn)。

大部分?jǐn)?shù)據(jù)庫的數(shù)據(jù)存儲(chǔ)是即時(shí)分配，這些數(shù)據(jù)庫的壓縮比觀察數(shù)據(jù)比較直接。少數(shù)數(shù)據(jù)庫有自己的空間管理策略。如 ORACLE數(shù)據(jù)庫有表空間概念，可以預(yù)分配（初始化）一定大小的數(shù)據(jù)文件。同時(shí)也可以后期文件自動(dòng)擴(kuò)展。以前在存儲(chǔ)資源很寶貴的時(shí)候， DBA 會(huì)習(xí)慣自己控制文件的增長(zhǎng)。一點(diǎn)點(diǎn)用，像擠牙膏似的。預(yù)分配的空間里都是用空數(shù)據(jù)（0x0）初始化，對(duì)壓縮比的結(jié)果會(huì)有一定影響，影響的比例就取決于這部分?jǐn)?shù)據(jù)占總大小的比例。然后表空間還有自己的空間管理（復(fù)用）策略，在表被刪除后，其對(duì)應(yīng)的空間很有可能只是數(shù)據(jù)庫內(nèi)部復(fù)用，并不會(huì)歸還給磁盤。盡管數(shù)據(jù)庫認(rèn)為某一段空間是無效的，在 CSD 眼里，其原數(shù)據(jù)還是在的，壓縮比也是存在的。

壓縮比浮動(dòng)可能會(huì)讓人擔(dān)心。為了放心，運(yùn)維可以監(jiān)控 SSD 的可用物理空間。正如 ORACLE 數(shù)據(jù)庫管理員要監(jiān)控磁盤可用空間，也要監(jiān)控?cái)?shù)據(jù)庫內(nèi)部表空間的可用空間，使用 CSD 2000 還要監(jiān)控 SSD 內(nèi)部可用物理空間。CSD 2000 的透明壓縮沒有修改文件系統(tǒng)的接口，所以用戶在看數(shù)據(jù)文件大小看到的都是壓縮前的大小，也叫邏輯空間大?。ㄆ湓L問地址對(duì)應(yīng)為 LBA，Logical Block Address）。這點(diǎn)是CSD透明壓縮區(qū)別于文件系統(tǒng)（如zfs）壓縮方案。在 SSD 內(nèi)部還有個(gè)物理空間地址 PBA （Physical Block Address）。

§OP 空間

對(duì)于普通的 HDD 而言，LBA 和 PBA 地址映射是 1:1 的。SSD 比 HDD 不一樣的地方是 SSD 內(nèi)部有一定比例的保留空間對(duì)用戶是不可見的，又稱為 Over Provision 空間（簡(jiǎn)稱 OP）。OP 空間的存在原因是 SSD 的寫是對(duì)閃存空的Page 進(jìn)行編程（Program），每個(gè) Page 只能編程一次(除非后期擦除再次變?yōu)榭?Page了)。所以 SSD 可以寫入新的空 Page 但是不能修改老的 Page 。如果要改寫只能將老的 Page 數(shù)據(jù)復(fù)制到新的 Page，期間經(jīng)過 SSD Cache 的時(shí)候在 Cache 里修改數(shù)據(jù)，然后寫入到新的 Page。這就需要 OP 空間來容納數(shù)據(jù)。所以 SSD 內(nèi) LBA 和 PBA 的映射不是 1:1 ， PBA 的地址容量大于 LBA 的地址容量。當(dāng)改寫數(shù)據(jù)時(shí)，原 LBA 會(huì)映射到新的 PBA，那么老的 PBA 在 SSD 內(nèi)部就屬于“無主數(shù)據(jù)”或者“臟數(shù)據(jù)”。當(dāng) SSD 內(nèi)沒有剩余的空 Page 用于寫時(shí)，SSD 就會(huì)回收“臟數(shù)據(jù)” 所在的 Page，這個(gè)操作叫 GC， “臟數(shù)據(jù)”所在 Page 變?yōu)榭?Page 操作叫擦除（Erase）。由于 SSD 電路設(shè)計(jì)特點(diǎn)，擦除的單位是 BLOCK ，并且每個(gè) BLOCK 被擦除的次數(shù)還有限。一個(gè) BLOCK 大小現(xiàn)在可能有幾MB 或者幾十 MB（跟產(chǎn)品型號(hào)、容量有關(guān)）。所以為了擦除某幾個(gè)“臟數(shù)據(jù)” 所在的 BLOCK，需要先把該 BLOCK 上有效數(shù)據(jù)所在的 Page 遷移到空的 BLOCK 上。當(dāng)剩余空 PAGE 比例很低觸發(fā)GC時(shí)，就是SSD進(jìn)入穩(wěn)態(tài)了。GC 操作并不會(huì)等空 Page全部寫完了才做，可能是定時(shí)做或者空閑期自動(dòng)做，或者空余 Page比例不足某個(gè)值時(shí)做。當(dāng) GC 發(fā)生時(shí)，很多數(shù)據(jù)搬遷，會(huì)占用 SSD 內(nèi)部 CPU 和 NAND 通道帶寬，所以對(duì)性能會(huì)有一定影響。這也就是普通 SSD 使用一段時(shí)間后寫性能會(huì)變慢的主要原因。當(dāng)把數(shù)據(jù)搬遷的量也算作 SSD 存儲(chǔ)介質(zhì)（NAND）的消耗時(shí)，相比業(yè)務(wù)寫入 SSD 的數(shù)據(jù)量，前者可能遠(yuǎn)遠(yuǎn)大于后者，這就是 SSD 的寫放大特點(diǎn)。

但在 CSD 產(chǎn)品，GC 的概率會(huì)非常低。由于內(nèi)置透明壓縮能力，業(yè)務(wù)寫入 CSD 的數(shù)據(jù)量跟 CSD 內(nèi)部 NAND 實(shí)際寫入量的比例是 N:1 的關(guān)系（N 就是數(shù)據(jù)壓縮比，N>1），也就是 CSD 產(chǎn)品的寫放大是小于 1 的。這是跟普通 SSD 最大的區(qū)別。這樣導(dǎo)致 CSD 內(nèi)部實(shí)際有效 OP 空間遠(yuǎn)大于產(chǎn)品標(biāo)稱的能力（一般 SSD 的 OP 比例是 7% 或者 28%）。OP 空間越大，GC 自然越少。對(duì)于 QLC CSD 而言，這個(gè)特性能極大提升 SSD 壽命。

§CSD 容量擴(kuò)容

不過有部分客戶業(yè)務(wù)數(shù)據(jù)壓縮比很高（大于3），業(yè)務(wù)數(shù)據(jù)量很大的時(shí)候（幾十甚至幾百TB 以上）這部分多出的 OP 空間就非?？捎^，客戶希望能使用這部分 OP 空間。所以 CSD 2000 還有一個(gè)用法就是“擴(kuò)容”。默認(rèn)一個(gè) 4TB 的 CSD 2000 可以提供 3.2T 的空間。根據(jù)實(shí)際業(yè)務(wù)數(shù)據(jù)特點(diǎn)，可以對(duì)盤做一個(gè)初始化設(shè)置，允許提供 6.4 T 的空間（這是舉例）。具體來說就是提供 6.4 TB 的 LBA 地址容量。對(duì)業(yè)務(wù)來說，使用方法還是不變。將 CSD 2000 格式化文件系統(tǒng)后，就能看到盤有 6.4 T 的剩余空間。只要后期業(yè)務(wù)寫入的數(shù)據(jù)平均壓縮比高于 2:1， 那么這塊盤的容量和性能還是可能比普通的盤要好。

§原子寫

CSD 2000還有個(gè)特殊的能力，能在硬件層面提供 8K~256K 的 IO 原子寫能力。只要上層應(yīng)用（數(shù)據(jù)庫）需要 4K 整數(shù)倍 IO的原子寫，可以完全交給 CSD 2000 來實(shí)現(xiàn)。前提是數(shù)據(jù)庫寫是 direct IO。

前面提到很多關(guān)系數(shù)據(jù)庫數(shù)據(jù)塊大小都是 4K 的倍數(shù)，在發(fā)生機(jī)器故障時(shí)，有可能出現(xiàn)數(shù)據(jù)塊寫到文件里部分成功部分失敗的情形下。即使數(shù)據(jù)庫開啟了 WAL（Write Ahead Logging）機(jī)制，也不一定能保證數(shù)據(jù)庫恢復(fù)后該數(shù)據(jù)塊也能正確恢復(fù)。在 MySQL 里，通過先同步順序?qū)懸粋€(gè)共享表空間文件，然后再寫數(shù)據(jù)文件的方式來規(guī)避問題。在故障發(fā)生后如果發(fā)現(xiàn)數(shù)據(jù)塊校驗(yàn)有問題，就直接用該共享表空間的內(nèi)容覆蓋數(shù)據(jù)文件上的數(shù)據(jù)塊進(jìn)行恢復(fù)。這個(gè)機(jī)制叫雙寫。在 PostgreSQL里使用的是在 Redo 日志里記錄數(shù)據(jù)塊完整的內(nèi)容（通過參數(shù) full_page_writes 控制）（傳統(tǒng) WAL 日志記錄的是數(shù)據(jù)塊的變化內(nèi)容）。openGauss 2.1版本兩種方案都支持（參數(shù) enable_double_write 和 full_page_writes），默認(rèn)使用的是雙寫方案。雙寫方案跟開啟增量檢查點(diǎn)一起使用（參數(shù) enable_incremental_checkpoint ）。

不管選哪個(gè)，這兩個(gè)原子寫方案都有一個(gè)特點(diǎn)，就是數(shù)據(jù)庫層面的寫放大，對(duì)性能的影響也是很明顯。openGauss 可以關(guān)閉這個(gè)機(jī)制，代價(jià)就是數(shù)據(jù)安全。由于 openGauss 不支持 direct IO，所以沒有辦法使用 CSD 2000 的原子寫能力。在 MySQL 數(shù)據(jù)庫上，我們成功驗(yàn)證了關(guān)閉 MySQL 雙寫機(jī)制和使用 CSD 2000 的原子寫能力，sysbench 寫性能得到極大的提升（200%~350%）。

其他

openGauss 2. 1版本也提供了 IN-Place 更新機(jī)制，名為 Ustore 存儲(chǔ)引擎。應(yīng)該還在試用狀態(tài)，具體使用效果還待官方客戶案例分享。這里沒有測(cè)試，Ustore 跟 ORACLE、MySQL的更新模型一致了，對(duì)使用CSD后壓縮和性能提升影響應(yīng)該不會(huì)太大。

審核編輯 ：李倩