关于 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 的另一个特性,它是通过普通的文件系统型压缩技术实现的,对于给定的数据库,只有启用或者禁用,没有其它可调节选项。
尽管非企业版服务器可以恢复带压缩的备份,但这所有的压缩选项极有可能成为企业版专享选项。
评论