基于TimesTen內(nèi)存數(shù)據(jù)庫提升股道現(xiàn)車同步應(yīng)用性能的研究與測試

王鳳琳

（北京經(jīng)緯信息技術(shù)有限公司，北京 100081）

鐵路運輸信息集成平臺的目標(biāo)是實現(xiàn)列車、車輛、貨物、機車、機車乘務(wù)員等信息的數(shù)據(jù)集中與共享，并實時掌握與動態(tài)追蹤其位置和狀態(tài)、推算與預(yù)測其變化趨勢，為實現(xiàn)精確調(diào)度指揮奠定基礎(chǔ)，同時為貨運電子商務(wù)和貨運組織改革提供必要的技術(shù)支撐。

運輸信息集成平臺建設(shè)過程中，中國鐵路總公司級（簡稱：總公司級）實時掌握各車站股道現(xiàn)車情況，以便精確組織運輸生產(chǎn)，是一項重要且迫切的需求。而鐵路運輸當(dāng)前的實際情況是，股道現(xiàn)車數(shù)據(jù)除本車站外，僅由車站所在鐵路局實時掌握，鐵路總公司調(diào)度部僅能通過各個鐵路局的現(xiàn)車系統(tǒng)查詢相關(guān)信息，無法從全路角度掌控所有在站車輛的位置、數(shù)量及空重狀態(tài)，故如何在總公司級實時掌握并管理全路約60萬輛股道現(xiàn)車，是運輸信息集成平臺建設(shè)中亟需解決的問題。

本文旨在分析當(dāng)前股道現(xiàn)車同步應(yīng)用存在的主要問題的基礎(chǔ)上，針對新的內(nèi)存數(shù)據(jù)庫技術(shù)進行了學(xué)習(xí)與研究，并將其運用于股道現(xiàn)車同步應(yīng)用測試，為應(yīng)用性能的提升提供了科學(xué)依據(jù)和有力支撐。

1 主要問題及解決思路

1.1 主要問題

中國鐵路總公司（簡稱：總公司）運輸信息集成平臺股道現(xiàn)車同步應(yīng)用運行在Unix操作系統(tǒng)，使用Oracle數(shù)據(jù)庫，運用Pro*C編程語言，實現(xiàn)車站股道現(xiàn)車數(shù)據(jù)同步至總公司。全路股道現(xiàn)車數(shù)據(jù)龐大且實時變化，基于當(dāng)前的設(shè)備能力和技術(shù)水平，很難在總公司級做到真正意義上的同步，即每一輛車的變化狀態(tài)都實時反映在總公司運輸信息集成平臺中。目前采用的方式是：利用MQ消息傳輸機制，各鐵路局每30 min按車站為單位以XML文件的形式上報局管內(nèi)車站股道現(xiàn)車數(shù)據(jù)至總公司集成平臺，總公司接收文件并解析入數(shù)據(jù)庫，以數(shù)據(jù)共享方式向相關(guān)應(yīng)用提供數(shù)據(jù)支持。

全路已實施車站系統(tǒng)的車站約6 000多個，均需每30 min上報本站當(dāng)前股道現(xiàn)車數(shù)據(jù)，具體包括車號、到達(dá)時間、到達(dá)股道、空重、始發(fā)站、終到站、貨物、車輛狀態(tài)等信息[1]；對于當(dāng)前時間沒有任何車輛的車站，仍需上報股道現(xiàn)車報告，以便在總公司股道現(xiàn)車庫中清除上一時間點的車輛信息。頻繁的刪除和插入操作，使得總公司股道現(xiàn)車庫壓力較大，執(zhí)行效率較低。為此，根據(jù)各鐵路局報告數(shù)量，經(jīng)過估算測試，優(yōu)化為6個進程并行處理，滿足30 min同步的要求，每處理30 min數(shù)據(jù)需大約12 min左右，即總公司數(shù)據(jù)與車站實際情況之間存在約40 min的時間差。時間差使得總公司與鐵路局?jǐn)?shù)據(jù)存在較大的不一致性，而提高兩級數(shù)據(jù)一致性的首要問題是縮短數(shù)據(jù)同步時間間隔，提升數(shù)據(jù)處理能力。

1.2 解決思路

