OLTP  和 OLAP

2024-05-04 22:08
文章标签 olap oltp

本文主要是介绍OLTP  和 OLAP,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

OLTP与OLAP的介绍

    数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。 

OLTP  系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作;
OLAP  系统则强调数据分析,强调SQL执行市场,强调磁盘I/O,强调分区等。 

OLTP与OLAP之间的比较:   


     OLTP,也叫联机事务处理(Online Transaction Processing) ,表示事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中,单个数据库每秒处理的Transaction往往超过几百个,或者是几千个,Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等,如美国eBay的业务数据库,就是很典型的OLTP数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
(1)CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上,逻辑读总量等于单个语句的逻辑读乘以执行次数,如果单个语句执行速度虽然很快,但是执行次数非常多,那么,也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读,或者是减少它们的执行次数。另外,一些计算型的函数,如自定义函数、decode等的频繁使用,也会消耗大量的CPU时间,造成系统的负载升高,正确的设计方法或者是优化方法,需要尽量避免计算过程,如保存计算结果到统计表就是一个好的方法。
(2)磁盘子系统在OLTP环境中,它的承载能力一般取决于它的IOPS处理能力. 因为在OLTP环境中,磁盘物理读一般都是db file sequential read,也就是单块读,但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候,就会出现大的性能问题。
    OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术,Cache决定了很多语句不需要从磁盘子系统获得数据,所以,Web cache与Oracle data buffer对OLTP系统是很重要的。另外,在索引使用方面,语句越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少表关联,尽量减少分布式事务,基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高,批量更新时要分批快速提交,以避免阻塞的发生。 
OLTP 系统是一个数据块变化非常频繁,SQL 语句提交非常频繁的系统。 对于数据块来说,应尽可能让数据块保存在内存当中,对于SQL来说,尽可能使用变量绑定技术来达到SQL重用,减少物理I/O 和重复的SQL 解析,从而极大的改善数据库的性能。
    这里影响性能除了绑定变量,还有可能是热快(hot block)。 当一个块被多个用户同时读取时,Oracle 为了维护数据的一致性,需要使用Latch来串行化用户的操作。当一个用户获得了latch后,其他用户就只能等待,获取这个数据块的用户越多,等待就越明显。 这就是热快的问题。 这种热快可能是数据块,也可能是回滚端块。 对于数据块来讲,通常是数据库的数据分布不均匀导致,如果是索引的数据块,可以考虑创建反向索引来达到重新分布数据的目的,对于回滚段数据块,可以适当多增加几个回滚段来避免这种争用。 
     OLAP,也叫联机分析处理(Online Analytical Processing) 系统,有的时候也叫DSS决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。
    磁盘子系统的吞吐量则往往取决于磁盘的个数,这个时候,Cache基本是没有效果的,数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽,如4Gb的光纤接口。
在OLAP系统中,常使用分区技术、并行技术。
    分区技术在OLAP系统中的重要性主要体现在数据库管理上,比如数据库加载,可以通过分区交换的方式实现,备份可以通过备份分区表空间实现,删除数据可以通过分区进行删除,至于分区在性能上的影响,它可以使得一些大表的扫描变得很快(只扫描单个分区)。另外,如果分区结合并行的话,也可以使得整个表的扫描会变得很快。总之,分区主要的功能是管理上的方便性,它并不能绝对保证查询性能的提高,有时候分区会带来性能上的提高,有时候会降低。
    并行技术除了与分区技术结合外,在Oracle 10g中,与RAC结合实现多节点的同时扫描,效果也非常不错,可把一个任务,如select的全表扫描,平均地分派到多个RAC的节点上去。
    在OLAP系统中,不需要使用绑定(BIND)变量,因为整个系统的执行量很小,分析时间对于执行时间来说,可以忽略,而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引,物化视图,对于大的事务,尽量寻求速度上的优化,没有必要像OLTP要求快速提交,甚至要刻意减慢执行的速度。
    绑定变量真正的用途是在OLTP系统中,这个系统通常有这样的特点,用户并发数很大,用户的请求十分密集,并且这些请求的SQL 大多数是可以重复使用的。
    对于OLAP系统来说,绝大多数时候数据库上运行着的是报表作业,执行基本上是聚合类的SQL 操作,比如group by,这时候,把优化器模式设置为all_rows是恰当的。 而对于一些分页操作比较多的网站类数据库,设置为first_rows会更好一些。 但有时候对于OLAP 系统,我们又有分页的情况下,我们可以考虑在每条SQL 中用hint。 如:
    Select  a.* from table a;
