在数据库查询中,存在两种典型的查询场景,一种是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在实际的数据库系统,比如运营商设备性能数据查询系统中都会有典型的应用场景,因此对于这些应用场景,在考虑对于用户透明的基础上,比如采用不同的优化策略和方式进行优化,这样才能更好的利用好数据库系统,采用大一统的模式进行优化,往往会导致顾此失彼的局面,使整体系统优化陷入误区。