内置的数据无法实现高性能 | 润乾 -pg游戏官网登录入口
这里说的“内”, 是指数据库之内。
当数据量变大时,我们常常会感到数据库的性能下降明显,但是,无论怎样优化sql(存储过程)都仍然与根据数据量和运算复杂度计算出来的理论性能相差甚远。这主要由如下几方面原因造成:
1. sql限制与优化困难
我们已经多次说过,由于关系代数和sql语法的限制,有许多高效的算法无法实施,比如前面说过的遍历复用技术,以及去年谈过的join优化方法。使用sql实现这类运算时,只能采用复杂度更高的方法,冗余的数据访问量和计算量非常大,而且也很难利用多cpu进行并行计算。
sql不提倡分步计算,经常一条语句写出几百行、嵌套很多层。不分步的长语句很难利用某个子句的计算结果,常常带来不必要的重复计算。而且过于复杂的也会给数据库优化引擎造成负担,优化引擎不能很好地理解运算逻辑而设计出最优的执行路径。我们常常发现一条语句的几个子部分执行都很快,结果集也不大,但合起来写到一句sql中就会很慢。
2. 存储过程性能差
对于复杂的多步骤计算,我们常常要编写存储过程才能实现。而和sql相比,存储过程的取数遍历过程要慢得多。同一个表的数据,使用存储过程先fetch出来再做聚合,要比直接用sql聚合的性能慢出几倍到十几倍,本来这两者的运算性能应当是差不多的(计算复杂度与数据访问量都一样)。有些针对明细数据的复杂处理只能把数据一条条取出才能实现时,这个性能就没办法得到保证了。
在存储过程中,为了利用前面计算出来的中间结果,只要涉及集合性数据一般都要使用临时表。而建表写数的动作也是非常慢的,数据库有太多约束性要求,而且常常需要把临时表落地到外存。
3. 直接外部计算不现实
如果我们不采用sql,而将数据读出后在库外计算,是否可以提高性能呢?
大多数情况仍然不可以。一方面原因是数据库io性能大都很差,从数据库中取数,要比从文件系统中读数的性能差出一个数据量,经常发生取数时间远远超过计算时间的现象。
而且,有些高效算法会要求有特殊的存储格式,比如需要事先将数据排序存储,从而可以采用分段定位查找或实现有序归并算法,而基于无序集合的sql在理论上就无法支持,必须先排序才能保证取出数据的有序性,结果排序时间会超过计算本身。再比如行存或列存的选择,一般数据库只会采用一种(支持oltp用行存且不压缩,面向olap用列存并压缩),但使用行存还是列存需要由计算目标决定,在遍历式计算采用列存较为合适,而使用索引定位查找时则更适合用行存。有时为了性能还可能把同一份数据存储冗余的多份以面向不同用途,而在数据库中很难有这么灵活的处理方式。
解决办法,就是数据外置,具体说就是把数据搬出数据库。使用合理的存储方案再配以适用的算法,对于许多几百上千行的存储过程,经过这样的改造后,性能常常都有几倍的增长。
当然,这又会带来新的问题。主要有三个方面:一是可管理性,在数据库中有统一的数据视图和约束性检查,而外部文件系统则没有这些东西;二是安全性,数据库是个封闭体系,获取数据的接口很单一,总有帐号认证的过程,而文件系统也没有这些东西;三是数据更新能力,数据在不断地变化中,数据库有完整的数据更新功能,文件系统这方面却很弱,一般只能做追加,还很难保证追加过程中的一致性(中途出错时恢复)。
目前阶段这个事还是需要权衡,获得了数据库的方便性就得不到高性能,要数据外置的高性能就要牺牲方便性。不过,随着技术的进步,在文件系统上加强可管理性、安全性以及可更新能力又不牺牲或很少牺牲其性能,还是有可能做到的,数据库的封闭性总要被打破。