王華柳，劉克驤，馬志剛

(云南省地震局騰沖地震臺，云南 騰沖 679100)

地震前兆數(shù)據(jù)庫是指除地震學以外的地磁、地電、地下流體、重力和定點形變等多學科固定臺站觀測數(shù)據(jù)的管理及共享平臺(周克昌等，2007)。前兆觀測系統(tǒng)所獲得的觀測數(shù)據(jù)通過臺站、區(qū)域中心、學科中心及國家中心的四級體系進行匯集、管理、交換及應用。目前，我國的地震前兆數(shù)據(jù)庫采用Oracle數(shù)據(jù)庫系統(tǒng)(周克昌等，2010)。云南地震前兆臺網(wǎng)中心從2007年開始安裝使用地震前兆數(shù)據(jù)庫，在使用客戶端軟件查詢并顯示數(shù)據(jù)時速度較慢。使用中國地震前兆臺網(wǎng)處理系統(tǒng)2014集成版軟件按圖形方式顯示單測項分鐘值前兆數(shù)據(jù)，運行時間較長?！笆濉逼陂g，騰沖地震臺安裝了存儲測震數(shù)據(jù)的Jopens系統(tǒng)，吳永權等(2010)針對Jopens數(shù)據(jù)庫自主編寫了一個測震分析軟件，采用該軟件打開同等數(shù)據(jù)量的Jopens數(shù)據(jù)庫數(shù)據(jù)，運行速度非?？臁Ｓ捎谇罢讛?shù)據(jù)與測震數(shù)據(jù)的采樣率不同，通過計算得到單測項分鐘值前兆數(shù)據(jù)一年的數(shù)據(jù)量相當于采樣率為100 Hz的三通道地震儀29.2分鐘數(shù)據(jù)量。不同軟件讀取相同數(shù)據(jù)量的運行速度的測試結果見表1。表1中前兆臺網(wǎng)處理系統(tǒng)測試結果為人工記時，測震分析軟件測試結果為軟件記時，均為10次記時的平均值。以下如無特殊說明，測試結果均為軟件10次記時的平均值。結果顯示，采用測震分析軟件加載數(shù)據(jù)的耗時明顯低于前兆臺網(wǎng)處理軟件加載數(shù)據(jù)的耗時，隨著加載數(shù)據(jù)量的增加，前兆數(shù)據(jù)與測震數(shù)據(jù)的加載耗時比在0.042左右；軟件功能模塊的運算時間與數(shù)據(jù)量、運算復雜度及算法相關， 分析上述兩種運算過程，認為前兆數(shù)據(jù)處理軟件和測震數(shù)據(jù)處理軟件按圖形方式顯示數(shù)據(jù)時，在數(shù)據(jù)庫平臺、軟件算法及數(shù)據(jù)存儲方式三個方面存在差異。本文使用Visual Basic 2010程序設計語言編寫測試軟件對上述三種差異進行實際測試，找到云南地震前兆數(shù)據(jù)處理系統(tǒng)在數(shù)據(jù)庫查詢方面運行速度較慢的原因，并針對實際情況提供了優(yōu)化解決方案。

表1 不同軟件讀取相同數(shù)據(jù)量的運行速度比較

1 性能測試

1.1 算法測試

圖1 獲取數(shù)據(jù)流程

通過自主開發(fā)讀取地震前兆數(shù)據(jù)庫的程序，測試該程序達到地震前兆臺網(wǎng)處理軟件顯示數(shù)據(jù)效果的運行時間可以完成算法測試。從數(shù)據(jù)庫獲取數(shù)據(jù)的流程見圖1。