內(nèi)存數(shù)據(jù)庫技術(shù)具有更快的數(shù)據(jù)讀取速度，能夠大大提升數(shù)據(jù)處理效率，且該項技術(shù)在鐵路互聯(lián)網(wǎng)余票查詢[2]、鐵路貨車追蹤[3]等應(yīng)用中已取得一定成效。經(jīng)過對目前主流的各類內(nèi)存數(shù)據(jù)庫產(chǎn)品進行對比和分析，基于與既有應(yīng)用最大的兼容性，總公司運輸信息集成平臺股道現(xiàn)車同步應(yīng)用選取了Oracle TimesTen內(nèi)存數(shù)據(jù)庫，進行了數(shù)據(jù)處理性能和高可用性方面的研究與測試。

2 Oracle TimesTen內(nèi)存數(shù)據(jù)庫簡介

Oracle內(nèi)存數(shù)據(jù)庫TimesTen 是一款針對內(nèi)存進行了優(yōu)化的關(guān)系型數(shù)據(jù)庫，它為應(yīng)用程序提供了即時響應(yīng)性和非常高的吞吐量。Oracle TimesTen作為高速緩存或嵌入式數(shù)據(jù)庫部署在應(yīng)用程序中，利用標(biāo)準(zhǔn)SQL 接口對完全位于物理內(nèi)存中的數(shù)據(jù)存儲進行操作，對于大規(guī)模的查詢應(yīng)用非常有好處[4]。

目前，Oracle TimesTen在全球的客戶包括Dell[5]、美國美林銀行[6]、上海海關(guān)[7]等，擁有如此眾多的客戶群并得到業(yè)界的廣泛認(rèn)可，主要得益于以下幾項優(yōu)勢[8]：

（1）能夠和Oracle數(shù)據(jù)庫做無縫集成，數(shù)據(jù)可以在TimesTen和Oracle直接實現(xiàn)實時雙向流動；

（2）TimesTen可以做成多節(jié)點并行提供服務(wù)的模式，數(shù)據(jù)在多個TimesTen之間直接實現(xiàn)實時或非實時的傳輸，進一步提高了系統(tǒng)的擴展性和可靠性；

（3）TimesTen是符合RDBMS標(biāo)準(zhǔn)的獨立內(nèi)存數(shù)據(jù)庫服務(wù)，支持SQL92，可運行在Linux、Windows、AIX等操作系統(tǒng)平臺上，使用Java、.NET、 C、 C++、 Pro*C 等語言進行應(yīng)用開發(fā)。

基于以上幾點，并結(jié)合總公司運輸信息集成平臺股道現(xiàn)車同步應(yīng)用的特點，運行于Unix平臺、使用Oracle數(shù)據(jù)庫、應(yīng)用Pro*C語言、業(yè)務(wù)邏輯相對簡單但要求快速響應(yīng)，Oracle TimesTen內(nèi)存數(shù)據(jù)庫是合適的選擇。

3 Oracle TimesTen測試過程

3.1 測試目的

本次測試的主要目的是驗證固定場景下內(nèi)存數(shù)據(jù)庫在數(shù)據(jù)處理上的效率，為評估內(nèi)存數(shù)據(jù)庫技術(shù)在運輸信息集成平臺的使用提供依據(jù)。

3.2 測試環(huán)境及步驟

3.2.1 軟硬件環(huán)境配置

測試環(huán)境的軟硬件配置情況如表1所示，兩臺主機分別安裝TimesTen11，建立Active Standby Pair主從復(fù)制關(guān)系，使用Oracle Cluster Ware作為集群管理軟件，監(jiān)控TimesTen及錯誤切換、監(jiān)控應(yīng)用和文件系統(tǒng)及應(yīng)用和文件系統(tǒng)切換。系統(tǒng)邏輯架構(gòu)如圖1所示。測試文件位于/u01/testdata目錄，TimesTen軟件安裝于/home/oracle/TimesTen/tt1122目錄，測試程序和腳本位于/home/oracle/poc目錄。

3.2.2 測試數(shù)據(jù)說明

表1 軟硬件環(huán)境配置

圖1 系統(tǒng)邏輯架構(gòu)

