Tag: zstd

gzip 的 --rsyncable (zstd 也有)

查資的時候 gzip 發現有 --rsyncable 這個參數，號稱是產生出對 rsync 友善的壓縮檔：

When you synchronize a compressed file between two computers, this option allows rsync to transfer only files that were changed in the archive instead of the entire archive. Normally, after a change is made to any file in the archive, the compression algorithm can generate a new version of the archive that does not match the previous version of the archive. In this case, rsync transfers the entire new version of the archive to the remote computer. With this option, rsync can transfer only the changed files as well as a small amount of metadata that is required to update the archive structure in the area that was changed.

這個參數的說明可以參考「Rsyncable gzip」這篇，從發表的日期是 2005 年就可以看出來這個參數已經很久了：

With this option, gzip will regularly “reset” his compression algorithm to what it was at the beginning of the file. So if for example there was a change at byte 23, this change will only affect the output up to maximum (for example) byte #9999. Then gzip will restart ‘at zero’, and the rest of the compressed output will be the same as what it was without the changed byte 23. This means that rsync will now be able to re-synchronise between the old and new compressed file, and can then avoid sending the portions of the file that were unmodified.

這個參數的想法是，正常狀態下的 gzip 會因為來源的微小改變，造成後續壓縮的內容都完全不一樣。

但加上 --rsyncable 後，gzip 就會定時重設壓縮狀態 (reset)，於是讓壓縮後的輸出內容有大部分的內容重複，於是 rsync 就能夠偵測到相同內容而避免大量重傳。

但反過來的缺點面也就馬上可以想到，這是犧牲一些壓縮演算法的效率，付出的代價就是輸出的檔案會大一點。

這個功能在 zstd 上也有，不過 xz 就沒有...

我拿 zstd -19 (zstd 最高的壓縮率？) 測試 BBS 的備份，一般壓縮是 513672097 bytes，而加上 --rsyncable 後的壓縮是 513831761 bytes，發現是萬分之幾的增加，等於是只多了零頭...？

看起來會是蠻好用的參數，特地寫一篇記錄起來...

PostgreSQL 15 釋出

PostgreSQL 15 出了：「PostgreSQL 15 Released!。

先前提到過「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」，反而沒排上這次 release 的重點，翻了一下的確是排不太上 XD

第一個超大的改善是 sorting：

In this latest release, PostgreSQL improves on its in-memory and on-disk sorting algorithms, with benchmarks showing speedups of 25% - 400% based on which data types are sorted.

在「Speeding up sort performance in Postgres 15」這邊有提到四個改動，裡面很詳細的說明了改動的內容，以及 benchmark 差異。

如果以他列出來的四個進展，應該是第二個「Reduce memory consumption by using generation memory context」這個會最容易遇到，也改善最多：

另外是第三個「Add specialized sort routines for common datatypes」也會有一些：

再來是拿 PostgreSQL 當 OLAP engine 用的時候會發生的第四個「Replace polyphase merge algorithm with k-way merge」：

最開頭第一個「Improvements sorting a single column」的 SELECT col1 FROM tab ORDER BY col1; 這種 case 好像用的很少，限制 SELECT 的部份也只能出現後面 sorting 的 column，但如果遇到的話效能提昇很多：

除了 sorting 的改善以外，另外一個是 WAL 支援 LZ4 與 zstd，這對於有寫入量很大的環境應該會有幫助：

PostgreSQL 15 adds support for LZ4 and Zstandard (zstd) compression to write-ahead log (WAL) files, which can have both space and performance benefits for certain workloads.

正式版出來後，應該會有一些整體性的 benchmark 數字可以看，再來等著看...

SQLite 的 zstd extension

看到「sqlite-zstd」這個實驗性質的專案，可以針對 SQLite 的 row-level 層壓縮：

Extension for sqlite that provides transparent dictionary-based row-level compression for sqlite. This basically allows you to compress entries in a sqlite database almost as well as if you were compressing the whole DB file, but while retaining random access.

看起來在空間上有很不錯的成果：

作者在他自己的 blog 上面有給了一篇比較完整的說明，除了空間上的優勢以外，還包含了效能上的分析：「sqlite-zstd: Transparent dictionary-based row-level compression for SQLite」。

在文章裡面測出來的數據看起來在效能上就不一定有比較好的結果，本來的 SQLite 就已經處理的還不錯了。

但看起來是個還蠻有趣的東西，舉例來說，如果可以透過 WebAssembly 編譯，再配合之前的「把 SQLite 的 VFS 掛上 WebTorrent 的 PoC Demo」，可以省下不少傳輸的量...

可以看看後續會不會真的有人這樣幹 XD

MyRocks/MariaDB 的 tuning 過程

看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。

看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：

Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.

這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：

The servers were close to their limits and were slow to catch up with replication after a maintenance period

後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。

另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。

不過在「Increased Read Load Over Time」那段還是看到了 workaround：

The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.

目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...

Arch Linux 決定把套件壓縮演算法從 xz 換成 Zstandard

看到 Arch Linux 的公告，他們決定把套件的壓縮演算法從 xz 換成 Zstandard：「Now using Zstandard instead of xz for package compression」。

從 xz 換成 Zstandard 主要的原因在於不用犧牲太多空間 (多 0.8% 的空間)，但解壓縮的速度可以大幅提昇 (提昇 13 倍)：

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

看起來是不斷發酵... 在幾個月前隔壁棚的 Fedora 先換過去了，計畫在「Changes/Switch RPMs to zstd compression」這邊可以翻到，而 issue tracking system 上的記錄可以參考「Issue #350: F31 System-Wide Change: Switch RPMs to zstd compression - release-notes - Pagure.io」。

看起來會是趨勢了...