作者：蒋步星

来源：数据蒋堂

本文共2600字，建议阅读9分钟。如果能物理地减少数据存储量，也就自然而然地减少了外存访问量。

我们知道，外存（硬盘）的性能远远低于内存，即使是同样复杂度的运算（CPU计算量相同），如果能减少外存的访问量，也会大大提高整体性能。甚至有时我们需要用CPU换硬盘，即宁可多消耗些CPU时也要减少硬盘访问量，一方面CPU性能更好，另一方面是CPU比硬盘更容易并行，现代计算机的CPU核数常常远远超过硬盘的并发访问能力，数据密集型的任务应当更多地使用CPU的能力。

如果能物理地减少数据存储量，也就自然而然地减少了外存访问量。

列存是常见的减少外存访问量的手段，不过，仅仅是简单地采用列式存储，并不会真正地减少数据存储量。但是，使用列存之后，数据的可压缩性将大大提高。同一列的数据一般具体有相同的数据类型甚至近似的取值，大多数压缩算法在这种情况的工作效果要比针对杂乱类型数据时好很多，这样就能大幅度地减少数据存储量了。所以，列存不仅是在访问量上占便宜，即使访问表中所有列，列存的硬盘读取量要也比行存更少。在表的列数不多时，列存仍然有优势。

通用的压缩算法不能假定数据有某种特征，只能是将数据当作随意的字节流去编码，有时并不能获得最好的压缩率。而且，高压缩率的算法常常会消耗过多的CPU，甚至于会到了拿CPU换硬盘都不划算的地步。所以，我们不能完全指望压缩算法，还要自己先对数据做一些手脚，人为地制造某些数据特征来利用，就可以采用较低压缩率同时低CPU消耗的压缩算法，也获得较好的压缩效果。

一个常用的办法是排序。

数据表的列中常常有许多是维度，比如地区、日期等。这些维度的取值基本都在一个小集合范围内，在大数据量时会有很多重复取值。如果数据是按这些列排序的，则相邻记录之间取值相同的情况就很常见，而这时使用很轻量级的压缩算法也能获得很好的压缩率，简单来讲，直接记录列值及其重复次数都能起到不错的压缩效果。

排序时的次序也有讲究。要尽量把取值较长的列放在前面排序。比如有地区和性别两个列，地区的取值长度要大于性别，则先地区后性别排序的效果就要好于反过来的情况。

先地区排序：

先性别排序：

前者存储：北京（3个），上海（2个）；男（2个），女（1个），男（1个），女（1个）；总字符数为8（只数字符个数，括号中的次数不记）。

后者存储：北京（2个），上海（1个），北京（1个），上海（1个）；男（3个），女（2个）；总字符为10。

地区的字符数比性别要长，把长的排到前面的存储量会更小。

上面的例子中，我们还可以把“北京”、“上海”这些字符串事先转换成数字编码，而不要直接使用原始字符串，这样也能减少存储量。“北京”是个2个字符的串，如果用数字1代替就变成1个字符了。有些枚举形字符串列的取值很长，转换成数字编码会有很好的效果。做了编码转换后，在使用的时候会有些麻烦，需要再转换回来。不过，和获得的性能提升相比，这些麻烦还是值得的。

整数（从字符串编码而来或本身就是整数）的存储也有些技巧。现代计算机的整数一般是32位的，要占4个字节。但很多整数很小，比如从省份转换过来的整数不会超过100，这4个字节的高3字节全是0，有些浪费；性别转换过来的只有1和2两种，而4个字节的整数甚至长于1或2个字节的“男”,“女”值本身了，这个转换反而不划算了。

这时候就要设计合理的编码方式，不要让所有整数都占用同样长度的空间，让小正整数只用1-2个字节就能表示，大正整数以及负整数（负数很罕见）才要占满4个字节，甚至5个字节（否则信息空间是不够的），因为小正整数更常见，整体存储空间还是会变少。

类似的技巧还可以用于日期存储上，一般来讲与某个确定日期距离较近的且过去的日期会更多一些，这时可采用某种编码方式让这些值变短，而距离远的以及将来的日期可以使用长编码。

这些编码方案看起来很不起眼，一次只能减少一两个字节，但当数据量很大时效果就相当可观。

对于应用程序员来讲，一般不会直接控制到这种细节层面了。不过，了解所选用的数据库（或别的有数据存储功能的产品）采用的压缩手段还是有必要的，这样才能更准确地预估运算性能。

专栏作者简介

润乾软件创始人、首席科学家

清华大学计算机硕士，中国大数据产业生态联盟专家委员，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016、2017年，荣获中国电子信息产业发展研究院评选的“中国软件和信息服务业十大领军人物”；2017年度中国数据大工匠、数据领域专业技术讲堂《数据蒋堂》创办者。

数据蒋堂

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

数据蒋堂第二年往期回顾：

数据蒋堂 | 莫非我就是被时代呼唤的数学人

数据蒋堂 | SQL是描述性语言？

数据蒋堂 | 存储和计算技术的选择

数据蒋堂 | 人工智能中的“人工”

数据蒋堂 | 中国报表漫谈

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 多维分析预汇总的功能盲区

数据蒋堂 | 多维分析预汇总的存储容量

数据蒋堂 | 多维分析预汇总的方案探讨

数据蒋堂 | 数据库的封闭性

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 前半有序的大数据排序

数据蒋堂 | “后半”有序的分组

数据蒋堂 | 时序数据从分表到分库

数据蒋堂 | BI系统的前置计算

数据蒋堂 | 性能优化是个手艺活

数据蒋堂 | 数据分布背后的逻辑

数据蒋堂 | 从一道招聘考题谈起

数据蒋堂 | 为什么我们需要C程序员

数据蒋堂 | 报表工具的SQL植入风险

数据蒋堂 | 内置的数据无法实现高性能

数据蒋堂 | 怎样生成有关联的测试数据

数据蒋堂 | 遍历复用