数据蒋堂 | 内置的数据无法实现高性能

作者：蒋步星

来源：数据蒋堂

本文共1400字，建议阅读7分钟。获得了数据库的方便性就得不到高性能，要数据外置的高性能就要牺牲方便性。

这里说的“内”， 是指数据库之内。 当数据量变大时，我们常常会感到数据库的性能下降明显，但是，无论怎样优化SQL（存储过程）都仍然与根据数据量和运算复杂度计算出来的理论性能相差甚远。这主要由如下几方面原因造成：

SQL限制与优化困难

我们已经多次说过，由于关系代数和SQL语法的限制，有许多高效的算法无法实施，比如前面说过的遍历复用技术，以及去年谈过的JOIN优化方法。使用SQL实现这类运算时，只能采用复杂度更高的方法，冗余的数据访问量和计算量非常大，而且也很难利用多CPU进行并行计算。 SQL不提倡分步计算，经常一条语句写出几百行、嵌套很多层。不分步的长语句很难利用某个子句的计算结果，常常带来不必要的重复计算。而且过于复杂的也会给数据库优化引擎造成负担，优化引擎不能很好地理解运算逻辑而设计出最优的执行路径。我们常常发现一条语句的几个子部分执行都很快，结果集也不大，但合起来写到一句SQL中就会很慢。

存储过程性能差

对于复杂的多步骤计算，我们常常要编写存储过程才能实现。而和SQL相比，存储过程的取数遍历过程要慢得多。同一个表的数据，使用存储过程先FETCH出来再做聚合，要比直接用SQL聚合的性能慢出几倍到十几倍，本来这两者的运算性能应当是差不多的（计算复杂度与数据访问量都一样）。有些针对明细数据的复杂处理只能把数据一条条取出才能实现时，这个性能就没办法得到保证了。 在存储过程中，为了利用前面计算出来的中间结果，只要涉及集合性数据一般都要使用临时表。而建表写数的动作也是非常慢的，数据库有太多约束性要求，而且常常需要把临时表落地到外存。

直接外部计算不现实

如果我们不采用SQL，而将数据读出后在库外计算，是否可以提高性能呢？ 大多数情况仍然不可以。一方面原因是数据库IO性能大都很差，从数据库中取数，要比从文件系统中读数的性能差出一个数据量，经常发生取数时间远远超过计算时间的现象。 而且，有些高效算法会要求有特殊的存储格式，比如需要事先将数据排序存储，从而可以采用分段定位查找或实现有序归并算法，而基于无序集合的SQL在理论上就无法支持，必须先排序才能保证取出数据的有序性，结果排序时间会超过计算本身。再比如行存或列存的选择，一般数据库只会采用一种（支持OLTP用行存且不压缩，面向OLAP用列存并压缩），但使用行存还是列存需要由计算目标决定，在遍历式计算采用列存较为合适，而使用索引定位查找时则更适合用行存。有时为了性能还可能把同一份数据存储冗余的多份以面向不同用途，而在数据库中很难有这么灵活的处理方式。

---

解决办法，就是数据外置，具体说就是把数据搬出数据库。使用合理的存储方案再配以适用的算法，对于许多几百上千行的存储过程，经过这样的改造后，性能常常都有几倍的增长。 当然，这又会带来新的问题。主要有三个方面： 一是可管理性，在数据库中有统一的数据视图和约束性检查，而外部文件系统则没有这些东西；二是安全性，数据库是个封闭体系，获取数据的接口很单一，总有帐号认证的过程，而文件系统也没有这些东西；三是数据更新能力，数据在不断地变化中，数据库有完整的数据更新功能，文件系统这方面却很弱，一般只能做追加，还很难保证追加过程中的一致性（中途出错时恢复）。 目前阶段这个事还是需要权衡，获得了数据库的方便性就得不到高性能，要数据外置的高性能就要牺牲方便性。不过，随着技术的进步，在文件系统上加强可管理性、安全性以及可更新能力又不牺牲或很少牺牲其性能，还是有可能做到的，数据库的封闭性总要被打破。

专栏作者简介

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

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

数据蒋堂

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

数据蒋堂第二年往期回顾：

数据蒋堂 | 莫非我就是被时代呼唤的数学人

数据蒋堂 | SQL是描述性语言？

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

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

数据蒋堂 | 中国报表漫谈

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

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

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

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

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

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

数据蒋堂 | 前半有序的大数据排序

数据蒋堂 | “后半”有序的分组

数据蒋堂 | 时序数据从分表到分库

数据蒋堂 | BI系统的前置计算

数据蒋堂 | 性能优化是个手艺活

数据蒋堂 | 数据分布背后的逻辑

数据蒋堂 | 从一道招聘考题谈起

数据蒋堂 | 为什么我们需要C程序员

数据蒋堂 | 报表工具的SQL植入风险