測試所用數(shù)據(jù)是實際業(yè)務(wù)數(shù)據(jù)文件的備份，為XML格式文件，描述各鐵路局上報的車站股道現(xiàn)車情況，一個車站對應(yīng)一個或多個文件，沒有現(xiàn)車的車站上報一個只有文件頭沒有文件內(nèi)容的空文件。為便于測試，將備份文件整理為數(shù)據(jù)集合A和數(shù)據(jù)集合B：數(shù)據(jù)集A是從隨機備份的實際業(yè)務(wù)數(shù)據(jù)的全集中經(jīng)過篩選后，模擬全路各站每30 min上報的一輪數(shù)據(jù)的集合，并比照目前股道現(xiàn)車同步應(yīng)用的實際情況，按鐵路局分6個目錄保存，分別為gdcl_1、gdcl_2、……、gdcl_6；數(shù)據(jù)集B是在A的基礎(chǔ)上，按鐵路局將文件分為12個目錄保存，分別為gdcl_1、gdcl_2、……、gdcl_12。同時，為了保證測試的準(zhǔn)確性，以股道現(xiàn)車實際生產(chǎn)數(shù)據(jù)表BGDCARA中的數(shù)據(jù)作為測試基礎(chǔ)數(shù)據(jù)。

表2 測試數(shù)據(jù)集基本情況描述

測試數(shù)據(jù)集A和B中文件數(shù)量和占用空間大小描述如表2所示。鐵路局上報的股道車輛文件格式和股道車輛數(shù)據(jù)表結(jié)構(gòu)，如圖2和圖3所示。

圖2 股道現(xiàn)車文件格式

圖3 股道現(xiàn)車數(shù)據(jù)表結(jié)構(gòu)

3.2.3 測試步驟

（1）將Oracle數(shù)據(jù)庫中基礎(chǔ)數(shù)據(jù)表的數(shù)據(jù)導(dǎo)入到內(nèi)存數(shù)據(jù)庫表BGDCARA中。

（2）應(yīng)用按時序分別讀取各文件夾中的報文，進行XML報文解析，并更新內(nèi)存數(shù)據(jù)庫表BGDCARA。處理過程需保留日志備查。

（3）處理某一車站報告時，需刪除數(shù)據(jù)庫表中該車站對應(yīng)的所有車輛，解析文件中每一輛車的詳細(xì)信息，插入到內(nèi)存數(shù)據(jù)庫表BGDCARA中。

（4）正確處理完畢的文件直接刪除；如果文件校驗有錯，將該文件保存到錯誤文件目錄。

（5）測試完畢，將內(nèi)存數(shù)據(jù)庫數(shù)據(jù)表BGDCARA的數(shù)據(jù)導(dǎo)出到Oracle數(shù)據(jù)庫中的數(shù)據(jù)表。

3.3 測試場景及結(jié)果

3.3.1 性能測試

性能測試是為了驗證系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的[9]。本測試僅涉及dp29-08一臺主機，基于數(shù)據(jù)集A和B，以O(shè)CI和Java兩種方式分別進行性能測試，以驗證Oracle TimesTen數(shù)據(jù)處理能力。

（1）測試準(zhǔn)備

a.連接TimesTen數(shù)據(jù)庫gdcl1，比照集成平臺生產(chǎn)環(huán)境中股道車輛Oracle數(shù)據(jù)表結(jié)構(gòu)和索引在TimesTen數(shù)據(jù)庫中新建數(shù)據(jù)表BGDCARA。

b.將Oracle數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)入TimesTen，記錄表行數(shù)。數(shù)據(jù)成功通過TimesTen緩存特性從Oracle數(shù)據(jù)庫導(dǎo)入，記錄數(shù)為626 610。

c.在/u01/testdata目錄下新建子目錄A和B，解壓測試數(shù)據(jù)集A到/u01/testdata/A目錄下，解壓測試數(shù)據(jù)集B到/u01/testdata/B目錄下。

（2）OCI測試

a. A數(shù)據(jù)集測試。比照既有生產(chǎn)環(huán)境下的模式，啟動6個Pro*C進程分別同時處理數(shù)據(jù)集6個文件夾中的數(shù)據(jù)，以最后完成的進程運行時間作為總執(zhí)行時間。為了保證測試的準(zhǔn)確性，共進行10輪測試，記錄每次運行時間，并計算一輪平均運行時間為16 s。登錄TimesTen gdcl1數(shù)據(jù)庫，查看數(shù)據(jù)表BGDCARA中的數(shù)據(jù)及記錄數(shù)。數(shù)據(jù)表總記錄數(shù)為620 356，各字段顯示正確。/u01/testdata/A目錄下正確處理完畢的XML文件成功刪除，解析校驗不正確的文件共4個，被挪至/u01/testdata/errdata目錄下。