前兆數(shù)據(jù)庫中存儲前兆數(shù)據(jù)的字段為obsValue，該字段保存了一天的前兆觀測值序列。以分鐘值為例，觀測值數(shù)據(jù)以ASCII 字符形式存放, 一天1 440 個分鐘值數(shù)據(jù)按采樣次序連接起來, 數(shù)據(jù)之間用空格分隔，可以得到觀測值序列。系列中缺測數(shù)據(jù)用NULL表示, 全天缺數(shù)時可用NULLALL表示(周克昌等，2010)。這種存儲方式在數(shù)據(jù)庫中稱為Clob格式。對該序列的解碼過程比較簡單，只需按空格分隔前兆數(shù)據(jù)序列即可完成。李井岡等(2008)對前兆數(shù)據(jù)庫存取的數(shù)據(jù)(Clob格式)進行了存取效果研究，結果顯示讀取一年的分鐘值數(shù)據(jù)需要7.85 s，如果對obsValue字段采用Blob格式存儲(float型觀測數(shù)據(jù)轉換為字節(jié))，速度可以提高到2.82 s。按上述流程編寫測試軟件，最初得到的結果與前兆臺網(wǎng)處理軟件的運行時間相當，同時也與李井岡等的研究結果一致。通過分析認為影響軟件運行時間的主要原因是需要判斷每一個前兆數(shù)據(jù)是否缺數(shù)，為了達到此目的需要實現(xiàn)一個循環(huán)，該循環(huán)算法對每一個通過循環(huán)主體的前兆數(shù)據(jù)進行判斷，此判斷過程非常耗時；另外繪制過程也比較耗時，原因同樣是因為繪制前兆數(shù)據(jù)時需要判斷數(shù)據(jù)是否缺數(shù)。通過改進并優(yōu)化循環(huán)算法，比如將循環(huán)量較大的一維循環(huán)分解為循環(huán)量較小的二維循環(huán)，測試結果有了較大改善，結果見表2。從表2可以看到，即使使用了優(yōu)化算法，讀取前兆數(shù)據(jù)庫的時間依舊長于讀取測震數(shù)據(jù)庫的時間，從算法復雜度方面分析認為主要原因在于顯示前兆數(shù)據(jù)時不需要繪制缺失數(shù)據(jù)，而讀取測震數(shù)據(jù)時可以采用缺數(shù)默認為0的方式進行處理，此種處理方式無需對數(shù)據(jù)進行判斷，所以運行速度比較快速。

表2 不同算法讀取前兆數(shù)據(jù)的運行速度比較

1.2 存儲平臺測試

在測試計算機上安裝Oracle及MySQL數(shù)據(jù)庫后分別在兩種數(shù)據(jù)庫中建立一張表保存前兆數(shù)據(jù)庫采用的數(shù)據(jù)序列值。分別讀取兩個數(shù)據(jù)庫中的數(shù)據(jù)，測試其讀取速度。為了測試網(wǎng)絡傳輸對讀取速度的影響，在一臺遠程服務器上安裝了Oracle及MySQL數(shù)據(jù)庫后完成同樣測試，測試結果見表3。結果表明，采用Oracle數(shù)據(jù)庫存儲的數(shù)據(jù)讀取速度稍優(yōu)于MySQL數(shù)據(jù)庫，但不存在明顯優(yōu)勢，本地存儲的數(shù)據(jù)讀取速度稍優(yōu)于遠程存儲的數(shù)據(jù)，因為傳輸距離較短，所以也不存在明顯優(yōu)勢， 故認為存儲平臺的差異對前兆數(shù)據(jù)的讀取速度影響不大。但是測試結果中讀取前兆數(shù)據(jù)庫的速度明顯慢于上述幾種測試結果，原因包括硬件性能老化、存儲空間不足及數(shù)據(jù)庫配置不合理等。云南地震前兆數(shù)據(jù)庫使用至今已經(jīng)十余年時間，從安裝之后不久就發(fā)現(xiàn)讀取速度較慢，故認為云南地震前兆數(shù)據(jù)庫在配置方面存在影響性能的問題。深入數(shù)據(jù)庫內部發(fā)現(xiàn)，部分數(shù)據(jù)表主鍵缺失是影響數(shù)據(jù)庫性能的主要原因。

表3 讀取不同數(shù)據(jù)庫前兆數(shù)據(jù)的運行速度比較

1.3 存儲方式測試

表4 讀取不同格式前兆數(shù)據(jù)的運行速度比較

