This is an automated email from the ASF dual-hosted git repository.
wangdan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pegasus-website.git
The following commit(s) were added to refs/heads/master by this push:
new 5afb2d2d Update compression docs (#73)
5afb2d2d is described below
commit 5afb2d2d24c57a1ea684a6ac78ef10bf3d9b5636
Author: Yingchun Lai <[email protected]>
AuthorDate: Fri Feb 2 19:23:52 2024 +0800
Update compression docs (#73)
---
_docs/en/administration/compression.md | 45 +++++++++++++++++++++++++++++++++-
_docs/zh/administration/compression.md | 43 ++++++++++++++++----------------
2 files changed, 65 insertions(+), 23 deletions(-)
diff --git a/_docs/en/administration/compression.md
b/_docs/en/administration/compression.md
index 39778c8c..9c53b0fd 100755
--- a/_docs/en/administration/compression.md
+++ b/_docs/en/administration/compression.md
@@ -2,4 +2,47 @@
permalink: administration/compression
---
-TRANSLATING
+# Compression on the client side
+
+Please refer to the [Java client - Data
Serialization](/clients/java-client#data-serialization) and [Java client - Data
Compression](/clients/java-client#data-compression).
+
+# Compression on the server side
+
+It's recommended:
+* For the server with low CPU load, use the `zstd` algorithm with the highest
compression ratio.
+* For the server with high CPU load, use the `lz4` algorithm with good
compression rate and speed.
+
+The compression algorithms supported by the Pegasus server:
+* snappy
+* lz4 (Since Pegasus v1.11.2)
+* zstd (Since Pegasus v1.11.2)
+
+Configure the compression algorithm through [Configurations](config), for
example:
+```ini
+[pegasus.server]
+ rocksdb_compression_type = lz4
+```
+
+Comparison of different compression algorithms (from [zstd official
benchmark](https://facebook.github.io/zstd/)):
+
+| Compressor name | Ratio | Compression (MB/s) | Decompress (MB/s) |
+|------------------|-------|--------------------|-------------------|
+| zstd 1.3.4 -1 | 2.877 | 470 | 1380 |
+| zlib 1.2.11 -1 | 2.743 | 110 | 400 |
+| brotli 1.0.2 -0 | 2.701 | 410 | 430 |
+| quicklz 1.5.0 -1 | 2.238 | 550 | 710 |
+| lzo1x 2.09 -1 | 2.108 | 650 | 830 |
+| lz4 1.8.1 | 2.101 | 750 | 3700 |
+| snappy 1.1.4 | 2.091 | 530 | 1800 |
+| lzf 3.6 -1 | 2.077 | 400 | 860 |
+
+{:class="img-responsive"}
+
+This result is consistent with [lz4 official
benchmark](https://github.com/lz4/lz4#benchmarks).
+
+[Compression algorithm suggestions from RocksDB
official](https://github.com/facebook/rocksdb/wiki/Compression):
+> Use options.compression to specify the compression to use. By default it is
Snappy. We believe LZ4 is almost always better than Snappy. We leave Snappy as
default to avoid unexpected compatibility problems to previous users.
LZ4/Snappy is lightweight compression so it usually strikes a good balance
between space and CPU usage.
+
+> If you want to further reduce the in-memory and have some free CPU to use,
you can try to set a heavy-weight compression in the latter by setting
options.bottommost_compression. The bottommost level will be compressed using
this compression style. Usually the bottommost level contains majority of the
data, so users get almost optimal space setting, without paying CPU for
compress all the data ever flowing to any level. We recommend ZSTD. If it is
not available, Zlib is the second choice.
+
+> If you want have a lot of free CPU and want to reduce not just space but
write amplification too, try to set options.compression to heavy weight
compression type. We recommend ZSTD. Use Zlib if it is not available.
diff --git a/_docs/zh/administration/compression.md
b/_docs/zh/administration/compression.md
index 7775a8a6..8d62476e 100755
--- a/_docs/zh/administration/compression.md
+++ b/_docs/zh/administration/compression.md
@@ -4,46 +4,45 @@ permalink: administration/compression
# 客户端压缩
-请参考 [Java客户端文档#数据序列化](/clients/java-client#数据序列化) 和
[Java客户端文档#数据压缩](/clients/java-client#数据压缩) 。
+请参考 [Java 客户端 - 数据序列化](/clients/java-client#数据序列化) 和 [Java 客户端 -
数据压缩](/clients/java-client#数据压缩) 。
# 服务端压缩
-**把总结放在最前面：**
-* 对于CPU比较空闲的场景，建议采用压缩率高的`zstd`算法。
-* 对于CPU比较繁忙的场景，建议采用综合性能比较优异的`lz4`算法。
+建议：
+* 对于 CPU 比较空闲的服务器，采用压缩率最高的 `zstd` 算法。
+* 对于 CPU 比较繁忙的服务器，采用压缩率和速度都比较好的 `lz4` 算法。
-Pegasus服务端支持的压缩算法：
+Pegasus 服务端支持的压缩算法：
* snappy
-* lz4 (从v1.11.2版本开始支持)
-* zstd (从v1.11.2版本开始支持)
+* lz4 (从 v1.11.2 版本开始支持)
+* zstd (从 v1.11.2 版本开始支持)
-通过[配置文件](config)来配置压缩算法，譬如：
+通过 [配置文件](config) 来配置压缩算法，例如：
```ini
[pegasus.server]
rocksdb_compression_type = lz4
```
-不同压缩算法的比较（数据来自[zstd官方的benchmark](https://facebook.github.io/zstd/)）：
+不同压缩算法的比较（数据来自 [zstd 官方的 benchmark](https://facebook.github.io/zstd/)）：
-Compressor name | Ratio | Compression(MB/s) | Decompress(MB/s)
--- | -- | -- | --
-zstd 1.3.4 -1 | 2.877 | 470 | 1380
-zlib 1.2.11 -1 | 2.743 | 110 | 400
-brotli 1.0.2 -0 | 2.701 | 410 | 430
-quicklz 1.5.0 -1 | 2.238 | 550 | 710
-lzo1x 2.09 -1 | 2.108 | 650 | 830
-lz4 1.8.1 | 2.101 | 750 | 3700
-snappy 1.1.4 | 2.091 | 530 | 1800
-lzf 3.6 -1 | 2.077 | 400 | 860
+| Compressor name | Ratio | Compression (MB/s) | Decompress (MB/s) |
+|------------------|-------|--------------------|-------------------|
+| zstd 1.3.4 -1 | 2.877 | 470 | 1380 |
+| zlib 1.2.11 -1 | 2.743 | 110 | 400 |
+| brotli 1.0.2 -0 | 2.701 | 410 | 430 |
+| quicklz 1.5.0 -1 | 2.238 | 550 | 710 |
+| lzo1x 2.09 -1 | 2.108 | 650 | 830 |
+| lz4 1.8.1 | 2.101 | 750 | 3700 |
+| snappy 1.1.4 | 2.091 | 530 | 1800 |
+| lzf 3.6 -1 | 2.077 | 400 | 860 |
{:class="img-responsive"}
-这个结果与[lz4官方的benchmark](https://github.com/lz4/lz4#benchmarks)也是一致的。
+这个结果与 [lz4 官方的 benchmark](https://github.com/lz4/lz4#benchmarks) 是一致的。
-附上[RocksDB的压缩建议](https://github.com/facebook/rocksdb/wiki/Compression)：
+附上 [RocksDB 的压缩建议](https://github.com/facebook/rocksdb/wiki/Compression)：
> Use options.compression to specify the compression to use. By default it is
> Snappy. We believe LZ4 is almost always better than Snappy. We leave Snappy
> as default to avoid unexpected compatibility problems to previous users.
> LZ4/Snappy is lightweight compression so it usually strikes a good balance
> between space and CPU usage.
> If you want to further reduce the in-memory and have some free CPU to use,
> you can try to set a heavy-weight compression in the latter by setting
> options.bottommost_compression. The bottommost level will be compressed
> using this compression style. Usually the bottommost level contains majority
> of the data, so users get almost optimal space setting, without paying CPU
> for compress all the data ever flowing to any level. We recommend ZSTD. If
> it is not available, Zlib is the second choice.
> If you want have a lot of free CPU and want to reduce not just space but
> write amplification too, try to set options.compression to heavy weight
> compression type. We recommend ZSTD. Use Zlib if it is not available.
-
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
