OLTP、OLAP、VDI和SPC-1是当前性能评估中常见的三类业务场景。SPC-1是业界通用的随机IOPS型的IO模型,在不清楚实际业务类型的条件下,常用此模型来进行性能评估。四种模型的简单IO特征如下表所示。
Oracle 数据库是典型的的OLTP业务模型,在核心 IT 业务系统中应用广泛,OLTP类型的 Oracle 数据库往往承载着企业核心的业务支撑系统,如 ERP、CRM 等,其性能和可用性出现问题,本章重点剖析OLTP和OLAP主要区别、规划方法及基于Oracle的最佳实践。
OLTP与OLAP的介绍
数据处理大致可以分成两大类:联机事务处理OLTP(On-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
OLTP与OLAP之间的比较:
OLTP应用的IO特征
OLTP通常是指事务性非常高的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中,单个数据库每秒处理的Transaction往往超过几百个,或者是几千个,Select语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等:
每个I/O非常小,通常为2KB~8KB
访问磁盘数据的位置非常随机
至少30%的数据是随机写操作
联机重做日志是写入非常频繁的顺序写
1、业务特征:每个事务的读,写,更改涉及的数据量非常小,同时有很多用户连接到数据库,使用数据库,要求数据库有很快的响应时间,通常一个事务在几秒内完成,时延要求一般在10-20ms。
2、IO特征:针对DATA LUN,随机小IO,IO大小主要为8KB(IO大小与数据库的Block块大小一致),读写比约为3:2,读全随机,写有一定合并。针对LOG LUN,多路顺序小IO,大小不定,几乎都是写IO。
OLTP系统最容易出现瓶颈的地方除了服务器的CPU,就是存储系统IOPS处理能力。因为在OLTP环境中,硬盘物理读一般都是db file sequential read,即单个数据块物理读,但是这个读的次数非常频繁。如果频繁到硬盘子系统都不能承载其IOPS的时候,就会出现大的性能问题。
OLAP应用的IO特征
OLAP系统,也称为DSS决策支持系统,就是我们说的数据仓库。在这样的系统中,绝大多数时候数据库上运行着的是报表作业,执行基本上是聚合类的SQL 操作,比如Group by,同时扫描非常多的行,一个查询将花费数小时,甚至数天,一次读取的数据量大;一般无数据修改,或者只有非常少的数据修改:
单个I/O很大,典型的值为64KB~1MB
读取操作为顺序读取
当读取操作进行时,发生的写操作通常在临时表空间内
平常对在线日志写入很少,除非在批量加载数据时
1、业务特征:一般很少有数据修改,除非在批量加载数据时;系统调用非常复杂的查询语句,同时扫描非常多的行;一个查询将花费数小时,甚至数天;主要取决于查询语句的复杂程度;查询的输出通常是一个统计值,由group by与order by得出;当读取操作进行时,发生的写操作通常在临时表空间内;平常对在线日志写入很少,除非在批量加载数据时;分析型业务,一般对时延没有要求。
2、IO特征:针对DATA LUN,多路顺序大IO(可以近似认为是随机大IO),IO大小与主机侧设置的分条大小有关(如512KB),90%以上为读业务,混合间断读写。针对TMP LUN,随机IO,读写混合(先写后读,计算时写,读临时表时读,大部分是写,占整个业务中很少部分的IO),IO大小基本为200KB以上大IO。
OLTP系统最容易出现瓶颈的地方是存储系统的带宽。阵列的带宽则往往取决于主机到阵列的前端网络和后端硬盘的个数,这个时候,阵列CACHE基本是没有效果的,数据库的读写类型基本上是db file scattered read与direct path read/write。
在实际应用中,既然OLTP中存放了大量的细节数据,为什么不直接在OLTP上进行分析处理呢?
由于OLTP主要是为了操作数据而设计(操作系统),用于处理已知的任务和负载:常见的优化在于主码索引和散列,检索特定的记录。去优化某一些特定的查询语句。
而OLAP则是为了分析数据而设计(数据仓库),其查询的方式往往是复杂且未知的,通常会涉及大量数据在汇总后的计算,这种需要基于多维视图的数据操作在OLTP上执行的时候性能将是非常差的,并且是也是极其危险的。
但是OLAP系统数据来源与各种OLTP数据库。因为OLTP系统存储的数据往往是异质的,所以OLAP系统需要把各种来源于OLTP的异质数据通过转换(ETL)做到同质并且合并。
分开设计与优化
在设计上要特别注意,如在高可用的OLTP环境中,不要盲目地把OLAP的技术拿过来用。
如分区技术,假设不是大范围地使用分区关键字,而采用其它的字段作为where条件,那么,如果是本地索引,将不得不扫描多个索引,而性能变得更为低下。如果是全局索引,又失去分区的意义。
并行技术也是如此,一般在完成大型任务时才使用,如在实际生活中,翻译一本书,可以先安排多个人,每个人翻译不同的章节,这样可以提高翻译速度。如果只是翻译一页书,也去分配不同的人翻译不同的行,再组合起来,就没必要了,因为在分配工作的时间里,一个人或许早就翻译完了。
位图索引也是一样,如果用在OLTP环境中,很容易造成阻塞与死锁。但是,在OLAP环境中,可能会因为其特有的特性,提高OLAP的查询速度。MV也是基本一样,包括触发器等,在DML频繁的OLTP系统上,很容易成为瓶颈,甚至是Library Cache等待,而在OLAP环境上,则可能会因为使用恰当而提高查询速度。
数据库模板
Oracle 10g以前的版本建库过程中可供选择的模板有:Data Warehouse (数据仓库)、General Purpose (通用目的、一般用途)、New Database和Transaction Processing (事务处理)
Oracle 11g的版本建库过程中可供选择的模板有:一般用途或事务处理、定制数据库、数据仓库等;个人对这些模板的理解为:
联机分析处理(OLAP),数据量大,DML少。使用数据仓库模板;
联机事务处理(OLTP),数据量少,DML频繁,并行事务处理多,但是一般都很短。使用一般用途或事务处理模板。
决策支持系统(DDS,Decision support system),典型的操作是全表扫描,长查询,长事务,但是一般事务的个数很少,往往是一个事务独占系统。
最佳实践
Oracle 数据库在核心 IT 业务系统中应用广泛,存储子系统的规划配置至关重要,不合理的存储规划往往导致 IT 系统性能低下,甚至可用性和数据可靠性得不到保证。OLTP类型的 Oracle 数据库往往承载着企业核心的业务支撑系统,如 ERP、CRM 等,其性能和可用性出现问题,会直接导致企业运营效率低下甚至中断。
本文OLTP 业务测试模型采用 SwingBench Order Entry 进行验证。该业务模型中定义了一种在线订单业务,模拟大量用户登陆系统,执行产品查询、下发订单、处理订单、查看订单等交易系统最常见的操作。该业务模型的主要性能指标有两个:每分钟事务数(TPM)、事务平均响应时间。TPM 代表系统在单位时间内所能够处理的交易量,TPM 高,代表着更强的生产力。事务响应时间直接影响到用户操作完成的速度,事务响应时间低,代表着更佳的用户体验。
Order Entry 业务模型中共定义了 9 张表,记录产品、客户、订单、仓库、登陆等信息。在执行负载测试时,50%为查询操作,30%为插入操作,20%为更新操作,无删除操作。从 I/O 层来看,该业务模型为小数据块随机访问,读写比例为 6:4,代表一种最为典型的 OLTP 业务模型。
在SAN(Storage Area Network)组网中,使用两个物理上独立的交换平面(每个交换平面包括一个交换机或多个相互级联的交换机),每个数据库节点与两个交换平面相连,每个存储控制器和两个交换平面相连。
Oracle RAC 组网示意图
对于 Oracle 数据库来说,I/O 队列深度是影响性能的重要参数。操作系统层存在两个参数影响到 I/O 队列深度:块设备队列深度和 HBA 卡队列深度。建议按照如下策略配置块设备队列深度和 HBA 卡队列深度。
对于 Linux 操作系统,块设备最大队列深度为 128,而 HBA卡的队列参数与卡类型和驱动程序相关,请参考 HBA 厂商给出的规格值,如 Qlogic 8Gbps FC 双口 HBA 卡,限制每个 LUN 的最大队列深度为 32。而建议采用增加 LUN 个数的方式提高整体 I/O 队列深度。
对于 AIX 操作系统,华为建议安装 UltraPath 多路径,而不建议使用系统多路径或第三方多路径。安装了华为 UltraPath 多路径,块设备最大队列深度被调整为 32,若不使用华为 UltraPath,系统默认块设备最大队列深度为 5,建议将此值修改为 32 或更高。AIX 的 HBA 卡最大队列深度默认值为 200,可根据实际业务需求进行调整。
对于 Windows 操作系统,单个 LUN 的最大 I/O 队列深度同样取决于 HBA 卡厂商给出的规格值。
Oracle 11g 数据库 OLTP 业务下,建议针对以下参数进行调整,参数的最佳值应根据实际业务进行测试调整,以获取最佳性能和可靠性。下表列出了关键参数的含义和推荐值:
采用SwingBench测试,配置特定用户会话数,测试出来的性能如下:
最佳实践介绍了基于存储系统部署 Oracle 数据库的规划配置方案,并提供经验证的规划配置参考架构。用户在 存储阵列规划、部署 Oracle 11g 时可以利用提供的组网、参数设置、测试方法等等信息,在实践中予以指导,减少方案规划时的负担与实施过程中的风险。
【编辑推荐】
【责任编辑:姜华 TEL:(010)68476606】
点赞 0
如果觉得《oracle oltp和olap OLTP与OLAP概念 主要区别和完美实践》对你有帮助,请点赞、收藏,并留下你的观点哦!