在讀取前兆數(shù)據(jù)庫數(shù)據(jù)的時候，發(fā)現(xiàn)部分測項在保存預處理數(shù)據(jù)時沒有對小數(shù)位數(shù)進行限制，導致小數(shù)位數(shù)過大，最大達到了16位，這樣的精度是不真實的，它是浮點數(shù)在轉換為字符串時系統(tǒng)保留的位數(shù)，對于數(shù)據(jù)運用而言沒有實際意義，反而增加了數(shù)據(jù)庫負擔，影響了讀寫速度。如果在保存數(shù)據(jù)時對小數(shù)位數(shù)進行合理限制可以有效提升數(shù)據(jù)庫存儲效率。目前測震數(shù)據(jù)在數(shù)據(jù)庫中的存儲格式為SEED格式(IRIS，2006)，通常采用Steim2壓縮算法。Steim2 壓縮算法是SEED 波形數(shù)據(jù)的一種整型數(shù)據(jù)的壓縮算法，該算法是一種壓縮效率較高的差分壓縮算法(羅新恒等，2003)。由于它保存的是數(shù)據(jù)序列的差值，所以在有限的存儲空間內可以保存更多的數(shù)據(jù)，以分鐘值前兆數(shù)據(jù)為例，如果有效位數(shù)為5位，加上一位空格共6位，采用前兆數(shù)據(jù)庫存儲方式保存數(shù)據(jù)，一天的數(shù)據(jù)量(1 440個數(shù)據(jù))占用空間為8 640字節(jié)，而Steim2方式保存只需要800～1 000字節(jié)，占用存儲空間為前兆數(shù)據(jù)庫存儲方式的1/10～1/8。由于前兆數(shù)據(jù)是浮點數(shù)，無法直接采用Steim2壓縮算法壓縮數(shù)據(jù)，需要將浮點數(shù)變換為整型數(shù)據(jù)，變換過程比較簡單，假定一個數(shù)據(jù)系列中數(shù)據(jù)的最大有效小數(shù)位數(shù)為N，將該數(shù)據(jù)系列分別與10N相乘即可將該數(shù)據(jù)系列轉換為整型數(shù)據(jù)。N是數(shù)據(jù)相互轉換過程中的關鍵參數(shù)，所以采用Steim2壓縮算法壓縮浮點型數(shù)據(jù)時需要同時保存N值，這樣才能準確完成數(shù)據(jù)逆轉換(解壓縮)。在測試計算機上安裝Oracle 10g數(shù)據(jù)庫后建立2張表，一張表用于存儲前兆數(shù)據(jù)庫采用的數(shù)據(jù)序列值，另一張表存儲Steim2方式壓縮的數(shù)據(jù)。分別讀取2個表相同量級的數(shù)據(jù)，測試其讀取速度，測試結果見表4。結果表明，Steim2壓縮數(shù)據(jù)的讀取速度明顯優(yōu)于空格分隔的數(shù)據(jù)序列，原因是其數(shù)據(jù)量小，占用內存少。表4中的耗時數(shù)據(jù)僅為讀取數(shù)據(jù)庫記錄的時間，不包括繪制數(shù)據(jù)的時間。

2 優(yōu)化處理

分析性能測試結果，可以認為影響前兆數(shù)據(jù)庫讀取速度的主要原因是存儲平臺的配置、數(shù)據(jù)存儲格式及算法等原因，所以優(yōu)化處理這幾方面的問題可以有效提升前兆數(shù)據(jù)庫的讀取速度。

2.1 數(shù)據(jù)庫優(yōu)化

數(shù)據(jù)庫優(yōu)化可以解決存儲平臺的配置及數(shù)據(jù)存儲格式方面的問題。鑒于在原有前兆數(shù)據(jù)庫基礎上進行優(yōu)化存在破壞數(shù)據(jù)庫的風險，為此重新搭建了一個數(shù)據(jù)庫，數(shù)據(jù)庫采用MySQL5.7作為數(shù)據(jù)庫平臺。MySQL數(shù)據(jù)庫是一種開源的關系型數(shù)據(jù)庫管理系統(tǒng)，雖然與Oracle及SQL Server等數(shù)據(jù)庫系統(tǒng)相比，存在規(guī)模小、功能有限等不足，但對于管理云南地震前兆數(shù)據(jù)而言，它提供的功能已經(jīng)足夠。數(shù)據(jù)庫在保留了原有前兆數(shù)據(jù)庫結構的基礎上增加了一個AutoID字段作為主鍵，對obsValue字段進行了Steim2壓縮，同時對StartDate、StationID、PointID和ItemID字段建立索引，通過編寫一個服務端程序定時下載云南前兆數(shù)據(jù)庫數(shù)據(jù)的方式實現(xiàn)數(shù)據(jù)存儲。結果表明，新建數(shù)據(jù)庫占用的存儲空間僅為原有數(shù)據(jù)庫存儲空間的1/8，存儲效率得到了極大的提升。新建數(shù)據(jù)庫前兆數(shù)據(jù)表結構見表5。利用數(shù)據(jù)庫的主鍵及索引字段進行查詢可以有效提升數(shù)據(jù)庫查詢速度，當然主鍵及索引的增加也會降低數(shù)據(jù)庫的寫效率，同時會使數(shù)據(jù)庫的存儲空間增加。但考慮到前兆數(shù)據(jù)庫的寫操作在時間上是分散的，而且數(shù)據(jù)量較小(每個臺站每個測項僅1條記錄)，而讀操作查詢的數(shù)據(jù)量相對較大。所以對上述字段建立索引對數(shù)據(jù)庫寫操作影響不大，但對于讀操作的查詢效率卻能夠帶來相當明顯的提升。

