摘要： 本章描述了 region 压缩机制, 它的好处和利用率. 在 Geode 中有一种减少内存消耗的方式是在 Region 中启动内存压缩机制。Geode 允许你压缩内存的 region 值，使用插件化的压缩器。Geode 包含了 Snappy 压缩器作为内置的压缩编码器；然而，你能够为每个已经压缩的...
本章描述了 region 压缩机制, 它的好处和利用率.
在 Geode 中有一种减少内存消耗的方式是在 Region 中启动内存压缩机制。Geode 允许你压缩内存的 region 值，使用插件化的压缩器。Geode 包含了 Snappy 压缩器作为内置的压缩编码器；然而，你能够为每个已经压缩的Region实现和指定一个不同的压缩器。
压缩什么值
在一个 Region 中当你启动压缩时，所有保存在 region 中的值都被压缩。Keys 和索引不能被压缩。新的值被压缩，当写入到缓存中时，当从缓存中读取数据时被解压缩。当持久化到磁盘时，这些值不压缩。当此值发送给其他成员或者客户端时进行解压缩操作。
当压缩启动时，region 中的每个值都被压缩，每个 region 条目都被压缩成一个单元. 单独压缩数据条目中的属性是不可能的.
在同一个缓存内可以有压缩和非压缩的混合模式
使用压缩指南
此篇描述了当什么时候进行压缩
回顾如下的指南决定是否启动压缩:
当 JVM 内存使用率太高时则使用压缩. 压缩允许你保存更多的 region 数据，同时减少 GC 循环周期，防止 JVMs 运行出 OOM异常故障，当内存使用高时.
为了确定是否 JVM 内存使用率高时, 检查如下的统计:
如果空闲内存量降低到 20% - 25% 或者 GC 循环处于高位时, 然后在 JVM 上的 region 比较合适启动压缩功能.
怎样在 region 中启动压缩
在 region 中为了启动压缩, 需要在 cache.xml 中设置如下的 region 属性:
<?xml version="1.0" encoding= "UTF-8"?>
<cache xmlns="http://schema.pivotal.io/gemfire/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd"
version="8.1” lock-lease="120" lock-timeout= "60" search-timeout= "300" is-server= "true" copy-on-read= "false" >
<region name="compressedRegion" >
<region-attributes data-policy="replicate" ... />
<Compressor>
<class-name>com.gemstone.gemfire.compression.SnappyCompressor</class-name>
</Compressor>
...
</region-attributes>
</region>
</cache>
在压缩器元素中，指定压缩器实现的类名。此例子指定了 Snappy 压缩器，与Geode 边界。你也能够指定一个自定义的压缩器。查看使用压缩器的示例。
当 region 创建时，压缩就能够被启动
gfsh:
gfsh>create-region --name=”CompressedRegion” --compressor=”com.gemstone.gemfire.compression.SnappyCompressor”;
API:
regionFactory.setCompressor(new SnappyCompressor());
或者
regionFactory.setCompressor(SnappyCompressor.getDefaultInstance());
怎么检查是否压缩是启动的
你也能检查是否一个 region 有压缩启动，通过查询哪个 codec 正在被使用。一个 null codec 提示对于 region没有压缩被启动。
Region myRegion = cache.getRegion("myRegion");
Compressor compressor = myRegion.getAttributes().getCompressor();
使用压缩器
当使用 region 压缩的时候，你能够使用默认的 Snappy压缩器，你能够指定你自己的压缩器
The single, default instance of the SnappyCompressor may be retrieved with theSnappyCompressor.getDefaultInstance() static method.
压缩 API 构成了一个单独的接口，用于实现自定义的压缩。默认的压缩器(SnappyCompressor)是一个单独的压缩实现，与产品进行绑定。而压缩器是无状态的，在 JVM 中只需要一个实例；然而，多个实例可能需要被使用。SnappyCompressor单独的实例可能使用SnappyCompressor.getDefaultInstance()来查询，
注意: Snappy 仅支持 Linux, Windows, 和 OS X 平台的部署.
示例提供了一个自定义的 Compressor 实现:
package com.mybiz.myproduct.compression;
import com.gemstone.gemfire.compression.Compressor;
public class LZWCompressor implements Compressor {
private final LZWCodec lzwCodec = new LZWCodec();
@Override
public byte[] compress(byte[] input) {
return lzwCodec.compress(input);
}
@Override
public byte[] decompress(byte[] input) {
return lzwCodec.decompress(input);
}
}在一个 Region 上使用一个新的自定义压缩器:
为已经压缩的 Region更改压缩器
你已经在region上启动了压缩，在 region 创建时. 你不能修改压缩器或者禁用压缩 ，当region在线时.
然而，如果你需要改变压缩器或者禁用压缩，你能够通过执行如下的步骤来做这件事:
比较压缩和非压缩的 Region
压缩 region 和非压缩 region的性能依赖于 region 怎么使用, 是否 region 在一个内存绑定的 JVM 上管理.
当考虑压缩的成本时, 你应该考虑读写压缩数据的相对成本，和压缩的成本 ，管理内存数据条目的时间百分比. operations than for region get operations. Because of this, enabling compression will create more overhead on regions that are write heavy than on regions that are read heavy.
通常来讲，启动压缩将增加 30% - 60% 以上的开销，对于 region 创建和更新来说。
然而，当你尝试评估启动压缩的性能开销时，你也应该考虑压缩的开销，与管理条目的开销相对应。一个 region 可能被调优，例如，一个不保存到磁盘的同步 region ，比分区 Region有更好地读写性能，在 region 上启动压缩，已经优化了读写性能，将提供更显著地结果，比在 region 上进行压缩，没有进行优化。性能将会几倍地降级，在一个读写优化 Region 上， 而在非优化的 region 上只会降级5-10百分点
在内存绑定的 JVM 中当启用压缩时。启用压缩通常假设 JVM 是内存边界的，因此耗费太多 GC 垃圾收集时间。在这种情况下，当运行在一个GC 周期中时，性能可能提升几倍，而 JVM 耗费GC 周期时间更小。
监控压缩性能
如下的统计提供缓存压缩的监控:
扫我，和云栖在线交流