openGauss數(shù)據(jù)庫在可計算存儲CSD上探索

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

CSD 測試效果

測試場景簡介

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

§BenchmarkSQL TPC-C場景

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

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

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

§sysbench OLTP 場景

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

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

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

存儲空間壓縮效果

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

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

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

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

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

性能對比

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

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

§SYSBENCH （FF=100）性能

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

讀寫混合場景的每秒請求數(shù)QPS：

讀寫混合場景的平均延時 RT：

§SYSBENCH （FF=75）性能

讀寫混合場景的每秒請求數(shù)QPS：

讀寫混合場景的平均延時 RT：

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

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

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

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

openGauss存儲特性簡介

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

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

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

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

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

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

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

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

可計算型存儲 CSD 簡介

常用壓縮方案

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

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

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

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

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)上不會開啟壓縮。一些 NewSQL 數(shù)據(jù)庫使用 LSM Tree 模型的，也自帶壓縮能力。如果數(shù)據(jù)庫強行開啟壓縮，那么數(shù)據(jù)文件在 CSD 上壓縮比還要根據(jù)實際情況看。這涉及到 CSD 壓縮的原理。

CSD 原理特性

§定長塊 IO

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

§壓縮算法

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

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

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

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

§壓縮比

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

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

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

§OP 空間

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

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

§CSD 容量擴容

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

§原子寫

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

前面提到很多關(guān)系數(shù)據(jù)庫數(shù)據(jù)塊大小都是 4K 的倍數(shù)，在發(fā)生機器故障時，有可能出現(xiàn)數(shù)據(jù)塊寫到文件里部分成功部分失敗的情形下。即使數(shù)據(jù)庫開啟了 WAL（Write Ahead Logging）機制，也不一定能保證數(shù)據(jù)庫恢復(fù)后該數(shù)據(jù)塊也能正確恢復(fù)。在 MySQL 里，通過先同步順序?qū)懸粋€共享表空間文件，然后再寫數(shù)據(jù)文件的方式來規(guī)避問題。在故障發(fā)生后如果發(fā)現(xiàn)數(shù)據(jù)塊校驗有問題，就直接用該共享表空間的內(nèi)容覆蓋數(shù)據(jù)文件上的數(shù)據(jù)塊進行恢復(fù)。這個機制叫雙寫。在 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），默認使用的是雙寫方案。雙寫方案跟開啟增量檢查點一起使用（參數(shù) enable_incremental_checkpoint ）。

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

其他

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

審核編輯 ：李倩