b. B數(shù)據(jù)集測試。與既有生產(chǎn)環(huán)境下的模式不同，測試啟動12個Pro*C進程分別同時處理數(shù)據(jù)集12個文件夾中的數(shù)據(jù)，以最后完成的進程運行時間作為總執(zhí)行時間。為了保證測試的準(zhǔn)確性，共進行10輪測試，記錄每次運行時間，并計算一輪平均運行時間為18 s。登錄TimesTen gdcl1數(shù)據(jù)庫，查看數(shù)據(jù)表BGDCARA中的數(shù)據(jù)及記錄數(shù)。數(shù)據(jù)表總記錄數(shù)為620 356，各字段顯示正確。/u01/testdata/B目錄下正確處理完畢的XML文件成功刪除，解析校驗不正確的文件共4個，被挪至/u01/testdata/errdata目錄下。

（3）Java測試

a. A數(shù)據(jù)集測試。比照既有生產(chǎn)環(huán)境下的模式，啟動6個Java進程分別同時處理數(shù)據(jù)集6個文件夾中的數(shù)據(jù)，以最后完成的進程運行時間作為總執(zhí)行時間。為了保證測試的準(zhǔn)確性，共進行10輪測試，記錄每次運行時間，并計算一輪平均運行時間為22 s。登錄TimesTen gdcl1數(shù)據(jù)庫，查看數(shù)據(jù)表BGDCARA中的數(shù)據(jù)及記錄數(shù)。數(shù)據(jù)表總記錄數(shù)為620 356，各字段顯示正確。/u01/testdata/A目錄下正確處理完畢的XML文件成功刪除，解析校驗不正確的文件共4個，被挪至/u01/testdata/errdata目錄下。

b. B數(shù)據(jù)集測試。與既有生產(chǎn)環(huán)境下的模式不同，測試啟動12個Java進程分別同時處理數(shù)據(jù)集12個文件夾中的數(shù)據(jù)，以最后完成的進程的運行時間作為總執(zhí)行時間。為了保證測試的準(zhǔn)確性，共進行10輪測試，記錄每次運行時間，并計算一輪平均運行時間為24 s。登錄TimesTen gdcl1數(shù)據(jù)庫，查看數(shù)據(jù)表BGDCARA中的數(shù)據(jù)及記錄數(shù)。數(shù)據(jù)表總記錄數(shù)為620 356，各字段顯示正確。/u01/testdata/B目錄下正確處理完畢的XML文件成功刪除，解析校驗不正確的文件共4個，被挪至/u01/testdata/errdata目錄下。

（4）測試結(jié)果

性能測試結(jié)果如表3和表4所示。表3是測試過程中執(zhí)行DELETE和INSERT操作的次數(shù)，表4匯總了各類測試方式的處理效率。從兩個表中可以看出，OCI方式數(shù)據(jù)處理效率明顯高于Java方式；頻繁的DELETE與INSERT操作并未對數(shù)據(jù)處理效率有明顯影響；當(dāng)并行進程數(shù)由6調(diào)整到12時，OCI與Java 方式的處理時間均有所增加，這說明并行度也有一個平衡點，并非并發(fā)度越高越好。

3.3.2 高可用性測試

本文高可用性測試采用主從方式，即主機工作，備機處于監(jiān)控準(zhǔn)備狀況，當(dāng)主機宕機時，備機接管主機的一切工作，待主機恢復(fù)正常后，按使用者的設(shè)定以自動或手動方式將服務(wù)切換到主機上運行，數(shù)據(jù)的一致性通過共享存儲系統(tǒng)解決[10]。

表3 數(shù)據(jù)表操作統(tǒng)計表

表4 處理效率匯總表

本測試涉及dp29-08和dp29-07兩臺主機，數(shù)據(jù)庫為gdcl1（dp29-08）和gdcl2（dp29-07），目的是為驗證TimesTen對業(yè)務(wù)連續(xù)性的支持。

（1）測試準(zhǔn)備

a.清空dp29-08主機gdcl1數(shù)據(jù)庫BGDCARA數(shù)據(jù)表中的測試數(shù)據(jù)；在主機dp29-07 gdcl2數(shù)據(jù)庫中新建數(shù)據(jù)表BGDCARA。

b.從Oracle數(shù)據(jù)庫導(dǎo)入數(shù)據(jù)到gdcl1，記錄數(shù)為626 610，登錄gdcl2可以看到相同記錄數(shù)，確認(rèn)兩個數(shù)據(jù)庫之間數(shù)據(jù)復(fù)制正常。