分开设计与优化
    在设计上要特别注意,如在高可用的OLTP环境中,不要盲目地把OLAP的技术拿过来用。
    如分区技术,假设不是大范围地使用分区关键字,而采用其它的字段作为where条件,那么,如果是本地索引,将不得不扫描多个索引,而性能变得更为低下。如果是全局索引,又失去分区的意义。
    并行技术也是如此,一般在完成大型任务时才使用,如在实际生活中,翻译一本书,可以先安排多个人,每个人翻译不同的章节,这样可以提高翻译速度。如果只是翻译一页书,也去分配不同的人翻译不同的行,再组合起来,就没必要了,因为在分配工作的时间里,一个人或许早就翻译完了。
    位图索引也是一样,如果用在OLTP环境中,很容易造成阻塞与死锁。但是,在OLAP环境中,可能会因为其特有的特性,提高OLAP的查询速度。MV也是基本一样,包括触发器等,在DML频繁的OLTP系统上,很容易成为瓶颈,甚至是Library Cache等待,而在OLAP环境上,则可能会因为使用恰当而提高查询速度。
    对于OLAP系统,在内存上可优化的余地很小,增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法,当然这也意味着系统成本的增加。      
    比如我们要对几亿条或者几十亿条数据进行聚合处理,这种海量的数据,全部放在内存中操作是很难的,同时也没有必要,因为这些数据快很少重用,缓存起来也没有实际意义,而且还会造成物理I/O相当大。 所以这种系统的瓶颈往往是磁盘I/O上面的。
    对于OLAP系统,SQL 的优化非常重要,因为它的数据量很大,做全表扫描和索引对性能上来说差异是非常大的。
其他
     Oracle 10g以前的版本建库过程中可供选择的模板有
        Data Warehouse (数据仓库)
        General Purpose  (通用目的、一般用途)
        New Database
        Transaction Processing  (事务处理)
     Oracle 11g的版本建库过程中可供选择的模板有
        一般用途或事务处理
        定制数据库

        数据仓库

个人对这些模板的理解为:

     联机分析处理(OLAP,On-line Analytical Processing),数据量大,DML少。使用数据仓库模板
     联机事务处理(OLTP,On-line Transaction Processing),数据量少,DML频繁,并行事务处理多,但是一般都很短。使用一般用途或事务处理模板。

     决策支持系统(DDS,Decision support system),典型的操作是全表扫描,长查询,长事务,但是一般事务的个数很少,往往是一个事务独占系统。



转自:http://blog.csdn.net/rfb0204421/article/details/6873284

            http://76287.blog.51cto.com/66287/885475

这篇关于OLTP  和 OLAP的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/960198

相关文章

DB、DW、DM、ODS、OLAP、OLTP和BI的概念理解

今天特地查了一些官方解释和很多优秀的博客文章,将关于数仓方面的一些名词理解记了下来,先将这些简称做一个解释: 1、DB(DataBase):数据库,一般指的就是OLTP数据库,在线事物数据库,用来支持生产的。DB保留的是数据信息的最新状态,只有一个状态! 2、DW(Data Warehouse):数据仓库,保存的是数据在不同时间点的状态,对同一个数据信息,保留不同时间点的状态,便于我们做统计

Apache Kylin 在美团数十亿数据 OLAP 场景下的实践

