弄清楚你的业务类型——OLTP or OLAP
时间：2009-06-01 23:06:00
来源：UltraLAB图形工作站方案网站
人气：6301
作者：admin
在Oracle数据库系统中，很多人没有弄清楚自己的业务类型到底是什么，就在开始盲目的寻求优化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。这样的使用，有的时候，对性能没有任何的提高，甚至是大大的影响了性能，得到适得其反的效果。所以，在优化系统之前，弄清楚自己的业务类型。
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环境中，数据库使用越简单的功能越好。
OLAP，也叫联机分析(Online Analytical Processing)，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一个语句的执行时间可能会非常长，读取的数据也非常多。所以，这样的系统中，考核的标准往往决定于磁盘子系统的吞吐量。 #p#page_title#e#
磁盘子系统的吞吐量则直接取决于磁盘的个数，这个时候，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需要快速提交，甚至要刻意减慢执行的速度。
特别是在高可用的OLTP环境中，不要盲目的把OLAP的技术拿过来用，如分区技术，如果不是大范围的使用了分区关键字作为where条件，而采用其它的字段作为where条件，那么，如果是本地索引，你将不得不扫描多个索引，而性能变的更为低下。如果是全局索引，那分区的意义又何在，只是多出一份分区技术的license而已。
并行技术也是如此，一般是在大型任务的时候才使用，好比说，实际生活中，一个比较大型的工作，如翻译一本书，你可以先安排多个人，每个人翻译不同的章节，这样是可以提高翻译速度，但是，你现在只是翻译一页，你也去分配不同的人翻译不同的行，再组合起来，这个时间，你一个人或者早就翻译完了。
位图索引在我前几篇文章中有交代，如果用在oltp环境中，可能因为阻塞范围太大，很容易阻塞与死锁，但是，在olap环境中，可能会因为其特有的特性，提高olap的查询速度。mv也是基本一样，包括触发器等等，在dml频繁的oltp系统上，很容易成为瓶颈，而在olap环境上，则可能会因为使用恰当而提高查询速度。
更多的差别与技术，细说下来太多了，有些东西，是要靠大家慢慢去体会的，我这里也就不多说了，大家可以平常在自己的业务中多多体会。
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环境中，数据库使用越简单的功能越好。
OLAP，也叫联机分析(Online Analytical Processing)，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一个语句的执行时间可能会非常长，读取的数据也非常多。所以，这样的系统中，考核的标准往往决定于磁盘子系统的吞吐量。 #p#page_title#e#
磁盘子系统的吞吐量则直接取决于磁盘的个数，这个时候，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需要快速提交，甚至要刻意减慢执行的速度。
特别是在高可用的OLTP环境中，不要盲目的把OLAP的技术拿过来用，如分区技术，如果不是大范围的使用了分区关键字作为where条件，而采用其它的字段作为where条件，那么，如果是本地索引，你将不得不扫描多个索引，而性能变的更为低下。如果是全局索引，那分区的意义又何在，只是多出一份分区技术的license而已。
并行技术也是如此，一般是在大型任务的时候才使用，好比说，实际生活中，一个比较大型的工作，如翻译一本书，你可以先安排多个人，每个人翻译不同的章节，这样是可以提高翻译速度，但是，你现在只是翻译一页，你也去分配不同的人翻译不同的行，再组合起来，这个时间，你一个人或者早就翻译完了。
位图索引在我前几篇文章中有交代，如果用在oltp环境中，可能因为阻塞范围太大，很容易阻塞与死锁，但是，在olap环境中，可能会因为其特有的特性，提高olap的查询速度。mv也是基本一样，包括触发器等等，在dml频繁的oltp系统上，很容易成为瓶颈，而在olap环境上，则可能会因为使用恰当而提高查询速度。
更多的差别与技术，细说下来太多了，有些东西，是要靠大家慢慢去体会的，我这里也就不多说了，大家可以平常在自己的业务中多多体会。