表5 新建前兆數(shù)據(jù)庫數(shù)據(jù)表結構

2.2 客戶端軟件優(yōu)化

由于數(shù)據(jù)庫數(shù)據(jù)表結構的變化，中國地震前兆臺網(wǎng)處理系統(tǒng)無法連接新建數(shù)據(jù)庫，需要開發(fā)客戶端軟件完成數(shù)據(jù)庫操作。針對新建前兆數(shù)據(jù)庫的結構，采用Visual Basic 2010程序設計語言編寫了客戶端軟件，運用Oracle.DataAccess組件連接Oracle數(shù)據(jù)庫，MySql.Data組件連接MySQL數(shù)據(jù)庫，軟件運行主界面見圖2。

圖2 客戶端軟件運行主界面

客戶端軟件能夠兼容原前兆數(shù)據(jù)庫，針對傳統(tǒng)前兆分析軟件在繪制數(shù)據(jù)時無法自由完成數(shù)據(jù)縮放操作，主界面參照了測震分析軟件的顯示方式，采用數(shù)據(jù)滾動條及放大窗顯示的方式實現(xiàn)數(shù)據(jù)的縮放操作，軟件能夠自動連接國家測震臺網(wǎng)中心數(shù)據(jù)庫并下載地震目錄加載到數(shù)據(jù)窗口中(界面中采用線條標記)，同時自動加載日志記錄并顯示在數(shù)據(jù)窗口中(界面中網(wǎng)格區(qū)域)。采用一臺64位終端計算機(內存4 GB、主頻3.90 GHz的Intel? core(TM)i3-7100處理器)對數(shù)據(jù)庫進行數(shù)據(jù)極限加載實驗，結果見表6。結果表明客戶端軟件對兩種數(shù)據(jù)庫加載時，能夠加載的最大數(shù)據(jù)量是相同的(對于分鐘值數(shù)據(jù)，由于單測項數(shù)據(jù)量有限，文中給出的數(shù)據(jù)量是由多個測項相加后折合的單測項數(shù)據(jù)量)，這主要與終端計算機運行內存有關；但是加載時間卻差別較大，對新建數(shù)據(jù)庫數(shù)據(jù)的加載時間僅為加載原數(shù)據(jù)庫時間的1/9。這個數(shù)據(jù)加載時間壓縮比例與Steim2壓縮比率基本相當。特別需要說明的是，這樣的數(shù)據(jù)量采用中國地震前兆臺網(wǎng)處理系統(tǒng)2014集成版軟件將無法加載。

表6 數(shù)據(jù)庫極限加載結果

3 結論

(1)地震前兆臺網(wǎng)處理系統(tǒng)讀取前兆觀測數(shù)據(jù)的功能模塊在算法方面存在耗時比較多的突出特征，可以通過優(yōu)化算法來提高運行速度；數(shù)據(jù)庫存儲平臺的差異對前兆數(shù)據(jù)的讀取速度影響不大，但是云南地震前兆數(shù)據(jù)庫自身配置對客戶端軟件查詢數(shù)據(jù)庫的運行速度影響較大，可能存在不合理配置；前兆數(shù)據(jù)庫保存數(shù)據(jù)的方式影響了軟件的運行速度，主要原因是此種存儲方式占用存儲空間較多。(2)數(shù)據(jù)庫極限加載實驗結果表明采用Steim2壓縮算法保存數(shù)據(jù)可以有效提升讀取數(shù)據(jù)庫數(shù)據(jù)的速度，這樣的速度提升能夠提供非常良好的用戶體驗。(3)通過上述方法的優(yōu)化，讀取前兆數(shù)據(jù)的速度得到了非常明顯的提升，對于數(shù)據(jù)運用而言，這樣的提升可以改變數(shù)據(jù)運用的方式，因為可以輕松獲取更多數(shù)據(jù)用于數(shù)據(jù)分析。(4)上述測試結果主要針對區(qū)域中心級前兆數(shù)據(jù)庫，對于臺站級前兆數(shù)據(jù)庫同樣存在相同的問題，對騰沖臺地震數(shù)據(jù)庫進行數(shù)據(jù)加載時運行速度同樣非常慢，所以文中提及的優(yōu)化方案也同樣適用于臺站級前兆數(shù)據(jù)庫。