Py学习  »  NoSql

数据蒋堂 | DB与NoSQL的访问性能

数据派THU • 6 年前 • 671 次点击  

作者:蒋步星

来源:数据蒋堂

本文约1500字,建议阅读5分钟
通过本文为大家带来怎么在高性能和数据多样性之间抉择数据处理。



我们继续从软件角度上看外存数据源的性能,考察数据库的性能特点,在这篇文章中,我们只关心数据的访问性能,而不涉及计算性能。


关系数据库


关系数据库也是很常见的数据存储方式。本质上讲,数据库其实也是一种特殊的二进制文件,但它的性能会弱于直接写在操作系统下的文件,主要原因在于数据库通常都要具备提供数据更新的能力,这就会产生影响性能的因素:


1. 紧凑性与压缩手段


数据库要考虑数据的更新,一般会采用段页式的分块存储,在存储数据时不会把分块完全填满,而会留一小部分空白区用于后续的修改动作。这样,占用的硬盘空间就会比不考虑更新动作的文件更大一点。


因为要更新数据,所以很难实现数据压缩。比如上一篇所说的把小整数存成较短字节的方案,如果采用了这种方案,一旦这个小整数被改成了大整数,原来的空间就存不下了,就要把后续数据都向后移动,这会使数据更新成本过高,所以一般数据库都不采用压缩手段,而直接根据数据类型分配空间,也会造成空间的浪费,极端情况会出现占用空间大于文本的现象。


2. 事实一致性带来的复杂性


许多商业数据库还会同时支持OLTP业务,在读取数据时要提供一致性的能力,这会使访问数据的动作复杂度变大很多。同一条数据,由于其它事务的写操作,可能出现多个备份,在读取时数据库要根据事务的启动时刻找到正确的那一个,这是个非常麻烦的动作,对性能影响很大。



另外,前面文章还提到过,按块存储的结构对于分段也不够自由,不象文件那样可以实施更灵活的并行手段,也会导致数据库的性能表现弱于直接 文件。


数据库普遍还有一个IO性能不佳的问题,数据在数据库中运算时性能尚可,但要通过数据库接口取出来就非常慢,实测的情况表明,这个性能经常可能会比用文本存储还慢。对于这个问题,在数据库本身负担不重时,可以采用并行取数的方法来解决,具体细节及代码我们将在以后再详述。


NoSQL数据库


NoSQL常常被用作大数据处理,但是,它真的能获得高性能吗?


这要分情况,看进行什么样的处理。


NoSQL产品一般都不提供事务一致性的能力,这使在数据访问时的动作要比关系数据库简单了许多,不需要考虑回滚段、多备份等问题。而且,放弃事务的NoSQL一般也更容易横向扩展,使用更多机器来承载更大的业务量。在这方面,NoSQL确实会有更高的性能,特别是高并发写入时的优势要比关系数据库大得多。


不过,对于单纯的分析型业务,却不完全是这样。


许多分析型关系数据库也不考虑事务一致性的问题,访问动作同样也较为简单。NoSQL不处理事务一致性带来的性能优势,与这些分析型数据库比并没有特别的地方。



NoSQL产品常常使用Key-Value型存储组织,Value的随意性会带来结构多样性的好处,即使用NoSQL存储数据时不需要事先确定数据结构,也不象关系数据库那样必须先建个有特定数据结构的表才能使用,这是NoSQL非常方便的地方。


但是,多样性和高性能是一对天生的矛盾


多样性意味着每条记录的数据结构都可能不一样。在存储数据时同时也要存储结构,增大了存储量,在解析数据时也要去匹配数据结构中的字段,增加大了复杂度。而关系数据库中同一表的数据结构是确定且相同的,结构只要存储一份,解析数据时的字段对应也非常简单,当数据量很大时,这个优势就会非常明显。


大多数Key-Value式的NoSQL产品,只是在用Key寻找Values时性能很好(这只要有个Hash索引就能够用Key找到对应的记录,关系数据库建了索引也可以),但面临需要对数据遍历才能完成的计算时(比如过滤条件不是针对Key的),它的性能就会远远低于确定数据结构的关系数据库。把NoSQL用于高性能大数据分析业务是个错误的选择,但现实中却经常有人在这么用。


专栏作者简介

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


清华大学计算机硕士,著有《非线性报表模型原理》等,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元红包

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

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


今天看啥 - 高品质阅读平台
本文地址:http://www.jintiankansha.me/t/AFNfAnHnWk
Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/7166
 
671 次点击