数据蒋堂 | 文件的性能分析

作者:蒋步星

来源:数据蒋堂

本文共1515字,建议阅读5分钟
本文带大家学习根据文件性能的不同选择更好的存储方式。



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


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


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


文本文件


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


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


举个例子,设想一下把文本“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倍的性能。使用二进制格式,还有可能使用前面文章中提到过的分段并行技术和列存技术,从而获得更高的性能。


专栏作者简介

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


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


数据蒋堂

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


往期回顾:

数据蒋堂 | JOIN延伸 - 维度概念

数据蒋堂 | JOIN提速 - 有序归并

数据蒋堂 | JOIN提速 - 外键指针的衍生

数据蒋堂 | JOIN提速 - 外键指针化

数据蒋堂 | JOIN简化 - 意义总结

数据蒋堂 | JOIN简化-消除关联

数据蒋堂 | JOIN简化 - 维度对齐

数据蒋堂 | JOIN运算剖析

数据蒋堂 | 迭代聚合语法

数据蒋堂 | 非常规聚合

数据蒋堂 | 再谈有序分组

数据蒋堂 | 有序分组

数据蒋堂 | 非等值分组

数据蒋堂 | 还原分组运算的本意

数据蒋堂 | 有序遍历语法

数据蒋堂 | 常规遍历语法

数据蒋堂 | 从SQL语法看离散性

数据蒋堂 | 从SQL语法看集合化

数据蒋堂 | SQL用作大数据计算语法好吗?

数据蒋堂 | SQL的困难源于关系代数

数据蒋堂 | SQL像英语是个善意的错误

数据蒋堂 | 开放的计算能力为数据库瘦身

数据蒋堂 | 计算封闭性导致臃肿的数据库

数据蒋堂 | 怎样看待存储过程的移植困难

数据蒋堂 | 存储过程的利之弊

数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 报表的数据计算层

数据蒋堂 | 报表应用的三层结构

数据蒋堂 | 列式存储的另一面

数据蒋堂 | 硬盘的性能特征

数据蒋堂 | 我们需要怎样的OLAP?

数据蒋堂 | 1T数据到底有多大?

数据蒋堂 | 索引的本质是排序

数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

数据蒋堂 | 非结构化数据分析是忽悠?

数据蒋堂 | 多维分析的后台性能优化手段

数据蒋堂 | JOIN延伸 - 维度查询语法


校对:林亦霖


为保证发文质量、树立口碑,数据派现设立“错别字基金”,鼓励读者积极纠错

若您在阅读文章过程中发现任何错误,请在文末留言,或到后台反馈,经小编确认后,数据派将向检举读者发8.8元红包

同一位读者指出同一篇文章多处错误,奖金不变。不同读者指出同一处错误,奖励第一位读者。

感谢一直以来您的关注和支持,希望您能够监督数据派产出更加高质的内容。


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值