云南地震前兆数据库性能分析及优化处理方案

王华柳，刘克骧，马志刚

(云南省地震局腾冲地震台，云南 腾冲 679100)

地震前兆数据库是指除地震学以外的地磁、地电、地下流体、重力和定点形变等多学科固定台站观测数据的管理及共享平台(周克昌等，2007)。前兆观测系统所获得的观测数据通过台站、区域中心、学科中心及国家中心的四级体系进行汇集、管理、交换及应用。目前，我国的地震前兆数据库采用Oracle数据库系统(周克昌等，2010)。云南地震前兆台网中心从2007年开始安装使用地震前兆数据库，在使用客户端软件查询并显示数据时速度较慢。使用中国地震前兆台网处理系统2014集成版软件按图形方式显示单测项分钟值前兆数据，运行时间较长。“十五”期间，腾冲地震台安装了存储测震数据的Jopens系统，吴永权等(2010)针对Jopens数据库自主编写了一个测震分析软件，采用该软件打开同等数据量的Jopens数据库数据，运行速度非常快。由于前兆数据与测震数据的采样率不同，通过计算得到单测项分钟值前兆数据一年的数据量相当于采样率为100 Hz的三通道地震仪29.2分钟数据量。不同软件读取相同数据量的运行速度的测试结果见表1。表1中前兆台网处理系统测试结果为人工记时，测震分析软件测试结果为软件记时，均为10次记时的平均值。以下如无特殊说明，测试结果均为软件10次记时的平均值。结果显示，采用测震分析软件加载数据的耗时明显低于前兆台网处理软件加载数据的耗时，随着加载数据量的增加，前兆数据与测震数据的加载耗时比在0.042左右；软件功能模块的运算时间与数据量、运算复杂度及算法相关， 分析上述两种运算过程，认为前兆数据处理软件和测震数据处理软件按图形方式显示数据时，在数据库平台、软件算法及数据存储方式三个方面存在差异。本文使用Visual Basic 2010程序设计语言编写测试软件对上述三种差异进行实际测试，找到云南地震前兆数据处理系统在数据库查询方面运行速度较慢的原因，并针对实际情况提供了优化解决方案。

表1 不同软件读取相同数据量的运行速度比较

1 性能测试

1.1 算法测试

图1 获取数据流程

通过自主开发读取地震前兆数据库的程序，测试该程序达到地震前兆台网处理软件显示数据效果的运行时间可以完成算法测试。从数据库获取数据的流程见图1。

前兆数据库中存储前兆数据的字段为obsValue，该字段保存了一天的前兆观测值序列。以分钟值为例，观测值数据以ASCII 字符形式存放, 一天1 440 个分钟值数据按采样次序连接起来, 数据之间用空格分隔，可以得到观测值序列。系列中缺测数据用NULL表示, 全天缺数时可用NULLALL表示(周克昌等，2010)。这种存储方式在数据库中称为Clob格式。对该序列的解码过程比较简单，只需按空格分隔前兆数据序列即可完成。李井冈等(2008)对前兆数据库存取的数据(Clob格式)进行了存取效果研究，结果显示读取一年的分钟值数据需要7.85 s，如果对obsValue字段采用Blob格式存储(float型观测数据转换为字节)，速度可以提高到2.82 s。按上述流程编写测试软件，最初得到的结果与前兆台网处理软件的运行时间相当，同时也与李井冈等的研究结果一致。通过分析认为影响软件运行时间的主要原因是需要判断每一个前兆数据是否缺数，为了达到此目的需要实现一个循环，该循环算法对每一个通过循环主体的前兆数据进行判断，此判断过程非常耗时；另外绘制过程也比较耗时，原因同样是因为绘制前兆数据时需要判断数据是否缺数。通过改进并优化循环算法，比如将循环量较大的一维循环分解为循环量较小的二维循环，测试结果有了较大改善，结果见表2。从表2可以看到，即使使用了优化算法，读取前兆数据库的时间依旧长于读取测震数据库的时间，从算法复杂度方面分析认为主要原因在于显示前兆数据时不需要绘制缺失数据，而读取测震数据时可以采用缺数默认为0的方式进行处理，此种处理方式无需对数据进行判断，所以运行速度比较快速。

