基于TimesTen內存數據庫提升股道現車同步應用性能的研究與測試

王鳳琳

（北京經緯信息技術有限公司，北京 100081）

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

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

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

1 主要問題及解決思路

1.1 主要問題

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

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

1.2 解決思路

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

2 Oracle TimesTen內存數據庫簡介

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

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

（1）能夠和Oracle數據庫做無縫集成，數據可以在TimesTen和Oracle直接實現實時雙向流動；

（2）TimesTen可以做成多節點并行提供服務的模式，數據在多個TimesTen之間直接實現實時或非實時的傳輸，進一步提高了系統的擴展性和可靠性；

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

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

3 Oracle TimesTen測試過程

3.1 測試目的

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

3.2 測試環境及步驟

3.2.1 軟硬件環境配置

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

3.2.2 測試數據說明

表1 軟硬件環境配置

圖1 系統邏輯架構

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

表2 測試數據集基本情況描述

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

圖2 股道現車文件格式

圖3 股道現車數據表結構

3.2.3 測試步驟

（1）將Oracle數據庫中基礎數據表的數據導入到內存數據庫表BGDCARA中。

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

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

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

（5）測試完畢，將內存數據庫數據表BGDCARA的數據導出到Oracle數據庫中的數據表。

3.3 測試場景及結果

3.3.1 性能測試

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

（1）測試準備

a.連接TimesTen數據庫gdcl1，比照集成平臺生產環境中股道車輛Oracle數據表結構和索引在TimesTen數據庫中新建數據表BGDCARA。

b.將Oracle數據庫中的數據導入TimesTen，記錄表行數。數據成功通過TimesTen緩存特性從Oracle數據庫導入，記錄數為626 610。

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

（2）OCI測試

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

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

（3）Java測試

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

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

（4）測試結果

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

3.3.2 高可用性測試

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

表3 數據表操作統計表

表4 處理效率匯總表

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

（1）測試準備

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

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

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

（2）高可用性測試之模擬內存數據庫故障

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

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

c.重新啟動數據庫gdcl1，復制關系自動建立，最終gdcl1中的數據由379 703變為620 356，兩數據庫表數據完全一致。

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

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

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

c.主機dp29-08重啟后，啟動數據庫gdcl1，復制關系自動建立，最終gdcl1中的數據由268 915變為620 356，兩數據庫表數據完全一致。

（4）測試結果

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

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

4 結束語

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

因此，使用Oracle TimesTen內存數據庫提升股道現車同步應用的性能是可行的解決方案。