SQL Server 2008的新压缩特性

关于SQL Server压缩的故事,最早是从SQL Server 2005开始的,在企业版和开发版中增加了一种叫做vardecimal的新存储格式,这个表级的选项会影响到decimal和numeric字段。当对值的精度要求低于字段可用精度,如在一个decimal(18,9)类型的字段中存储1.5这个数值时,存储上就需要有相应的压缩。从效果上来看,它就是一个varchar类型的数字型版本。

SQL Server 2008所包含的已远不止这些小技巧,Chad Boyd写到 :

无论从哪方面来看,SQL Server 2008的数据压缩都与现在有着巨大的差异(尽管它依然支持或者说包括vardecimal类型)——引起这种差异的真像是,如果你对一个给定的table/index启用压缩功能,那么底层的row/page格式将不再相同——是的,就是这样,你听得没错——如果你使用压缩(ROW或者PAGE),那么SQL 2008的row/page格式将不同于现有的格式(如果你只是在table/index上使用压缩的话)。因此,在SQL 2008中,有两种,没错,是两种可选row/page数据格式。你现在可能会想知道“那么,如果row/page格式改变了,那你们究竟是如何在这么短的时间内,依然有足够的时间去重新生成SQL Server所有需要识别这些格式的组件的呢?”答案就是我们不需要那样做——因为Storage Engine是SQL 2008中唯一一个需要知道新的row/page格式的组件。

行级压缩将大幅减少元数据所需的变量长度,较以前每个字段需要花费2个字节来存储,现在只要仅仅3个位。字段本身现在也变得更小,在整型字段中存储像1这样的数值,只需要一个字节,而大数值则最多只需要4个字节。

行级压缩则允许在行间共享共有数据。Chad首先谈到的两种技术就是列前缀和页字典:

假设你在一页的数据行中有一列数据有这些值:‘Chad’、‘Chadwick’、‘Chadly’、‘Chad’、‘Chadster’、‘Chadwick’和‘Chadly’(故意重复的数值)——正如你所见,有相当多的冗余‘前缀’数据在这一页的同一列的不同行中,是吧?因此,你最终可能会想到这样的一个场景:将列的前缀‘Chad’存储在CI结构中,每一个列的最后都指向这个前缀值,最后出现在磁盘上的值会像这样:‘’,‘1wick’,‘1ly’,‘1ster’,‘1wick’和‘1ly’。

所以,对于上述例子中的含有Chad的同列数值,在经过对“列前缀”值进行计算和存储后,你可能得到一个会含有如‘1ly’和‘1wick’这些值的页字典,而真正行内数值则极有可能看上去像这样:‘’、‘2’、‘3’、‘’、‘1ster’、‘3’和‘2’。通过这种方式,我们让原本需要大约25个字节来存储的行数据,减少到只要大约17个字节来存储,节省30%以上。

每一个页都是单独压缩的,前缀和字典也存储在页内。由于页是存储分配的原子单位,将半页压缩到四分之一页是没有任何意义的,所以,只有在页的内容快满的时候才会开始压缩处理。

在使用行和页压缩时还有一个性能权衡问题,因为CPU使用率会上升,但I/O使用率和内存占用会下降。

Backup Compression是2008的另一个特性,它是通过普通的文件系统型压缩技术实现的,对于给定的数据库,只有启用或者禁用,没有其它可调节选项。

尽管非企业版服务器可以恢复带压缩的备份,但这所有的压缩选项极有可能成为企业版专享选项。

查看英文原文:New Compression Features in SQL Server 2008

你可能感兴趣的:(SQL Server 2008的新压缩特性)