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

640?wx_fmt=png

作者:蒋步星

来源:数据蒋堂

本文共1200字,建议阅读6分钟
本文与你探讨数据库的封闭性对数据处理效率的影响。

640?wx_fmt=png


我们知道,数据库的数据处理能力是封闭的。所谓封闭性,这里是指要被数据库计算和处理的数据,必须事先装入数据库之内,数据在数据库内部还是外部是很明确的。


数据库一般有OLTP和OLAP两个用途。对于OLTP业务来讲,因为要保证数据的一致性,而一致性只有在一个确定的范围内谈论才有意义,这样就自然就会带来封闭性:数据库系统将保证也只负责数据库内部的数据的一致性


如果不关注OLTP业务,只关心OLAP业务时,数据库在逻辑上可以被理解成为数据仓库,而这样的数据仓库也顺便继承了这个封闭性。




数据库的名字中有个“库”字,即使不考虑OLTP业务,也会让人觉得它是个以存储为主要目的的产品。其实不然,在实际应用中,特别是在大数据场景下,数据库有相当多的作用是计算,对于OLAP业务几乎可以说是全部,其存储经常也是为了计算服务的。因为数据库的计算能力还不错,远远超过大多数其它软件产品,所以人们经常会为了计算目标而部署数据库。


但是,一个以计算为主要任务的产品,没必要绑定封闭性这样的特点。




计算能力的封闭性有什么坏处呢?


一个典型的现象就是ETL经常被做成ELT甚至LET。ETL中的E和T这两步事实上也是某种计算,如果计算能力被封闭到数据库之内的话,我们就只能先把数据装入库中才能计算了,因为无法计算库外的数据。然而ETL过程中的原始数据常常并不在库内,或者至少不在这个用于计算的数据库中,也可能存在于多个数据库。总之,都需要先做个同库动作之后才能再计算。


有点多此一举!


数据库的封闭性,相当于城市有个城墙,数据要进出也必须通过数据库的城门,过程中还要进行一些检查。对于OLTP业务,为了保证一致性,这些检查是有必要的,但也会损失数据库的IO效率,而这对于ETL这类业务几乎没有意义,只是浪费时间而已。


当代应用中多样性的数据源越来越普遍,经常有来自外部服务的数据。如果为了计算这些数据而先把它们转入数据库中,也是非常累赘的。临时转入的效率很低(因为数据库的IO成本高),很可能跟不上访问需求,而定时批量转入又很难获得最新的数据,同样影响计算结果的实时性。




那么,我们把计算能力从数据库中剥离出来,作为独立的计算引擎提供,让数据(仓)库只负责存储,是不是就可以了?


不依赖于数据库的计算能力确实很必要,这样是可以解决上述的ELT/LET和多数据源问题,但这还不够。


数据库风格的计算常常是数据密集型的,其性能和存储机制密切相关。把计算能力剥离,只能是让计算可以进行,但并不能保证足够快。在关注计算性能的场景下,特定的存储方案仍然是必要的。


还是要回到计算封闭的老路?


不必。


要获得高性能,是要关注数据存储,但只要设定专门的存储格式即可,并不需要做个“库”把数据装起来。一个开放的计算引擎,可以计算任何来源的数据。如果数据能够以约定的方式存储,那么可以获得更高性能的计算效率,仅此而已。计算时并不需要关心数据是不是属于某个“库”,“数据仓库”(如果还用这个名词的话)可以发展成没有库、只有数据的组织形式。


现代城市不必再有城墙!


专栏作者简介

640?

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


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


数据蒋堂

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


往期回顾:


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

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

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

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

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

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

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

数据蒋堂 | JOIN运算剖析

数据蒋堂 | 迭代聚合语法

数据蒋堂 | 非常规聚合

数据蒋堂 | 再谈有序分组

数据蒋堂 | 有序分组

数据蒋堂 | 非等值分组

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

数据蒋堂 | 有序遍历语法

数据蒋堂 | 常规遍历语法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

数据蒋堂 | 报表开发的现状

数据蒋堂 | Hadoop - 一把杀鸡用的牛刀

数据蒋堂 | Hadoop中理论与工程的错位

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

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

数据蒋堂 | 中国报表漫谈

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

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

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

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

640?wx_fmt=jpeg

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值