表2 不同算法读取前兆数据的运行速度比较

1.2 存储平台测试

在测试计算机上安装Oracle及MySQL数据库后分别在两种数据库中建立一张表保存前兆数据库采用的数据序列值。分别读取两个数据库中的数据，测试其读取速度。为了测试网络传输对读取速度的影响，在一台远程服务器上安装了Oracle及MySQL数据库后完成同样测试，测试结果见表3。结果表明，采用Oracle数据库存储的数据读取速度稍优于MySQL数据库，但不存在明显优势，本地存储的数据读取速度稍优于远程存储的数据，因为传输距离较短，所以也不存在明显优势， 故认为存储平台的差异对前兆数据的读取速度影响不大。但是测试结果中读取前兆数据库的速度明显慢于上述几种测试结果，原因包括硬件性能老化、存储空间不足及数据库配置不合理等。云南地震前兆数据库使用至今已经十余年时间，从安装之后不久就发现读取速度较慢，故认为云南地震前兆数据库在配置方面存在影响性能的问题。深入数据库内部发现，部分数据表主键缺失是影响数据库性能的主要原因。

表3 读取不同数据库前兆数据的运行速度比较

1.3 存储方式测试

表4 读取不同格式前兆数据的运行速度比较

在读取前兆数据库数据的时候，发现部分测项在保存预处理数据时没有对小数位数进行限制，导致小数位数过大，最大达到了16位，这样的精度是不真实的，它是浮点数在转换为字符串时系统保留的位数，对于数据运用而言没有实际意义，反而增加了数据库负担，影响了读写速度。如果在保存数据时对小数位数进行合理限制可以有效提升数据库存储效率。目前测震数据在数据库中的存储格式为SEED格式(IRIS，2006)，通常采用Steim2压缩算法。Steim2 压缩算法是SEED 波形数据的一种整型数据的压缩算法，该算法是一种压缩效率较高的差分压缩算法(罗新恒等，2003)。由于它保存的是数据序列的差值，所以在有限的存储空间内可以保存更多的数据，以分钟值前兆数据为例，如果有效位数为5位，加上一位空格共6位，采用前兆数据库存储方式保存数据，一天的数据量(1 440个数据)占用空间为8 640字节，而Steim2方式保存只需要800～1 000字节，占用存储空间为前兆数据库存储方式的1/10～1/8。由于前兆数据是浮点数，无法直接采用Steim2压缩算法压缩数据，需要将浮点数变换为整型数据，变换过程比较简单，假定一个数据系列中数据的最大有效小数位数为N，将该数据系列分别与10N相乘即可将该数据系列转换为整型数据。N是数据相互转换过程中的关键参数，所以采用Steim2压缩算法压缩浮点型数据时需要同时保存N值，这样才能准确完成数据逆转换(解压缩)。在测试计算机上安装Oracle 10g数据库后建立2张表，一张表用于存储前兆数据库采用的数据序列值，另一张表存储Steim2方式压缩的数据。分别读取2个表相同量级的数据，测试其读取速度，测试结果见表4。结果表明，Steim2压缩数据的读取速度明显优于空格分隔的数据序列，原因是其数据量小，占用内存少。表4中的耗时数据仅为读取数据库记录的时间，不包括绘制数据的时间。

2 优化处理

分析性能测试结果，可以认为影响前兆数据库读取速度的主要原因是存储平台的配置、数据存储格式及算法等原因，所以优化处理这几方面的问题可以有效提升前兆数据库的读取速度。

2.1 数据库优化

