说说OLTP和OLAP

在数据库查询中，存在两种典型的查询场景，一种是OLTP ，On-Line Transaction Processing，一种是 On-Line Analytical Processing，分别对应联机事物处理和联机查询分析两种不同类型。这两种查询类型的区分，对于基于数据库优化和调整有很大的差异，而OLTP和OLAP往往会混合在一起，做为一个整体呈现在用户的面前，因此在实际的系统优化过程中，必须采用“庖丁解牛”的方式进行深入的解剖，明白要理，才能展开相应的优化，提升数据库查询效率。

UEP做为公司系统设备管理的基础平台，常期致力于性能数据查询优化，主要解决管理系统设备上报性能数据的查询和分析功能，随着管理设备数量增加，必然会导致整体数据量的增加，对于性能数据查询效率带来较大的影响。

在UEP性能模块设计和实现过程中，对于OLTP和OLAP其实并没有做严格区分，通常会采用相同的方法进行处理，但是从数据库层面看，这些查询特点是不同的，此处就使用无线产品设备举例说明各自的典型场景。

OLTP典型场景：查询指定位置的一个小区计数器或者指标

该场景下，提交到数据库请求特点是小而精，这种特点的查询效率提升，重点需要考虑SQL语句解析时间、索引策略、数据库物理读取、存储设备IOPS。

SQL语句解析时间：使用数据库缓存中的信息进行软解析，而不是每次查询时进行硬解析，尽量采用能够让数据库SQL重用的SQL写法；

索引策略：数据库索引的有效性和健康状态，需要关注数据库索引的效率，绝对要避免数据库全表扫描操作，保持数据库索引B+数平衡；

数据库物理读取：消除数据库的物理读取，对于磁盘物理读取，通常速度都会非常慢，数据库对于热点数据都会进行缓存，如果在缓存中的数据，会直接走逻辑读，整体执行速度会快很多；

存储设备IOPS：对于硬件和整个文件系统来看，这样的小读取次数会非常多，整个文件系统和硬件需要按照高IOPS的方式进行设计。

OLAP典型场景：查询当前系统全网所有小区计数器或者指标

该场景下，提交到数据库请求特点是大而少，此类查询往往对应对于全网质量监控和评估，发起次数不会很频繁，但是每一个查询请求，都会对于数据库带来不小压力。这种查询效率提升，重点需要考虑数据存储方式、数据读取方式、数据库物理读取、存储设备和文件系统TPS。

数据存储方式：数据储存方式，要尽量按照访问获取需要的数据范围来进行数据的逻辑和物理储存，把无关的数据分离开，比如，通过数据库提供的表空间、表、分区等技术做好数据存储规划，便于数据库高速读取；

数据读取方式：结合数据的存储特点，确定相应的访问方式，在这种场景下，索引扫描可能已经不是最高效的访问方式，可以考虑全表扫描、并行执行等方式来加快速度的读取速度，同时需要关注数据库参数配置，以最大努力的方式，进行数据读取，同时尽量一次性的多读取数据，减少数据库总的读取次数。

存储设备和文件系统TPS：此种场景发起的数据库请求不是太频繁，系统在加大每次IO读取的数据量后，会导致系统IO总量增加，也就是要求系统TPS能力比较强，在指定时间内导致最大的数据读取量，该数据量为每秒IO次数*每次读取数据量，这个值越大，执行的速度就会越快。从磁盘读取原理看，如果参与这个读取的磁盘数量越多，那么TPS的能力就必定更强。但是在实际的存储系统和文件系统中，要完全清除参与的磁盘数量已经不太可能，磁盘阵列系统的RAID方式、磁盘阵列系统自身的文件存储和优化方式、操作系统多路软件设计和LVM卷管理策略、操作系统文件系统的存储和优化都会相互叠加。因此，一个唯一可能的方式时，按照相关的原理介绍，进行相关的配置操作，想象存储系统可能的执行方式，构造一种可以满足该场景的配置方式，提交到实际系统中进行测试，根据测试效果进行相应的持续改进。

OLAP和OLTP混合场景：查询当前指定一个分组下面所有小区计数器或者指标

该场景下介于OLATP和OLTP的混合型场景，即类似于OLTP，也类似与OLAP系统，因此此种场景必须按照具体的网络中小区数量、分组中小区数量做对比分析，可能会采用结合上述2种方式的优化策略进行优化。

通过上述分析，笔者认为OLTP和OLAP在实际的数据库系统，比如运营商设备性能数据查询系统中都会有典型的应用场景，因此对于这些应用场景，在考虑对于用户透明的基础上，比如采用不同的优化策略和方式进行优化，这样才能更好的利用好数据库系统，采用大一统的模式进行优化，往往会导致顾此失彼的局面，使整体系统优化陷入误区。

本文出自 “南方的熊熊” 博客，转载请与作者联系！