数据压缩

数据的持久化存储需要用户投入成本购买存储设备。虽然硬盘等存储设备的价格一直在下降,但由于数据的增长速度已经远远超出了设备价格下降的速度,所以用户的净存储成本实际上一直在增长。因此,使用高效的算法对数据进行压缩,可以大大减小存储空间的需求,降低用户的成本投入。

从软件系统层面来讲,对于数据库等特殊领域,需要对存储在磁盘等介质上的海量数据进行高频访问。此时,磁盘 I/O 就成为整体性能的一个关键节点。数据压缩后存储到磁盘,可以大大减小 I/O 需求,系统能够提供更高的性能和吞吐量。

衡量压缩效果的是压缩率(Compression ratio),是指压缩后大小与压缩前大小的比值,该值越小,表示压缩效果越好。影响压缩率的关键因素有两个:

  • 数据的重复度:压缩算法的核心思想都是使用更简短的方式来表示重复的内容,数据的重复度越高,压缩率越小
  • 压缩算法:压缩算法领域也没有“银弹”,不同的压缩算法都是在速度和压缩率之间进行取舍,更快的算法通常意味着更大的压缩率

SequoiaDB 巨杉数据库内部使用 BSON 结构来存储数据,这是一种类 JSON 的二进制编码格式。BSON 结构的一个重要特点是自描述,每条记录都包含完整的字段信息,因此数据中存在着大量的重复信息,这种特点使数据压缩具备了必要性与可行性。

数据压缩

SequoiaDB 在集合级提供了配置数据压缩的能力,开启之后会对插入的记录进行压缩。如前所述,影响数据压缩效果的因素主要是数据本身重复度及压缩算法的选择。SequoiaDB 提供了两种压缩策略,用户可根据实际业务场景灵活选择:

  • Snappy 压缩
  • LZW 压缩

使用数据压缩的方法很简单,在创建集合时,通过参数 Compressed 及 CompressionType 打开压缩并指定压缩类型即可:

> db.sample.createCL('employee', {Compressed:true, CompressionType:'lzw'})

Snappy 压缩

在 SequoiaDB 中,Snappy 压缩算法具有很高的压缩与解压速度,CPU 等资源开销比 LZW 低。压缩与解压就是数据的处理和迁移过程:原始记录在内存中被压缩,然后存入文件中,或者从文件中读取压缩的记录,在内存中解压使用。

compression_snappy

由于是以单条记录为单位进行压缩,记录内部的数据重复度直接影响到压缩率。因此,当记录内部数据重复度比较高,如字段名,字段值相似,只存在少量差异的情况下,使用 Snappy 算法可获得良好的压缩性能和压缩效果。如果记录内部数据重复度很低,但记录间具有更高的相似性,如相同的字段名或相近的字段值等,则使用 LZW 压缩更优。

LZW 压缩

基于集合中的记录通常具有相似的结构和值这一典型特征,SequoiaDB 中的 LZW 压缩算法使用一定规模的真实记录作为样本数据,分析其中的数据重复情况,提取出最有效的压缩字典,使用该压缩字典对新产生的数据进行压缩或对压缩数据进行解压。压缩字典也与集合数据一起持久化存储到数据文件中,节点重启后也可正常使用。

compression_lzw

数据库实例后台运行着一个字典构造器线程。创建集合时指定开启 LZW 压缩后,字典构造器的任务队列会添加一个新的字典创建任务。当开始处理一个集合的字典生成任务时,就从该集合中提取样本数据进行分析,并最终生成压缩字典,持久化存储到文件中。如果发现集合的样本数据过少(少于64MB 或 100 条记录),则会暂时挂起该任务,将它放到任务队列尾部,下一次轮询到它时再次进行处理。

compresion_dictionary

集群中各数据库实例的字典构造器都是独立的,因此即使是在同一个分区组内的主节点和从节点上,同一个集合生成的字典也可能是不一样的,压缩之后的数据也不一样,但解压出来的数据是一致的。 一般而言,推荐使用 LZW 压缩算法。虽然 LZW 压缩算法的速度不及 Snappy,且 CPU 开销相对较高,但由于 LZW 算法在更大范围样本数据的基础上生成了更有效的压缩字典,在典型的数据库应用场景中,其压缩效果通常远胜于 Snappy 压缩,具备更好的适用性。

回到顶部