往期回顾

8. 应对OLAP的种种思路

老柯：能优化OLAP的方法有很多，我先举最关键最本质的来说，首先就是数据库的存储结构，这是决定OLTP和OLAP性能的重中之重。

其中OLTP基于行存的存储效果最佳，什么是行存，也就是数据是一行一行的往数据库块里插，插满了一个数据块，就插下一个数据块。而OLAP则是基于列存的效果最优，什么是列存，那就是一列一列的往数据库块里插，比如一张表有10个列，那就同时往10个块里插数据，也是插满一个数据库块，就插下一个数据块。

两者的差别就是行存在数据库块中找到的是表的所有列信息，而列存就是在一个数据块中全是表的某一列的数据。这也是OLTP和OLAP在存储上的主要差异。老王，您知道列存为啥要这么设计吗？

老王（想了许久）：没明白。

老柯：其实最关键还是OLTP是怎么查的，OLTP基本上是基于点查，而OLAP是基于报表类等展示。比如前者针对工资表查的往往是：城市，公司，部门，姓名，工资，奖金，满勤奖，社保金额，医保金额，公积金金额，总收入，月份…基本上每行记录都要，往往返回一条属于自己的记录。而后者针对工资表维度就完全不一样了，或许只想统计一下各个城市的工资收入情况，于是就取城市和总收入两个字段进行分组汇聚统计。到这里，您是否意识到为什么OLAP系统的表往往是列存设计了。

老王（恍然大悟)：明白了！因为OLAP一般会遍历大部分的记录，但是往往只会访问少数的列，这样如果列存的话，很多列不需要访问了，那扫描数据块的数量就会大幅减少，从而提升性能。而在OLTP数据库中的行存结构就完全用不了这个技巧了。”

老柯：老王果然是睿智英明，您说的完全正确！您提到减少数据块访问量这点说的特别精彩，不过减少数据块访问量在这里还有进一步的手段，您能想到吗？

老王沉思了一会儿，摇了摇头。

老柯：咱们可以考虑压缩手段啊，列存模式下，数据块里都只存某一列的数据，那这一列的数据类型是一模一样的，压缩比就会非常的高，你去想象一下行存，数据块里完整的是行数据，就是每一列都保存进去了，那数据类型差别很大，压缩的效果就很一般。

在这里插入图片描述

老王：妙！那压缩比一般会有多少呢？

老柯：不好说，和这一列的类型是否容易压缩以及选择什么压缩算法是有关的。但是往往会在20倍以上。

老王（很吃惊）：这么高！是不是意味着访问的数据块只有原来的二十分之一？

老柯：是啊，所以性能往往会有大幅提升，列存对于提升OLAP性能来说，简直就是一个优化神器！而且这个压缩比这么高还会带来另外一个好处，那就是可以节省存储空间，降低成本。不过关于压缩这块也要讲究一点平衡，因为这里CPU是需要解压进行运算的，所以需要和CPU的能力及当前CPU资源的情况结合在一起综合考虑。

老王：厉害啊老柯，除了列存+压缩外，还有其他优化OLAP查询的方面吗？

老柯：有的，OLAP的一个特点是用的人往往不多，但是任务特别大，这样我们可以充分利用CPU的并行处理能力，让某个大任务在运行时尽可能用更多的CPU，人多力量大，也就变更快了。类似的还有尽可能对特别复杂的SQL分配足够多的内存，让运算尽可能多在内存内完成，尽量减少物理读增加逻辑读来提升性能。

老王：这个有道理，暴力美学，给大任务的SQL足够多的资源。还有其他方法吗？

老柯：有啊，比如空间换时间。很多时候我们查询的实效性没那么高，比如每天中午统计昨天的数据，如果这样的任务特别大跑的很慢，可以从凌晨开始执行这个任务，那中午统计的时候只要直接拿着任务结果来展示即可。除了人工的跑脚本外，其实数据库还有自带类似的能力，如物化视图，能每隔一段时间自动完成数据汇聚，实现空间换时间。

9. OLAP城堡的诞生

老王：老柯，真有你的，居然有这么OLAP优化思路。不过你咋不这么干呢？

老柯：老王，刚才的方法我说了很多，其实可以分成三类：1. 减少数据访问量，比如列存储技术和压缩技术；2. 增大吞吐量，比如增加CPU并行及分配尽可能多的内存；3. 空间换时间，比如提前计算和物化视图。可是这三类方法并不适合当下的OLTP城堡啊。

首先是减少数据访问量的核心是列存，行存和列存是两种完全不同的存储结构，如何共存这两种存储结构目前我还没有好的思路；再有就是增大吞吐量，我们当前铺天盖地的身份认证请求已经让我们应对困难了，还要分配这么多的资源给OLAP大任务查询，不是要火上浇油了；还有关于空间换时间，就是让属后台批量的跑任务，以供统计所需，不过这显然也会产生系统资源竞争。

在这里插入图片描述