王鳳琳

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

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

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

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

1 主要問題及解決思路

1.1 主要問題

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

全路已實施車站系統(tǒng)的車站約6 000多個，均需每30 min上報本站當前股道現(xiàn)車數(shù)據(jù)，具體包括車號、到達時間、到達股道、空重、始發(fā)站、終到站、貨物、車輛狀態(tài)等信息[1]；對于當前時間沒有任何車輛的車站，仍需上報股道現(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的時間差。時間差使得總公司與鐵路局數(shù)據(jù)存在較大的不一致性，而提高兩級數(shù)據(jù)一致性的首要問題是縮短數(shù)據(jù)同步時間間隔，提升數(shù)據(jù)處理能力。

1.2 解決思路

內(nèi)存數(shù)據(jù)庫技術具有更快的數(shù)據(jù)讀取速度，能夠大大提升數(shù)據(jù)處理效率，且該項技術在鐵路互聯(lián)網(wǎng)余票查詢[2]、鐵路貨車追蹤[3]等應用中已取得一定成效。經(jīng)過對目前主流的各類內(nèi)存數(shù)據(jù)庫產(chǎn)品進行對比和分析，基于與既有應用最大的兼容性，總公司運輸信息集成平臺股道現(xiàn)車同步應用選取了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)化的關系型數(shù)據(jù)庫，它為應用程序提供了即時響應性和非常高的吞吐量。Oracle TimesTen作為高速緩存或嵌入式數(shù)據(jù)庫部署在應用程序中，利用標準SQL 接口對完全位于物理內(nèi)存中的數(shù)據(jù)存儲進行操作，對于大規(guī)模的查詢應用非常有好處[4]。

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

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

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

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

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

3 Oracle TimesTen測試過程

3.1 測試目的

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

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

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

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

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

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

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

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

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

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

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

圖3 股道現(xiàn)車數(shù)據(jù)表結構

3.2.3 測試步驟

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

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

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

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

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

3.3 測試場景及結果

3.3.1 性能測試

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

（1）測試準備

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

b.將Oracle數(shù)據(jù)庫中的數(shù)據(jù)導入TimesTen，記錄表行數(shù)。數(shù)據(jù)成功通過TimesTen緩存特性從Oracle數(shù)據(jù)庫導入，記錄數(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í)行時間。為了保證測試的準確性，共進行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í)行時間。為了保證測試的準確性，共進行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í)行時間。為了保證測試的準確性，共進行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í)行時間。為了保證測試的準確性，共進行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）測試結果

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

3.3.2 高可用性測試

本文高可用性測試采用主從方式，即主機工作，備機處于監(jiān)控準備狀況，當主機宕機時，備機接管主機的一切工作，待主機恢復正常后，按使用者的設定以自動或手動方式將服務切換到主機上運行，數(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è)務連續(xù)性的支持。

（1）測試準備

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

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

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

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

a.啟動應用，默認連接位于主機dp29-08的數(shù)據(jù)庫gdcl1，進程運行正常，實時往數(shù)據(jù)表中寫入記錄。模擬內(nèi)存數(shù)據(jù)庫故障，手動Kill數(shù)據(jù)庫守護進程，應用立即檢測到數(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故障之前應用寫入數(shù)據(jù)表的記錄數(shù)。

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

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

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

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

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

（4）測試結果

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

表5 高可用性測試結果匯總表

4 結束語

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

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