数据库优化可以解决存储平台的配置及数据存储格式方面的问题。鉴于在原有前兆数据库基础上进行优化存在破坏数据库的风险，为此重新搭建了一个数据库，数据库采用MySQL5.7作为数据库平台。MySQL数据库是一种开源的关系型数据库管理系统，虽然与Oracle及SQL Server等数据库系统相比，存在规模小、功能有限等不足，但对于管理云南地震前兆数据而言，它提供的功能已经足够。数据库在保留了原有前兆数据库结构的基础上增加了一个AutoID字段作为主键，对obsValue字段进行了Steim2压缩，同时对StartDate、StationID、PointID和ItemID字段建立索引，通过编写一个服务端程序定时下载云南前兆数据库数据的方式实现数据存储。结果表明，新建数据库占用的存储空间仅为原有数据库存储空间的1/8，存储效率得到了极大的提升。新建数据库前兆数据表结构见表5。利用数据库的主键及索引字段进行查询可以有效提升数据库查询速度，当然主键及索引的增加也会降低数据库的写效率，同时会使数据库的存储空间增加。但考虑到前兆数据库的写操作在时间上是分散的，而且数据量较小(每个台站每个测项仅1条记录)，而读操作查询的数据量相对较大。所以对上述字段建立索引对数据库写操作影响不大，但对于读操作的查询效率却能够带来相当明显的提升。

表5 新建前兆数据库数据表结构

2.2 客户端软件优化

由于数据库数据表结构的变化，中国地震前兆台网处理系统无法连接新建数据库，需要开发客户端软件完成数据库操作。针对新建前兆数据库的结构，采用Visual Basic 2010程序设计语言编写了客户端软件，运用Oracle.DataAccess组件连接Oracle数据库，MySql.Data组件连接MySQL数据库，软件运行主界面见图2。

图2 客户端软件运行主界面

客户端软件能够兼容原前兆数据库，针对传统前兆分析软件在绘制数据时无法自由完成数据缩放操作，主界面参照了测震分析软件的显示方式，采用数据滚动条及放大窗显示的方式实现数据的缩放操作，软件能够自动连接国家测震台网中心数据库并下载地震目录加载到数据窗口中(界面中采用线条标记)，同时自动加载日志记录并显示在数据窗口中(界面中网格区域)。采用一台64位终端计算机(内存4 GB、主频3.90 GHz的Intel® core(TM)i3-7100处理器)对数据库进行数据极限加载实验，结果见表6。结果表明客户端软件对两种数据库加载时，能够加载的最大数据量是相同的(对于分钟值数据，由于单测项数据量有限，文中给出的数据量是由多个测项相加后折合的单测项数据量)，这主要与终端计算机运行内存有关；但是加载时间却差别较大，对新建数据库数据的加载时间仅为加载原数据库时间的1/9。这个数据加载时间压缩比例与Steim2压缩比率基本相当。特别需要说明的是，这样的数据量采用中国地震前兆台网处理系统2014集成版软件将无法加载。

表6 数据库极限加载结果

3 结论

(1)地震前兆台网处理系统读取前兆观测数据的功能模块在算法方面存在耗时比较多的突出特征，可以通过优化算法来提高运行速度；数据库存储平台的差异对前兆数据的读取速度影响不大，但是云南地震前兆数据库自身配置对客户端软件查询数据库的运行速度影响较大，可能存在不合理配置；前兆数据库保存数据的方式影响了软件的运行速度，主要原因是此种存储方式占用存储空间较多。(2)数据库极限加载实验结果表明采用Steim2压缩算法保存数据可以有效提升读取数据库数据的速度，这样的速度提升能够提供非常良好的用户体验。(3)通过上述方法的优化，读取前兆数据的速度得到了非常明显的提升，对于数据运用而言，这样的提升可以改变数据运用的方式，因为可以轻松获取更多数据用于数据分析。(4)上述测试结果主要针对区域中心级前兆数据库，对于台站级前兆数据库同样存在相同的问题，对腾冲台地震数据库进行数据加载时运行速度同样非常慢，所以文中提及的优化方案也同样适用于台站级前兆数据库。