首页  »   其他数据库

替 Greenplum 增加 Zstandard 压缩功能

网友分享于:2017-04-20  浏览:0次
为 Greenplum 增加 Zstandard 压缩功能

为 Greenplum 增加 Zstandard 压缩功能

作者:Arthur_Qin 禾众

目前在做的基于 Greenplum 的修改将造成额外的数据读写,这就加剧了磁盘 I/O 的代价。我们采取对数据进行有效压缩的方法来抵消这部分代价。

压缩算法比较

压缩算法有很多,较为通用的有 zlib, QuickLZ, LZO, LZ4, Zstandard 。前两者已经原生内嵌在 GPDB 系统中(因版权问题,QuickLZ 在最新的开源版本中已被移除),可直接调用接口使用,但 zlib 的实际使用效果并不理想。而 LZO 和 LZ4,凭借快速压缩解压的特点,在 hive, spark, lucene 等框架中被广泛采用,但压缩率逊与 zlib 。近年,Facebook 在 LZ4 作者 Collet 之前所做的工作基础上发布并开源了 Zstandard(简称 Zstd ),在资源占用和压缩效果方面都优于 zlib 。

下面给出两组分别来自于 Zstd 和 LZ4 的 Benchmarks 比较:

Benchmarks A: Linux Mint Debian edition server (Linux version 4.8.0-1-amd64), with a Core i7-6700K CPU @ 4.0GHz, using lzbench.

Compressor Ratio Compression Decompression
zstd 1.1.3 -1 2.877 430 MB/s 1110 MB/s
zlib 1.2.8 -1 2.743 110 MB/s 400 MB/s
quicklz 1.5.0 -1 2.238 550 MB/s 710 MB/s
lzo1x 2.09 -1 2.108 650 MB/s 830 MB/s
lz4 1.7.5 2.101 720 MB/s 3600 MB/s
snappy 1.1.3 2.091 500 MB/s 1650 MB/s

Benchmarks B: Compiled with GCC v6.2.0 on Linux 64-bits, with s a Core i7-3930K CPU @ 4.5GHz. sing lzbench, in single-thread mode.

Compressor Ratio Compression Decompression
memcpy 1.000 7300 MB/s 7300 MB/s
LZ4 fast 8 (v1.7.3) 1.799 911 MB/s 3360 MB/s
LZ4 default (v1.7.3) 2.101 625 MB/s 3220 MB/s
LZO 2.09 2.108 620 MB/s 845 MB/s
QuickLZ 1.5.0 2.238 510 MB/s 600 MB/s
Snappy 1.1.3 2.091 450 MB/s 1550 MB/s
Zstandard 1.1.1 -1 2.876 330 MB/s 930 MB/s
Zstandard 1.1.1 -3 3.164 200 MB/s 810 MB/s
zlib deflate 1.2.8 -1 2.730 100 MB/s 370 MB/s
LZ4 HC -9 (v1.7.3) 2.720 34 MB/s 3240 MB/s
zlib deflate 1.2.8 -6 3.099 33 MB/s 390 MB/s

通过比较,我们不难发现。在所有常见压缩算法中,Zstd 拥有最好的压缩率,LZ4 拥有最好的压缩和解压缩时间。使用以上算法测试数据压缩,结论依旧有效。由于在之前的性能分析中已基本确认在我们的系统里数据落盘是性能的较大影响因子,因此我们优先选用 Zstd 算法。

调用 Zdtd 接口实现数据压缩

我们依照 GPDB 自带的 zlib 接口实现 Zstd 压缩。当数据生成后将落盘时,将会调用压缩函数指针,最终写入的是压缩后的数据。同理,当我们需要读出数据时,读操作同样会调用解压缩接口,获取完整可读的数据。因为我们用 Zstd 替代了 zlib ,压缩解压的时间大大减少,压缩率也更加优异,整体有较大收益。

Zstd 取代 zlib

性能分析

为了明确采用压缩方案后各环节的收益和代价,我们设计了若干简单查询,测试在原 TPC-H 500 G 测试数据下的系统性能。

具体内容略。在实验中,Zstd 的实际压缩率为 2.8 - 3.3,I/O 代价降至原来的 1/3 左右。

压缩的性能比较

实验数据显示,在我们的系统中,将内存中的数据写回硬盘是最耗时的操作(左图中绿色柱型图,在不压缩的情况下长度为现在的三倍左右),采用 Zstd 压缩的办法,虽然花费了少量时间用于压缩(深蓝色)和解压缩(红),但整体来看是划算的。我们再对比不压缩的代码版本,我们可以看出,压缩的版本(蓝)在性能上有明显提升。因此在我们的系统中,Zstd 压缩将作为默认选项,用户在实际使用中可以根据具体的环境配置情况选择关闭。

Zstd 的文档比较完善,具体请参考以下链接。

https://github.com/facebook/zstd

https://github.com/facebook/zstd/tree/dev/doc

转载请注明 作者 Arthur_Qin(禾众) 及文章地址 http://www.cnblogs.com/arthurqin/p/6594879.html

相关解决方案

最新解决方案