数据库的封闭性
我们知道,数据库的数据处理能力是封闭的。所谓封闭性,这里是指要被数据库计算和处理的数据,必须事先装入数据库之内,数据在数据库内部还是外部是很明确的。
数据库一般有OLTP和OLAP两个用途。对于OLTP业务来讲,因为要保证数据的一致性,而一致性只有在一个确定的范围内谈论才有意义,这样就自然就会带来封闭性:数据库系统将保证也只负责数据库内部的数据的一致性。
如果不关注OLTP业务,只关心OLAP业务时,数据库在逻辑上可以被理解成为数据仓库,而这样的数据仓库也顺便继承了这个封闭性。
数据库的名字中有个“库”字,即使不考虑OLTP业务,也会让人觉得它是个以存储为主要目的的产品。其实不然,在实际应用中,特别是在大数据场景下,数据库有相当多的作用是计算,对于OLAP业务几乎可以说是全部,其存储经常也是为了计算服务的。因为数据库的计算能力还不错,远远超过大多数其它软件产品,所以人们经常会为了计算目标而部署数据库。
但是,一个以计算为主要任务的产品,没必要绑定封闭性这样的特点。
计算能力的封闭性有什么坏处呢?
一个典型的现象就是ETL经常被做成ELT甚至LET。ETL中的E和T这两步事实上也是某种计算,如果计算能力被封闭到数据库之内的话,我们就只能先把数据装入库中才能计算了,因为无法计算库外的数据。然而ETL过程中的原始数据常常并不在库内,或者至少不在这个用于计算的数据库中,也可能存在于多个数据库。总之,都需要先做个同库动作之后才能再计算。
有点多此一举!
数据库的封闭性,相当于城市有个城墙,数据要进出也必须通过数据库的城门,过程中还要进行一些检查。对于OLTP业务,为了保证一致性,这些检查是有必要的,但也会损失数据库的IO效率,而这对于ETL这类业务几乎没有意义,只是浪费时间而已。
当代应用中多样性的数据源越来越普遍,经常有来自外部服务的数据。如果为了计算这些数据而先把它们转入数据库中,也是非常累赘的。临时转入的效率很低(因为数据库的IO成本高),很可能跟不上访问需求,而定时批量转入又很难获得最新的数据,同样影响计算结果的实时性。
那么,我们把计算能力从数据库中剥离出来,作为独立的计算引擎提供,让数据(仓)库只负责存储,是不是就可以了?
不依赖于数据库的计算能力确实很必要,这样是可以解决上述的ELT/LET和多数据源问题,但这还不够。
数据库风格的计算常常是数据密集型的,其性能和存储机制密切相关。把计算能力剥离,只能是让计算可以进行,但并不能保证足够快。在关注计算性能的场景下,特定的存储方案仍然是必要的。
还是要回到计算封闭的老路?
不必。
要获得高性能,是要关注数据存储,但只要设定专门的存储格式即可,并不需要做个“库”把数据装起来。一个开放的计算引擎,可以计算任何来源的数据。如果数据能够以约定的方式存储,那么可以获得更高性能的计算效率,仅此而已。计算时并不需要关心数据是不是属于某个“库”,“数据仓库”(如果还用这个名词的话)可以发展成没有库、只有数据的组织形式。
现代城市不必再有城墙!