c.為便于測試，將6個文件夾中的數(shù)據(jù)匯總到一個文件夾中，以O(shè)IC方式啟動一個應(yīng)用進程處理數(shù)據(jù)。

（2）高可用性測試之模擬內(nèi)存數(shù)據(jù)庫故障

a.啟動應(yīng)用，默認(rèn)連接位于主機dp29-08的數(shù)據(jù)庫gdcl1，進程運行正常，實時往數(shù)據(jù)表中寫入記錄。模擬內(nèi)存數(shù)據(jù)庫故障，手動Kill數(shù)據(jù)庫守護進程，應(yīng)用立即檢測到數(shù)據(jù)庫錯誤，并成功切換至gdcl2數(shù)據(jù)庫繼續(xù)處理文件、插入數(shù)據(jù)。

b.文件全部處理完成后，檢查兩數(shù)據(jù)庫表中記錄數(shù)。gdcl2數(shù)據(jù)庫表中記錄數(shù)為620 356，gdcl1數(shù)據(jù)庫表中記錄數(shù)為379 703，為數(shù)據(jù)庫gdcl1故障之前應(yīng)用寫入數(shù)據(jù)表的記錄數(shù)。

c.重新啟動數(shù)據(jù)庫gdcl1，復(fù)制關(guān)系自動建立，最終gdcl1中的數(shù)據(jù)由379 703變?yōu)?20 356，兩數(shù)據(jù)庫表數(shù)據(jù)完全一致。

（3）高可用性測試之模擬主機故障

a.啟動應(yīng)用，默認(rèn)連接位于主機dp29-08的數(shù)據(jù)庫gdcl1，進程運行正常，實時往數(shù)據(jù)表中寫入記錄。模擬主機dp29-08故障，reboot重啟主機，應(yīng)用停頓約幾十秒后檢測到錯誤，并成功切換到gdcl2數(shù)據(jù)庫繼續(xù)處理文件、插入數(shù)據(jù)。

b.文件全部處理完成后，檢查兩數(shù)據(jù)庫表中記錄數(shù)。gdcl2數(shù)據(jù)庫表中記錄數(shù)為620 356，gdcl1數(shù)據(jù)庫表中記錄數(shù)為268 915，為主機dp29-08重啟之前應(yīng)用寫入數(shù)據(jù)表的記錄數(shù)。

c.主機dp29-08重啟后，啟動數(shù)據(jù)庫gdcl1，復(fù)制關(guān)系自動建立，最終gdcl1中的數(shù)據(jù)由268 915變?yōu)?20 356，兩數(shù)據(jù)庫表數(shù)據(jù)完全一致。

（4）測試結(jié)果

從表5匯總情況可知，無論數(shù)據(jù)庫故障還是主機故障，應(yīng)用均無中斷，都可無縫切換到備機數(shù)據(jù)庫，繼續(xù)處理數(shù)據(jù)，并在故障恢復(fù)后，主備機數(shù)據(jù)庫可自動恢復(fù)復(fù)制關(guān)系，保證主備機數(shù)據(jù)庫表數(shù)據(jù)的完整性和一致性。該測試證明了Oracle TimesTen具有很好的高可用性，為業(yè)務(wù)處理的連續(xù)性提供了有力的保證。

表5 高可用性測試結(jié)果匯總表

4 結(jié)束語

通過本次測試，可以看到使用Oracle TimesTen內(nèi)存數(shù)據(jù)庫進行鐵路局股道現(xiàn)車數(shù)據(jù)同步的處理效率比Oracle數(shù)據(jù)庫本身有了質(zhì)的飛躍，處理一輪數(shù)據(jù)所需時間從12 min縮短到16 s，提升了約45倍，完全能夠?qū)崿F(xiàn)在總公司實時掌握車站車輛的現(xiàn)場情況。TimesTen的高可用性，更有力保證了業(yè)務(wù)處理的連續(xù)性和數(shù)據(jù)的完整性。同時，由于TimesTen支持SQL92并支持 Pro*C語言進行應(yīng)用開發(fā)，使得本次OCI測試應(yīng)用程序修改量不大，僅做了部分適應(yīng)性修改，程序主體基本沿用目前生產(chǎn)環(huán)境中的既有應(yīng)用，便于開發(fā)運維人員學(xué)習(xí)使用。

因此，使用Oracle TimesTen內(nèi)存數(shù)據(jù)庫提升股道現(xiàn)車同步應(yīng)用的性能是可行的解決方案。