OLTP 与 OLAP 概念、主要区别和完美实践

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 时可以利用提供的组网、参数设置、测试方法等等信息,在实践中予以指导,减少方案规划时的负担与实施过程中的风险。