【数据蒋堂】第41期：文件的性能分析

我们以前讲过硬盘的性能特征，主要是针对硬件层面进行分析的，现在我们来考虑软件层面的差异。

理论上讲，软件可以穿过操作系统直接进行磁盘扇区的访问，但实在太过于麻烦而几乎不会实践机会，这里就不考虑了，我们只讨论操作系统下的存储形式，而文件就是其中重要的存储形式。

文件一般有两种：文本文件和二进制文件，我们分别来讨论。

文本是很常见的数据存储形式，它具有通用性易读性等优点而被广泛使用。但是，文本的性能却非常差！

文本字符不能直接运算，需要转换成整数、实数、日期、字符串等内存数据类型才可以进一步处理，而文本的解析是个非常复杂的任务。

举个例子，设想一下把文本“12345"转成内存二进制整数12345的过程：

1. 先设结果的初始值为0
2. 拆出字符“1”，解析出数值1，将初值0乘以10加上这个1得到数值1
3. 再拆出字符“2”，解析出数值2，把刚才的1乘以10和这个2相加得到数值12
4. 再拆出字符“3”，解析出数值3，把刚才的12再乘以10加上这个3得到数值123
5. ...

有些C程序员知道用函数atoi()可以实现字串到整数的转换，仅仅一句代码，看似非常简单，但其实背后的步骤非常多，CPU要干很多事才能完成这个动作，耗时并不短。实际过程中还要判断可能出现的非法字符（比如不是数字的字符），比上面描述的步骤还要更复杂得多。

整数还是最简单的数据类型，如果是实数还要处理小数点，字符串解析时要考虑转义字符和引号匹配，日期的解析更是要麻烦得多，因为格式种类太多，2018/1/10和10-1-2018都是常见的合法日期格式，甚至还有Jan-10 2018这种，要正确解析，就得尝试用多种格式去匹配，CPU耗时很严重。

一般来讲，外存数据访问的主要时间是在硬盘本身的读取上，而文本文本的性能瓶颈却经常发生在CPU环节。因为解析的复杂性，CPU耗时很可能超过硬盘耗时（特别是采用高性能固态硬盘时）。文本是非常慢的，需要高性能处理大数据时不要使用文本！

但是，有些原始数据（如日志）只有文本形式，解析文本就是不可避免的任务。这时候，一方面可以采用并行技术，利用多CPU并行度更高的特性，由多个线程同时解析文本，这样即使仍然串行访问硬盘也能获得更高的文本处理性能；另一方面，这些数据如果需要反复使用，那么最好是转换成二进制格式存储，第二次使用不要再次解析。

二进制文件中，我们会将各种数据类型对应的内存字节直接写出到文件中，再读取时也只要直接取出重新装载成内存数据，没有复杂的解析过程，也不需要判断和识别非法情况，这时性能就会好很多。

不过，用二进制数据存储时需要考虑好压缩手段，否则在某些极端情况下会比文本的存储空间更大，虽然解析时间缩短，但硬盘访问时间会变长。

比如整数1，用文本存储时只要占一个字节，即使加上分隔符也就两个字节。而如果要把所有整数都按32位整数处理（当前计算机的整数数据类型大多数是这个位长），就需要用4个字节来存储，比文本大了一倍，有时可能还要加上数据类型本身的信息，就会更长。

对于这种情况，合理的做法是根据数的大小决定位长，比如小整数只存储一个字节或两个字节，大整数才存储更多的字节，因为小整数较常见，结果会使得总体存储空间降低，从而获得性能优势。

但是，压缩率并不是越高越好，解压缩需要消耗CPU时间。象上面说的，把整数分大小存储能够减少空间，但在解析时就要多一重判断，又降低一点性能。最后采用的压缩方案，要在硬盘空间的减少和CPU的消耗中取得某种平衡。如果一味地追求压缩率（比如使用zip压缩算法），空间是降低得更多，但CPU时间将会超过硬盘时间，整体性能反而下降。

不过，无论如何，二进制文件仍然是最快的存储格式。采用简单压缩方案的二进制文件，即使同样采用行式存储，一般也能达到比文本高4-5倍的性能。使用二进制格式，还有可能使用前面文章中提到过的分段并行技术和列存技术，从而获得更高的性能。