對于列壓縮選項(xiàng),PostgreSQL 14提供了新的壓縮方法LZ4。與TOAST中現(xiàn)有的PGLZ壓縮方法相比,LZ4壓縮更快。本文介紹如何使用整個(gè)選項(xiàng),并和其他壓縮算法進(jìn)行性能比較。
背景
PG中,頁是存儲(chǔ)數(shù)據(jù)的單位,默認(rèn)是8KB。一般情況下,一行數(shù)據(jù)不允許跨頁存儲(chǔ)。然而,有一些變長的數(shù)據(jù)類型,存儲(chǔ)的數(shù)據(jù)可能超出一頁大學(xué)。為了克服整個(gè)限制,大字段域會(huì)被壓縮或者分割成多個(gè)物理行。這個(gè)技術(shù)就是TOAST:
默認(rèn)情況下,如果表中有變長列,行數(shù)據(jù)的大小超過TOAST_TUPLE_THRESHOLD(默認(rèn)2KB)就會(huì)觸發(fā)TOAST。首先,會(huì)先壓縮數(shù)據(jù);壓縮后如果仍然太大,會(huì)溢出存儲(chǔ)。需要注意,如果列的存儲(chǔ)策略指定EXTERNAL/PLAIN,壓縮會(huì)被禁止。
PG14之前版本,TOAST僅支持一個(gè)壓縮算法PGLZ(PG內(nèi)置算法)。但是其他壓縮算法可能比PGLZ更快或者有更高的壓縮率。PG14中有了新壓縮選項(xiàng)LZ4壓縮,這是一個(gè)以速度著稱的無損壓縮算法。因此我們可以期望它有助于提高TOAST壓縮和解壓縮的速度。
如何使用LZ4?
為了使用LZ4壓縮特性,在編譯時(shí)需要指定--with-lz4,并且在操作系統(tǒng)中按照LZ4庫。通過GUC參數(shù)default_toast_compression可以指定PG實(shí)例的TOAST默認(rèn)壓縮算法??梢栽趐ostgresql.conf中配置,也可以通過SET命令僅改變當(dāng)前連接:
postgres=# SET default_toast_compression=lz4;
SET
在CREATE TABLE創(chuàng)建表時(shí)指定列壓縮算法:
我們使用d+命令可以看到所有列的壓縮算法。如果列不支持或者沒有指定壓縮算法,那么會(huì)在Compression列顯示空格。上面的例子中,id列不支持壓縮算法,col1列使用PGLZ,col2使用LZ4,col3沒有指定壓縮算法,那么它會(huì)使用默認(rèn)的壓縮算法。
可以通過ALTER TABLE修改列壓縮算法,但需要注意,修改后的算法僅影響執(zhí)行整個(gè)命令后的insert數(shù)據(jù)。
postgres=# INSERT INTO tbl VALUES (1, repeat('abc',1000), repeat('abc',1000),repeat('abc',1000));
INSERT 0 1
postgres=# ALTER TABLE tbl ALTER COLUMN col1 SET COMPRESSION lz4;
ALTER TABLE
postgres=# INSERT INTO tbl VALUES (2, repeat('abc',1000), repeat('abc',1000),repeat('abc',1000));
INSERT 0 1
postgres=# SELECT id,
postgres-# pg_column_compression(id) AS compression_colid,
postgres-# pg_column_compression(col1) AS compression_col1,
postgres-# pg_column_compression(col2) AS compression_col2,
postgres-# pg_column_compression(col3) AS compression_col3
postgres-# FROM tbl;
id | compression_colid | compression_col1 | compression_col2 | compression_col3
---+-------------------+------------------+-----
1 | | pglz | lz4 | lz4
2 | | lz4 | lz4 | lz4
(2 rows)
可以看到在修改壓縮算法前插入的行,col1仍使用PGLZ壓縮算法,即使將壓縮算法從PGLZ修改到了LZ4。(那么,修改后進(jìn)行解壓時(shí)使用哪個(gè)算法呢?)
需要注意,如果從其他表掃數(shù)據(jù)插入本表,例如CREATE TABLE ...AS...或者INSERT INTO...SELECT...,插入的數(shù)據(jù)使用的壓縮算法仍然使用原始數(shù)據(jù)的壓縮方法。pg_dump和pg_dumpall也添加了選項(xiàng)--no-toast-compuression,使用整個(gè)選項(xiàng)后,不會(huì)dump出TOAST壓縮選項(xiàng)。
性能比較
測試了LZ4和PGLZ壓縮率和壓縮速度。并添加了未壓縮數(shù)據(jù)的測試結(jié)果(指定存儲(chǔ)策略為EXTERNAL),對于未壓縮數(shù)據(jù),沒有壓縮和解壓的耗時(shí),但讀和寫數(shù)據(jù)的時(shí)間會(huì)增加。
測試使用的數(shù)據(jù):PG documents(一行數(shù)據(jù)一個(gè)HTML文件);SilesiaCorpus提供的數(shù)據(jù),包括HTML、Text、源代碼、可執(zhí)行二進(jìn)制文件、圖片
測試機(jī)器使用Intel? Xeon? Silver 4210CPU@2.20GHz with 10 cores/20 threads/2 sockets。
使用pgbench測試SQL語句執(zhí)行時(shí)間,pg_table_size檢查表大學(xué)(每次執(zhí)行前都執(zhí)行VACUUM FULL排除死記錄的影響)。
壓縮率
PGLZ和LZ4的壓縮率都依賴于重復(fù)數(shù)據(jù),重復(fù)的元組越多,壓縮率越高。但是如果PG評估這樣的壓縮率不好時(shí),就不會(huì)執(zhí)行壓縮,即使數(shù)據(jù)大小達(dá)到了閾值。因?yàn)閴嚎s并沒有高效節(jié)省磁盤空間,還會(huì)帶來解壓鎖的額外時(shí)間和資源消耗。
當(dāng)前PG14中,PGLZ需要至少25%的壓縮率,LZ則僅比未壓縮數(shù)據(jù)時(shí)小即可。我比較了LZ4、PGLZ的表與未壓縮表大小??梢钥吹?,大部分場景下,PGLZ的壓縮率稍微好點(diǎn),壓縮率評價(jià)為2.23,LZ4的壓縮率為2.07。這意味著PGLZ可以節(jié)省7%的磁盤空間。
Figure 1 - Comparing table sizes (in KB)
壓縮/解壓縮速度
Insert和查詢時(shí)TOAST數(shù)據(jù)會(huì)被壓縮和解壓縮。因此,我執(zhí)行一些SQL語句查看不同壓縮算法帶來的影響。
首先比較了INSERT語句,列使用LZ、PGLZ和未使用壓縮時(shí)的性能。可以看到與未壓縮數(shù)據(jù)比,LZ4耗費(fèi)稍微多一點(diǎn)時(shí)間,PGLZ耗費(fèi)時(shí)間更多。LZ4的壓縮時(shí)間比PGLZ平均節(jié)省20%。這是一項(xiàng)非常顯著的改進(jìn)。
Figure 2 - Comparing INSERT performance
下面比較SELECT。與PGLZ相比,LZ4可以節(jié)省20%的時(shí)間,與未壓縮數(shù)據(jù)相比,沒有太大差別。解壓縮的消耗已經(jīng)降到了很低了。
Figure 3 - Comparing SELECT performance
再比較16個(gè)客戶端的INSERT語句并發(fā)。與PGLZ相比使用LZ4的單大文件(HTML,英文文本,源代碼,二進(jìn)制執(zhí)行文件,圖片)的壓縮性能快60%-70%。插入多個(gè)小文件(PG文檔),性能提升不大。和未壓縮的數(shù)據(jù)相比,有巨大提升,猜測使用壓縮減少了寫入磁盤的數(shù)據(jù)量。
Figure 4 - Comparing INSERT performance with 16 clients
16個(gè)客戶端的SELECT,多數(shù)場景下,LZ4性能優(yōu)于PGLZ:
Figure 5 - Comparing SELECT performance with 16 clients
同樣也比較了使用字符串函數(shù)的SELECT、UPDATE處理文本的速度。整個(gè)場景下LZ4優(yōu)于PGLZ。LZ4壓縮算法的數(shù)據(jù)與未壓縮數(shù)據(jù)相比,函數(shù)處理的速度幾乎一樣,LZ4算法幾乎不會(huì)影響字符串操作速度。
Figure 6 - Comparing performance using string functions
與PGLZ相比,LZ4壓縮和解壓縮TOAST數(shù)據(jù)更加高效,并提供很好的性能。和未壓縮數(shù)據(jù)相比,查詢速度幾乎一樣,和PGLZ相比,插入快80%。當(dāng)然某些場景下壓縮率不太好,但如過你想要提升執(zhí)行速度,強(qiáng)烈推薦使用LZ4算法。
同樣需要注意,需要考慮表中的數(shù)據(jù)是否合適壓縮。如果壓縮率不好,它仍然會(huì)嘗試壓縮數(shù),然后放棄。這將導(dǎo)致額外的內(nèi)存資源浪費(fèi),并極大影響插入數(shù)據(jù)的速度。
未來
LZ4對TOAST的壓縮和解壓縮性能帶來了很大提升。除了LZ4,還有很多其他壓縮算法比如Zstandard。支持Zstandard用戶可以得到比PGLZ更好的壓縮率。LZ4 HC具有比LZ4解壓98.5%的壓縮速度,但是可以大幅提升壓縮率。希望未來PG版本可以使用更多的壓縮算法。
除了TOAST外,其他場景也需要壓縮。據(jù)我所知,目前開發(fā)版本已經(jīng)支持WAL的LZ4壓縮,這是一項(xiàng)令人興奮的特性。
-
算法
+關(guān)注
關(guān)注
23文章
4587瀏覽量
92501 -
SQL
+關(guān)注
關(guān)注
1文章
753瀏覽量
44032
發(fā)布評論請先 登錄
相關(guān)推薦
評論