SQL Server数据压缩绝对适合只读数据库吗？

我读过一些有关SQL Server数据压缩的文献，指出写入成本增加到通常需要的四倍。似乎还暗示这是数据压缩的主要缺点，强烈暗示对于只读存档数据库，使用100％填充页面的数据压缩将提高性能（仅少数例外）。

1. 以上陈述正确吗？

2. 数据压缩与其他方式（用于读取）之间的主要“差异”是什么？

   • “ CPU + x％”？
   • “ IO -y％”？
   • 页面拆分发生了吗？
   • tempdb的用法？
   • RAM使用率？
3. 和写作？

出于这个问题的目的，您可以将上下文限制为大型（> 1TB）数据库的PAGE级压缩，但是始终欢迎其他注释。

参考文献：

SQL Server存储引擎博客（DW场景显示压缩非常有优势）
数据压缩：策略，容量规划和最佳实践

确定压缩内容的更详细方法涉及分析每个表和索引的工作负载特征。它基于以下两个指标：

U：相对于该对象的总操作数，特定表，索引或分区上的更新操作数的百分比。U的值越低（即不经常更新表，索引或分区），则它越适合用于页面压缩。
S：表，索引或分区上的扫描操作相对于该对象上的全部操作的百分比。S的值越高（即，表，索引或分区大部分被扫描），则用于页面压缩的候选值越好。

以上两种情况都明显偏向于建议为DW样式的数据库建议页面压缩（读密集型/排他性大数据操作）。

我在1-2岁硬件上进行的实验仅获得2美分：

页面压缩表（〜80行/页）上的只读操作（DW样式的扫描，排序等），我发现在压缩大小减小约3倍时达到了收支平衡。

也就是说，如果表仍然适合内存，则页面压缩仅在数据大小缩小3倍以上时才可提高性能。您扫描内存中的页面较少，但是扫描每个页面所需的时间更长。

我想如果您的计划是嵌套循环且繁重的，您的里程可能会有所不同。其中，这也将取决于硬件（外部NUMA节点访问损失，内存速度等）。

以上只是我的粗略经验法则，是基于我在自己的硬件（Dell Poweredge 910及更低版本）上使用自己的查询进行的测试运行所得出的。不是福音啊！

编辑：昨天，Thomas Kejser出色的SQLBits XI演示文稿已作为视频提供。与该讨论非常相关的是，页面压缩显示了CPU成本的“丑陋”面孔-更新速度降低了4倍，锁定时间更长了。

但是，Thomas使用的是FusionIO存储，他选择的表仅“适合”页面压缩。如果存储在典型的SAN上，并且数据使用的压缩率是3x-4x，则图像可能不太生动。

我可以在我的数据仓库环境中添加几句话。

在具有3000万行（18GB）的测试表上实施压缩（在我的情况下为PAGE）可将表的大小从18GB减少到3GB！（确定存储效率），但将加载时间（写入）从22分钟增加到36分钟。

因此，对于读取或读取数据并将其放置在内存中，这可能是一个很好的解决方案，但对于日常数据加载，则可能导致性能下降。