你的位置:首页 > 数据库

[数据库]弄清楚你的业务类型——OLTP or OLAP


在Oracle数据库系统中,很多人没有弄清楚自己的业务类型到底是什么,就在开始盲目的寻求优化方法,而往往是把OLAP的方法使用在OLTP上,或者是OLTP的方法使用在OLAP上。这样的使用,有的时候,对性能没有任何的提高,甚至是大大的影响了性能,得到适得其反的效果。所以,在优化系统之前,弄清楚自己的业务类型。

1、什么是OLTP
OLTP,也叫联机事务处理(Online Transaction Processing),表示事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的transaction以及execute sql的数量。在这样的系统中,每秒处理的transaction往往超过几百个,或者是几千个,select 语句的执行量每秒几千甚至几万个。典型的OLTP系统如电子商务系统,银行,证卷等等,如美国ebay的业务数据库,就是很典型的OLTP数据库。
OLTP系统最容易出现的瓶颈就是CPU与磁盘子系统。cpu则取决于逻辑读以及内部调用,如函数等等。一个执行频繁的SQL语句,如果每个语句可以减少很少的逻辑读,也相当于优化了一些逻辑读很差的大型语句。很多人不感觉不到这里的作用,觉得一个语句几十个逻辑读,执行时间基本为0,就不需要优化了,其实,只要他的执行次数非常频繁,而且有优化的余地,就一定要优化,如减少一定的逻辑读或者降低执行次数,都是优化方法。
另外,一些计算性的函数,如sum,count,decode被非常频繁的使用,也是非常消耗cpu的,我遇到一个系统,因为一个sql语句,大量的使用了sum与decode进行行列转换,结果这一个语句就耗费了整个机器一半以上的CPU。
那么,在一般的OLTP系统中,如果不考虑我上面说的函数问题,那么,逻辑读乘以执行次数,决定了cpu的消耗程度,如一个语句,每秒执行次数为500次,每个逻辑读为15,但是,通过优化,能让每个语句的逻辑读从15降到10,那么,每秒的逻辑读就可以减少500*5=2500个,其实就是相当于优化了一个执行频率为每秒1次,每次逻辑读为2500个的语句(注意,2500个逻辑读,在oltp系统是非常差的语句)。再如,假定一个1GHZ的cpu每秒能正常处理的逻辑读是100,000个,如果是10个逻辑读一个的语句,每秒可以处理10,000个,而1000个逻辑读一个的语句,每秒则只能处理100个。
同以上道理,物理读乘以执行次数,则决定了存储子系统的处理能力,在一个OLTP环境中,物理读一般都是db file sequential read决定的,也就是单块读,一个典型的OLTP系统,db file sequential read应当基本等于磁盘子系统的读的IOPS。而磁盘子系统的IOPS处理能力,与cache命中率以及磁盘个数有很大的关系。我的一些文章中,也分析到了这些问题,如一个15K转速的磁盘,每秒最多能处理的iops达到150个,基本就是极限了,如果cache不命中,那么100个磁盘,最多能处理的IOPS仅仅是15000个(但是,实际上,还基本达不到这个值)。
OLTP最常用的技术就是cache技术与btree索引,cache决定了很多语句不需要从磁盘子系统获得数据,所以,web cache与oracle data buffer对OLTP系统是很重要的。另外,在索引使用方面,语句是越简单越好,这样执行计划也稳定,而且一定要使用绑定变量,减少语句解析,尽量减少关联。其它方面,基本不使用分区技术,MV技术,并行技术以及位图索引,因为并发量很高,批量更新可能要尽量快速提交避免阻塞的发生。
在ebay的数据库设计中,有一个很重要的点就是,数据库只负责存放数据,业务逻辑尽量在业务层实现,因为数据库扩展是困难的,而应用服务器扩展是简单的。其实,也就是说,在高可用的OLTP环境中,数据库使用越简单的功能越好。

2、什么是OLAP
OLAP,也叫联机分析(Online Analytical Processing),有的时候也叫DSS决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一个语句的执行时间可能会非常长,读取的数据也非常多。所以,这样的系统中,考核的标准往往决定于磁盘子系统的吞吐量。磁盘子系统的吞吐量则直接取决于磁盘的个数,这个时候,cache基本是没有效果的,这个时候数据库的读写基本上是db file scattered read与direct path read/write。在我前面的一些文章中描述过,如果一个15K的磁盘的IO量每秒13M,那么,100个磁盘,最多能提供的吞吐量则是1300M/s(实际上,也基本达不到这个值)。如果磁盘个数足够的话,还需要考虑采用比较大的带宽,如4GB的光纤接口。
在OLAP系统中,常使用的技术有分区技术,并行技术。如分区技术可以使得一些大表的扫描变得很快(只扫描单个分区),而且方便管理。另外,如果分区结合并行的话,也可以使得整个表的扫描也会变得很快。并行技术除了与分区技术结合外,在oracle 10g中,与rac结合实现多节点的同时扫描,效果也非常不错,把一个任务,如select的全表扫描,平均的分派到多个rac的节点上去。
在OLAP系统中,不需要使用绑定变量,因为整个系统的执行量很少,分析时间对于执行时间来说,可以忽略,而且避免出现错误的执行计划。但是OLAP中可以大量使用位图索引,物化视图,对于大的事务,尽量的寻求速度上的优化,没有必要象OLTP需要快速提交,甚至要刻意减慢执行的速度。

3、总结
特别是在高可用的OLTP环境中,不要盲目的把OLAP的技术拿过来用,如分区技术,如果不是大范围的使用了分区关键字作为where条件,而采用其它的字段作为where条件,那么,如果是本地索引,你将不得不扫描多个索引,而性能变的更为低下。如果是全局索引,那分区的意义又何在,只是多出一份分区技术的license而已。
并行技术也是如此,一般是在大型任务的时候才使用,好比说,实际生活中,一个比较大型的工作,如翻译一本书,你可以先安排多个人,每个人翻译不同的章节,这样是可以提高翻译速度,但是,你现在只是翻译一页,你也去分配不同的人翻译不同的行,再组合起来,这个时间,你一个人或者早就翻译完了。
位图索引在我前几篇文章中有交代,如果用在oltp环境中,可能因为阻塞范围太大,很容易阻塞与死锁,但是,在olap环境中,可能会因为其特有的特性,提高olap的查询速度。mv也是基本一样,包括触发器等等,在dml频繁的oltp系统上,很容易成为瓶颈,而在olap环境上,则可能会因为使用恰当而提高查询速度。

更多的差别与技术,细说下来太多了,有些东西,是要靠大家慢慢去体会的,我这里也就不多说了,大家可以平常在自己的业务中多多体会。

 

           oltp数据                 

olap数据

原始数据

导出数据  

细节性数据

综合性和提炼性数据  

当前值数据

历史数据  

可更新

不可更新,但周期性刷新  

一次处理的数据量小

一次处理的数据量大  

面向应用,事务驱动

面向分析,分析驱动

面向操作人员,支持日常操作   

面向决策人员,支持管理需要