原文：https://www.altinity.com/blog/2017/11/21/compression-in-clickhouse
Altinity是國外一家從事ClickHouse咨詢、服務(wù)的公司，該公司高管由ClickHouse開發(fā)者趾娃，以及來自Percona的專家組成笋除。目前Altinity的ClickHouse云服務(wù)測試版已經(jīng)上線。
綜述
It might not be obvious from the start, but ClickHouse supports different kinds of compressions, namely two LZ4 and ZSTD.
There are evaluations for both of these methods:https://www.percona.com/blog/2016/04/13/evaluating-database-compression-methods-update/
But in short, LZ4 is fast but provides smaller compression ratio comparing to ZSTD. While ZSTD is slower than LZ4, it is often faster and compresses better than a traditional Zlib, so it might be considered as a replacement for Zlib compression.
其實(shí)约素，從一開始ClickHouse就支持多種方式的數(shù)據(jù)壓縮：LZ4和ZSTD。
關(guān)于壓縮算法的測試拇囊，見這篇文章硅急。簡而言之枢冤，LZ4在速度上會更快，但是壓縮率較低铜秆，ZSTD正好相反淹真。盡管ZSTD比LZ4慢，但是相比傳統(tǒng)的壓縮方式Zlib连茧，無論是在壓縮效率還是速度上核蘸，都可以作為Zlib的替代品。
實(shí)際壓測
To get some real numbers using ClickHouse, let’s review a table compressed with both methods.
For this, we will take the table lineorder, from the benchmark described inhttps://www.altinity.com/blog/2017/6/16/clickhouse-in-a-general-analytical-workload-based-on-star-schema-benchmark
The uncompressed datasize for lineorder table with 1000 scale is 680G.
為了用事實(shí)說話啸驯，我們一起對比一下這兩種壓縮方式客扎。
壓測所用的表（lineorder）結(jié)構(gòu)和數(shù)據(jù)來著這里。
未壓縮的數(shù)據(jù)集是680GB罚斗。
數(shù)據(jù)對比
And now let’s load this table into ClickHouse. With the default compression (LZ4), we have184G lineorderlz4
And with ZSTD135G lineorderzstd
There we need to mention how to make ClickHouse using ZSTD. For this, we add the following lines into config:
把上述數(shù)據(jù)加載到ClickHouse后徙鱼，默認(rèn)的LZ4壓縮算法下，數(shù)據(jù)容量是184G（壓縮到27%）针姿，而ZSTD達(dá)到了135GB（壓縮到20%）袱吆。
關(guān)于如何使用ZSTD，需要簡單的提一下距淫，使用如下配置即可：
zstd
So the compression ratio for this table
壓縮比率對比
CompressionRatio
LZ43.7
ZSTD5.0
What about performance? For this let’s run the following query
壓縮后的性能如何绞绒，我們來跑如下查詢看看。
SELECTtoYear(LO_ORDERDATE)ASyod,sum(LO_REVENUE)FROMlineorderGROUPBYyod;
And we will execute this query in “cold” run (no data is cached), and following “hot” run when some data is already cached in OS memory after the first run.
為了保持客觀榕暇，我們會跑兩次蓬衡，第一次是冷數(shù)據(jù)請求，這次的數(shù)據(jù)沒有被操作系統(tǒng)緩存彤枢，第二次跑一次熱數(shù)據(jù)情求狰晚，這次的數(shù)據(jù)已經(jīng)被操作系統(tǒng)的內(nèi)存給緩存住了。
So query results, for LZ4 compression:
LZ4的性能如下：
# Cold run:
7 rows in set. Elapsed: 19.131 sec. Processed 6.00 billion rows,
36.00 GB (313.63 million rows/s., 1.88 GB/s.)
Hot run:
7 rows in set. Elapsed: 4.531 sec. Processed 6.00 billion rows,
36.00 GB (1.32 billion rows/s., 7.95 GB/s.)
For ZSTD compression:
ZSTD性能如下：
Cold run:
7 rows in set. Elapsed: 20.990 sec. Processed 6.00 billion rows,
36.00 GB (285.85 million rows/s., 1.72 GB/s.)
Hot run:
7 rows in set. Elapsed: 7.965 sec. Processed 6.00 billion rows,
36.00 GB (753.26 million rows/s., 4.52 GB/s.)
While there is practically no difference in cold run times (as the IO time prevail decompression time), in hot runs LZ4 is much faster (as there is much less IO operations, and performance of decompression becomes a major factor).
冷數(shù)據(jù)查詢情況下缴啡，兩者區(qū)別不大壁晒，原因在于消耗在IO方面的時間，遠(yuǎn)大于消耗在解壓縮上面的時間盟猖。
熱數(shù)據(jù)請求下讨衣，LZ4會更快，此時IO代價小式镐，數(shù)據(jù)解壓縮成為性能瓶頸反镇。
Conclusion:
結(jié)論
ClickHouse proposes two methods of compression: LZ4 and ZSTD, so you can choose what is suitable for your case.
With LZ4 you may get a better execution time with the cost of the worse compression and data taking more space on the storage.
ClickHouse提供了兩種數(shù)據(jù)壓縮方式供我們選擇：LZ4和ZSTD。
默認(rèn)的LZ4壓縮方式娘汞，會給我們提供更快的執(zhí)行效率歹茶，但是同時，我們要付出較多的磁盤容量占用的代價了。
譯者注
ClickHouse在我們公司（Sina）內(nèi)部已經(jīng)有一段時間的使用了惊豺，拋開高效的SQL執(zhí)行燎孟，數(shù)據(jù)容量也是一個非常喜人的地方
我們使用的是大容量的服務(wù)（沒錯，就是Hadoop node節(jié)點(diǎn)的低配機(jī)器）尸昧，單機(jī)容量輕松幾十T揩页，再加上ClickHouse優(yōu)秀的壓縮方式，日志數(shù)據(jù)存1-2年烹俗，都沒有一點(diǎn)問題
我們沒修改過壓縮算法爆侣，就用的默認(rèn)的LZ4
作者：JackpGao