大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 暴走大数据 点击右侧关注,暴走大数据! By  大数据技术与架构 场景描述:美团各业务线存在大量的OLAP分析场景,需要基于Hadoop数十亿级别的数据进行分析,直接响应分析师和城市BD等数千人

数据仓库系统的实现与使用(含OLAP重点讲解)

系列文章: 《一文了解数据库和数据仓库》 《DB数据同步到数据仓库的架构与实践》 《数据湖(Data Lake)-剑指下一代数据仓库》 《从0建设离线数据仓库》 《基于Flink构建实时数据仓库》 阅读目录 前言创建数据仓库ETL:抽取、转换、加载OLAP/BI工具数据立方体(Data Cube)OLAP的架构模式小结 前言 数据仓库是数据仓库开发中最核心的部分。然而完整的数据仓库系统还会涉及

Apache Flink新场景 | OLAP引擎

大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 暴走大数据 点击右侧关注,暴走大数据! 本文作者来自阿里巴巴的贺小令,探讨了Flink在OLAP中的应用,之前我个人写过两篇关于OLAP的文章: 《你需要的不是实时数仓 | 你需要的是一款强大的OLAP数据库(上)》 《你需要的不是实时数仓 | 你需要的是一款强大的OLAP数据库(下)》 希望此文对大家有所启发。

大数据面试通关手册 | Kylin入门/原理/调优/OLAP解决方案和行业典型应用

Kylin入门/原理/调优/OLAP解决方案和行业典型应用一网打尽。 一:背景历史和使命 背景和历史 现今,大数据行业发展得如火如荼,新技术层出不穷,整个生态欣欣向荣。作为大数据领域最重要的技术的 Apache Hadoop 最初致力于简单的分布式存储,然后在此基础之上实现大规模并行计算,到如今在实时分析、多维分析、交互式分析、机器学习甚至人工智能等方面有了长足的发展。 2013 年年初,在

什么是联机分析处理(OLAP)

什么是联机分析处理(OLAP) OLAP的提出引起了很大的反响,OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。 当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、

【数据仓库/数据治理】探索数据处理的两大类:OLTP与OLAP及其核心技术

在现代数据处理的世界中,数据的管理和分析是商业和技术决策的关键。为满足不同的业务需求,数据处理大致分为两大类:联机事务处理(OLTP) 和 联机分析处理(OLAP)。这两者分别适用于日常事务处理和复杂的分析操作,在数据管理中扮演着不同但互补的角色。 联机事务处理(OLTP):日常事务的基石 OLTP系统主要用于处理基本的、日常的事务操作,典型的例子包括银行交易、订单处理和库存管理等。这类系

我们需要怎样的 OLAP

OLAP 这个词从字面上理解是在线分析的意思,也就是由人员面对数据进行各种交互式的分析操作。 但是,现在的OLAP 概念被 BI 软件给严重狭义化了。面向业务分析时说到 OLAP,在技术上经常就只有多维分析的功能,也就是针对一个事先建设好的数据立方体,按指定维度层次进行汇总并呈现成表格或图形,再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。这些大家都很熟悉,就不再细说了。 多维分析就是

DataBase学习笔记 --- OLAP 与 OLTP区别

OLTP = > on-line transaction processing 链接事务处理 OLAP = > on-line Analytical processing 联机分析处理 OLTP是传统的关系型数据库主要应用,主要是基本的,日常的事务处理,例如银行交易。 OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。 OLTP 系

性能工具之 MySQL OLTP Sysbench BenchMark 测试示例

文章目录 一、前言二、测试环境1、服务器配置2、测试拓扑 三、测试工具安装四、测试步骤1、导入数据2、压测数据3、清理数据 五、结果解析六、最后 一、前言 做为一名性能工程师掌握对 MySQL 的性能测试是非常必要的,本文基于 Sysbench 对MySQL OLTP(联机事务处理) 的 BenchMark 测试案例详细介绍具体方法。 二、测试环境 1、服务器配置 数据库服