细说 OLAP 与 OLTP
OLAP (Online analytical processing)[联机分析处理]
-
起源
- 数据库概念最初源于1962年Kenneth Iverson发表的名为“A Programming Language” (APL)的著作,它第一次提出了处理操作和多维变量的的数学表达式,后来APL语言由IBM实现。
- 随后数据库之父Edgar F. Codd提出了著名的关系数据模型理论《A Relational Model of Data for Large Shared Data Banks 》,为后面数据库发展奠定基础。
- 第一款OLAP产品Express于1975年问世,随着被Oracle收购后繁荣发展了30余年,最后由继任者Oracle 9i替代。这么多年过去,基本的OLAP理念和数据模型仍然未变。
- OLAP这个名词是数据库之父Edgar F. Codd于1993年在文章《Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate》提出,他总结了OLAP产品的12个原则,随后OLAP产品相继问世并逐渐形成今天的格局。
-
核心概念
-
维
- 维(Dimension): 人们观察事物的视角, 如时间、地理位置、年龄和性别等, 是单一角度概念。
- 维的层次(Lever of Dimension): 表示维度概念基础上进一步的细分, 如时间可以细分为年、季度、月三个层次。
- 维成员(Member of Dimension): 表示维不可再细分的原子取值。
- 度量(Measure): 表示在这个维成员上的取值。
-
操作
-
下探(Drill down): 维度是有层次的, 下探表示进入维度的下一层, 将汇总数据拆分到下一层所在细节数据信息, 如下图从第二急速下探到看4、5、6月的明细数据。
-
上钻(Drill up): 下探的反向操作, 回到更高汇聚层的汇总数据。
-
切片(Slice): 切片可以理解成把立体按某一个维度进行切分, 切块就是按一个范围(区间)来做切分。
-
旋转(Pivot): 维的行列位置切换, 换一个视角分析数据。
-
-
-
分类
-
MOLAP (Multi-dimensional OLAP)
-
OLAP发源最初形态: 以多维数组(Multi-dimension Array) 存储模型的 OLAP, 某些方面也等同于OLAP。
-
特点:
- 数据需要预计算(pre-computation), 然后把预计算之后的结果 (cube) 存在多维数组里。
-
优点:
- cube 包含所有维度的聚合结果, 所有查询速度非常快。
- 计算结果数据占用的磁盘空间相对关系型数据库更小。
-
缺点:
-
空间和时间开销大。
- update cube 的时间跟计算程度(degree)相关, 计算时间随着维度增加↑而大幅↑, 此外预计算还会造成数据占用急剧膨胀。
-
查询灵活度比较低。
- 需要提前设计维度模型, 查询分析的内容仅限于这些指定维度, 增加维度需要重新计算。
-
-
-
ROLAP (Relational OLAP)
- 基于关系模型存放数据, 一般要求事实表(fact table) 和 维度表(dimension table) 按一定关系设计, 它不需要预计算, 适用标准SQL就可以根据需要即时查询不同维度数据。
- 优点
- 扩展性强, 适用于维度数量多的模型, MOLAP对于维度多的模型预计算慢, 空间占用大。
- 更适合处理non-aggregate事实, 如文本描述。
- 基于row存储, 数据更容易做权限管理。
- 缺点
- 因为是即时计算,查询响应时间一般比预计算的MOLAP长。
-
HOLAP (Hybrid)
- 业界还没有一致的定义,它是MOLAP和ROLAP类型的混合运用 。
- 细节的数据以ROLAP的形式存放,更加方便灵活。
- 高度聚合的数据以MOLAP的形式展现,更适合于高效的分析处理。
- 公司使用HOLAP的目的是根据不同场景来利用不同OLAP的特性。
-
-
业界产品
- MOLAP 产品有 Cognos Powerplay, Oracle Database OLAP Option, MicroStrategy, Microsoft Analysis Services, Essbase, TM1, Jedox ,icCube和kylin等
- ROLAP产品有Vertica、Amazon Redshift、Google Dremel、Hulu Nesto、Presto、Druid、Impala、Greenplum、HAWQ和Doris等。
-
国内发展状态
- 除BAT等大厂会自研OLAP产品外,其他中小互联网公司普遍拥抱开源,会使用Kylin、Presto、impala、Druid和Greenplum等开源技术来实现OLAP分析查询业务。
OLTP(on-line transaction processing)[联机事务处理]
-
描述
- 表示事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主 。
- 在这样的系统中,单个数据库每秒处理的Transaction往往超过几百个,或者是几千个,Select 语句的执行量每秒几千甚至几万个。
- 典型的OLTP系统有电子商务系统、银行、证券等,如美国eBay的业务数据库,就是很典型的OLTP数据库。
-
最容易出现瓶颈的地方
-
CPU
-
CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上,逻辑读总量等于单个语句的逻辑读乘以执行次数,如果单个语句执行速度虽然很快,但是执行次数非常多,那么,也可能会导致很大的逻辑读总量。
-
设计的方法与优化的方法就是减少单个语句的逻辑读,或者是减少它们的执行次数。
-
一些计算型的函数,如自定义函数、decode等的频繁使用,也会消耗大量的CPU时间,造成系统的负载升高
-
正确的设计方法或者是优化方法,需要尽量避免计算过程,如保存计算结果到统计表就是一个好的方法。
-
-
磁盘
- 磁盘的承载能力一般取决于它的IOPS(Input/Output Operations Per Second)处理能力. 因为在OLTP环境中,磁盘物理读一般都是db file sequential read,也就是单块读,但是这个读的次数非常频繁。
- 如果频繁到磁盘子系统都不能承载其IOPS的时候,就会出现大的性能问题。
-
常用设计与优化方式:
-
Cache
- Cache决定了很多语句不需要从磁盘子系统获得数据。
-
B-tree 索引技术
- 在索引使用方面,语句越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少表关联,尽量减少分布式事务,基本不使用分区技术、MV技术、并行技术及位图索引。
- 因为并发量很高,批量更新时要分批快速提交,以避免阻塞的发生。
-
OLTP 系统是一个数据块变化非常频繁,SQL 语句提交非常频繁的系统。
-
对于数据块来说,应尽可能让数据块保存在内存当中,对于SQL来说,尽可能使用变量绑定技术来达到SQL 重用,减少物理I/O 和重复的SQL 解析,从而极大的改善数据库的性能。
-
影响性能除了绑定变量,还有可能是热快(hot block)
-
当一个块被多个用户同时读取时,Oracle 为了维护数据的一致性,需要使用Latch来串行化用户的操作。
-
当一个用户获得了latch后,其他用户就只能等待,获取这个数据块的用户越多,等待就越明显。
-
这就是热快的问题。 这种热快可能是数据块,也可能是回滚端块。
-
对于数据块来讲,通常是数据库的数据分布不均匀导致,如果是索引的数据块,可以考虑创建反向所以来达到重新分布数据的目的,对于回滚段数据块,可以适当多增加几个回滚段来避免这种争用。
-