基于內(nèi)存數(shù)據(jù)庫提升鐵路貨車追蹤應(yīng)用性能的研究

顏昌盛，范娟娟，海 洋，高明星

（中國鐵路信息技術(shù)中心，北京 100844）

基于內(nèi)存數(shù)據(jù)庫提升鐵路貨車追蹤應(yīng)用性能的研究

顏昌盛，范娟娟，海 洋，高明星

（中國鐵路信息技術(shù)中心，北京 100844）

介紹鐵路貨車追蹤應(yīng)用的背景及當前存在的性能問題，針對實際情況提出利用內(nèi)存數(shù)據(jù)庫解決性能問題的思路，并進行了POC測試。測試結(jié)果證明，采用內(nèi)存數(shù)據(jù)庫解決當前貨車追蹤應(yīng)用面臨的性能問題，無論是從前期投入還是從后期維護角度看，都具有可行性。

內(nèi)存數(shù)據(jù)庫；貨物運輸；貨車追蹤

鐵路運輸管理信息系統(tǒng)（TMIS，Transportation Management Information System）是中國鐵路第一個覆蓋全路的實時信息系統(tǒng)，它通過計算機網(wǎng)絡(luò)，從全路6 000多個站的2 000多個主要站點中，實時收集列車、機車、車輛、集裝箱以及承運貨物的動態(tài)信息，對列車、車輛、集裝箱和貨物進行節(jié)點式追蹤管理，實現(xiàn)貨票、確報、編組站、區(qū)段站、貨運站、貨運營銷以及運輸調(diào)度等的信息化管理。

實現(xiàn)貨車追蹤主要是為了解決貨車管理的“黑洞”問題，以此提高運輸組織的效率、降低運營管理的成本，同時促進提高運輸服務(wù)的質(zhì)量、提升鐵路貨運的市場競爭力等，其意義之重大不言而喻。

1 當前貨車追蹤應(yīng)用的主要問題

當前貨車追蹤應(yīng)用所需的原始數(shù)據(jù)采集于基層站段，并由站段向鐵路局和鐵路總公司逐級上報，最后在鐵路總公司集中綜合處理后形成全路完整的貨車追蹤數(shù)據(jù)庫。貨車追蹤應(yīng)用的后臺數(shù)據(jù)庫采用了業(yè)界主流的Oracle數(shù)據(jù)庫，處理平臺采用了小型機作數(shù)據(jù)庫服務(wù)器外加SAN存儲的典型架構(gòu)。全路目前共有80多萬輛貨車，貨車的狀態(tài)和位置處于不斷變化之中，每一次變化都要形成一條軌跡記錄，這就決定了當前貨車追蹤應(yīng)用的主要特點為數(shù)據(jù)規(guī)模龐大、后臺綜合處理較復(fù)雜且處理量大，同時用戶對應(yīng)用的可用性提出了非常高的要求。

當前貨車追蹤應(yīng)用的主要問題是性能問題。（1）隨著貨車追蹤密度的不斷加大和用戶對數(shù)據(jù)的實時性和準確性要求越來越高，后臺數(shù)據(jù)庫處理系統(tǒng)的能力已漸趨飽和、亟待擴能；（2）后臺數(shù)據(jù)庫處理系統(tǒng)因技術(shù)架構(gòu)問題，難以簡單橫向擴展能力，同時受資金投入和建設(shè)周期等多種因素制約，縱向擴展能力也難以一蹴而就；（3）針對當前貨車追蹤應(yīng)用的性能問題已經(jīng)進行了多輪優(yōu)化，在保持現(xiàn)有軟硬件架構(gòu)不變的情況下，進一步提升性能的潛力非常有限。正因為貨車追蹤應(yīng)用的后臺數(shù)據(jù)庫處理系統(tǒng)當前存在性能問題，盡管各種用戶對貨車追蹤數(shù)據(jù)庫的訪問需求量很大，但目前僅針對有限的用戶開放了查詢訪問權(quán)限，應(yīng)用效果和價值受到了一定程度的制約。

2 解決貨車追蹤性能問題的思路選擇

面對日趨緊張的貨車追蹤數(shù)據(jù)庫系統(tǒng)的性能問題和不斷增長的用戶對貨車追蹤數(shù)據(jù)庫的大量查詢訪問需求之間的矛盾，要想進一步開放貨車追蹤數(shù)據(jù)庫的查詢訪問權(quán)限，更好地發(fā)揮應(yīng)用的效果和價值，目前解決問題主要有兩種思路：（1）保持原有系統(tǒng)整體架構(gòu)不變，通過使用一體機、閃存等新技術(shù)產(chǎn)品大幅提升硬件設(shè)備能力。（2）另辟蹊徑，采用全新技術(shù)對數(shù)據(jù)處理架構(gòu)進行改造優(yōu)化，以大幅提升系統(tǒng)整體處理能力。

貨車追蹤應(yīng)用的現(xiàn)有架構(gòu)是基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的，雖曾對應(yīng)用做過多次優(yōu)化但仍然不能很好地滿足現(xiàn)實要求。傳統(tǒng)關(guān)系型數(shù)據(jù)庫的主要瓶頸在I/O，尤其是磁盤的I/O對性能的提升限制最大。因此，要想徹底解決問題，摒棄原有架構(gòu)，采用業(yè)界日漸成熟的內(nèi)存數(shù)據(jù)庫技術(shù)，將數(shù)據(jù)挪到內(nèi)存以便從根本上解決I/O瓶頸問題，不失為一種良策。

上述第1種思路涉及到投入產(chǎn)出的綜合考慮等問題，加上目前機房、電源都比較緊張，難以落地；第2種思路硬件投入相對較少，經(jīng)過評估我們認為學(xué)習(xí)成本和實現(xiàn)難度并不大，相對容易落地。下文將基于上述第2種思路，研究解決貨車追蹤應(yīng)用的性能問題。

3 內(nèi)存數(shù)據(jù)庫的發(fā)展及應(yīng)用情況

內(nèi)存數(shù)據(jù)庫，顧名思義就是將數(shù)據(jù)放在內(nèi)存中直接進行管理和操作的數(shù)據(jù)庫。內(nèi)存數(shù)據(jù)庫拋棄了磁盤數(shù)據(jù)管理的傳統(tǒng)方式，基于全部數(shù)據(jù)都在內(nèi)存中重新設(shè)計了體系結(jié)構(gòu)，并且在數(shù)據(jù)緩存、快速算法、并行操作方面也進行了相應(yīng)的改進，所以數(shù)據(jù)處理速度比傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)處理速度要快很多，能夠極大地提高應(yīng)用的性能。

內(nèi)存數(shù)據(jù)庫的發(fā)展史和數(shù)據(jù)庫的發(fā)展史幾乎一樣長。1969年IBM公司研制了世界上最早的數(shù)據(jù)庫管理系統(tǒng)—基于層次模型的數(shù)據(jù)庫管理系統(tǒng)IMS，并作為商品化軟件投入市場。在設(shè)計IMS時，IBM考慮到基于內(nèi)存的數(shù)據(jù)管理方法，相應(yīng)推出了IMS/ VS Fast Path。Fast Path是一個支持內(nèi)存駐留數(shù)據(jù)的商業(yè)化數(shù)據(jù)庫軟件，同時也可以很好地支持磁盤駐留數(shù)據(jù)。近年來內(nèi)存數(shù)據(jù)庫的發(fā)展更是突飛猛進，例如出現(xiàn)了eXtremeDB、Oracle TimesTen、SAP HANA、Pivotal GemFire等為代表的一些優(yōu)秀產(chǎn)品，其中GemFire已在12306 網(wǎng)站中得到了很好的應(yīng)用。

GemFire目前在業(yè)界取得的認可主要得益于它在以下幾個方面的技術(shù)優(yōu)勢：

（1）GemFire支持海量并發(fā)請求的能力超群。它可以把客戶端的一個查詢或是計算請求分發(fā)給各個節(jié)點，各個節(jié)點都查詢或是計算本節(jié)點的數(shù)據(jù)，通過協(xié)調(diào)節(jié)點對各個節(jié)點返回來的數(shù)據(jù)進行匯總，再返回給客戶端。通過并行計算方式，GemFire可以持續(xù)地橫向擴展，即增加機器就可以提高支持的并發(fā)量。

（2）GemFire采用了標準的TCP/IP協(xié)議，對于同一網(wǎng)絡(luò)下的其它應(yīng)用沒有影響。而有些同類產(chǎn)品采用了私有的TCMP協(xié)議，要求交換機支持UDP廣播協(xié)議，對其它應(yīng)用可能會產(chǎn)生影響。

（3）GemFire支持大內(nèi)存，最大實測過支持1 TB～2 TB的內(nèi)存數(shù)據(jù)。而其它同類產(chǎn)品一般都是小內(nèi)存，一個節(jié)點只支持1 GB～2 GB內(nèi)存。如果要緩存的數(shù)據(jù)規(guī)模較大，則需要部署大量的節(jié)點。即降低了硬件內(nèi)存的利用率，也增加了采購的成本，增加了管理的復(fù)雜性，比較容易引起網(wǎng)絡(luò)風(fēng)暴，同時也會對整個集群的穩(wěn)定性產(chǎn)生影響。

（4）GemFire提供C++/.net的客戶端。其它同類產(chǎn)品對C++/.net應(yīng)用支持欠佳。

（5）GemFire可以把內(nèi)存數(shù)據(jù)持久化在本地應(yīng)用，同步或是異步均可以。而很多同類產(chǎn)品不支持把數(shù)據(jù)持久化在本地硬盤，這樣若計算機異常斷電后可能會導(dǎo)致數(shù)據(jù)丟失。

因此，下文將基于Gemfire內(nèi)存數(shù)據(jù)庫產(chǎn)品，研究解決貨車追蹤應(yīng)用的性能問題。

4 解決貨車追蹤應(yīng)用性能的POC測試研究

4.1 POC測試總體方案設(shè)計

本次POC測試的主要目的是評估GemFire和Oracle兩種解決方案在大并發(fā)環(huán)境下的性能差異。本次POC測試方案的邏輯架構(gòu)示意圖如圖1所示。

圖1 貨車追蹤應(yīng)用POC測試方案邏輯架構(gòu)示意圖

圖1中，虛線左邊代表Gemfire系統(tǒng)環(huán)境，虛線右邊代表同一局域網(wǎng)下的Oracle系統(tǒng)環(huán)境。

在本POC測試方案中，通過壓力測試工具JMeter分別向Gemfire和Oracle兩套系統(tǒng)環(huán)境發(fā)送查詢請求。查詢接口分為以下幾類：（1）采用Gemfire函數(shù)實現(xiàn)查詢，JMeter調(diào)用Gemfire提供的FunctionServic,執(zhí)行車輛軌跡信息查詢的函數(shù)；（2）采用Gemfire OQL實現(xiàn)查詢，JMeter調(diào)用Gemfire提供的QueryService執(zhí)行車輛軌跡信息查詢的OQL（Object Query Language）；（3）采用JDBC實現(xiàn)查詢Oracle，JMeter采用JDBC接口查詢Oracle，實現(xiàn)車輛軌跡信息查詢。

關(guān)于圖1中的各個組件及其作用簡單說明如下：（1）JMeter，是基于Java的壓力測試工具。JMeter在測試中模擬對 Gemfire和Oracle系統(tǒng)發(fā)起壓力請求，在不同壓力類別下測試它們的強度并分析整體性能；（2）FunctionService，是Gemfire提供的函數(shù)服務(wù)接口，開發(fā)人員通過開發(fā)Gemfire的函數(shù)服務(wù)接口，可以實現(xiàn)復(fù)雜的業(yè)務(wù)行為。在Gemfire服務(wù)端部署了自定義的函數(shù)服務(wù)后，在Gemfire客戶端就可以動態(tài)調(diào)用這些函數(shù)；（3）QueryService，是Gemfire執(zhí)行OQL查詢語言的服務(wù)接口；OQL是Gemfire提供的類似SQL語言的接口。QueryService是執(zhí)行OQL的入口，開發(fā)人員采用Gemfire Client API獲取QueryService服務(wù)，然后通過它發(fā)送OQL給Gemfire集群；Gemfire集群接受到OQL后會解析OQL，然后把解析后的執(zhí)行計劃發(fā)送到集群的每個節(jié)點執(zhí)行并最終匯總結(jié)果給客戶端；（4）數(shù)據(jù)節(jié)點（CacheService），是Gemfire緩存集群的節(jié)點，負責(zé)存儲數(shù)據(jù)，并對外提供緩存操作的接口，包括FunctionService和QueryService；（5）JDBC，是Java語言中用來規(guī)范客戶端程序如何來訪問數(shù)據(jù)庫的應(yīng)用程序接口，提供諸如查詢和更新數(shù)據(jù)庫中數(shù)據(jù)的方法。采用它實現(xiàn)對Oracle關(guān)系型數(shù)據(jù)庫的訪問。

4.2 POC測試環(huán)境及場景說明

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

在圖1中，整個測試環(huán)境由6臺物理PC服務(wù)器、1臺小型機和1臺筆記本組成。在6臺PC服務(wù)器上部署 GemFire集群，在1臺小型機上部署Oracle數(shù)據(jù)庫。筆記本作為測試客戶端，能分別連接Gemfire集群和 Oracle數(shù)據(jù)庫系統(tǒng)進行壓力測試。

6臺PC服務(wù)器的配置均相同?；九渲茫海?）硬件：CPU： Intel Xeon CPU；CPU核數(shù)：16核；MEM：128 GB；（2）軟件：OS：Redhat 6.4；Gemfire：GemFire_702。

Oracle數(shù)據(jù)庫服務(wù)器為1臺Oracle SPARC T5-4小型機。基本配置：（1）硬件：CPU核數(shù)：32核；MEM：32 GB；（2）軟件：OS： SunOS；Oracle 11g。

JMeter測試客戶端為1臺筆記本?；九渲茫篊PU：Intel Core i7-3520M；MEM：16 GB。

服務(wù)器端網(wǎng)絡(luò)為開發(fā)測試環(huán)境區(qū)域的局域網(wǎng)，Gemfire集群和Oracle數(shù)據(jù)庫系統(tǒng)之間帶寬是1 000 Mb/s。JMeter測試客戶端部署在辦公區(qū)時，與Gemfire集群和Oracle數(shù)據(jù)庫系統(tǒng)之間的帶寬是100 Mb/s，部署在服務(wù)器端時，帶寬可以達到1 000 Mb/s。

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

在Oracle測試數(shù)據(jù)庫中創(chuàng)建貨車追蹤軌跡表（gcarevta），字段與貨車追蹤生產(chǎn)系統(tǒng)保持一致。表結(jié)構(gòu)如表1所示。

在Gemfire集群中創(chuàng)建內(nèi)存表對象，字段與Oracle數(shù)據(jù)庫的表結(jié)構(gòu)保持一致。

從貨車追蹤軌跡表（gcarevta）的數(shù)據(jù)備份中選擇了15天的歷史數(shù)據(jù)，共40 107 420條記錄，分別

導(dǎo)入Oracle 測試數(shù)據(jù)庫和Gemfire 集群系統(tǒng)。其中導(dǎo)入Gemfire 集群耗時35 min，內(nèi)存占用460 GB 左右（數(shù)據(jù)冗余1 份，共2 份）。

表1 貨車追蹤軌跡表結(jié)構(gòu)

4.2.3 測試場景說明

本次POC測試使用隨機讀測試場景，從1個數(shù)據(jù)節(jié)點開始保持測試交易一直執(zhí)行，逐步增加至6個數(shù)據(jù)節(jié)點并分別進行如下驗證：（1）增加數(shù)據(jù)節(jié)點（Cache server）后，交易繼續(xù)保持執(zhí)行，觀察處理能力是否增加；（2）增加數(shù)據(jù)節(jié)點（Cache server）后，觀察緩存集群中的數(shù)據(jù)是否會自動重新分布，且數(shù)據(jù)不丟失。

本次POC測試共設(shè)計了4種隨即讀場景，分別說明如下：

（1）GemfireOQL。此場景是指壓力測試客戶端通過Gemfire OQL編程接口實現(xiàn)查詢車輛軌跡業(yè)務(wù)。OQL是Gemfire提供查詢緩存的高級接口，用戶可以采用類似SQL的語句來查詢緩存中的數(shù)據(jù)。

（2）GemfireFun。此場景是指壓力測試客戶端通過Gemfire的Function編程接口實現(xiàn)車輛軌跡查詢業(yè)務(wù)。Function是Gemfire為開發(fā)人員提供的編程接口，用戶可以通過它實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。

（3）Oracle。此場景是指壓力測試客戶端通過SQL語句訪問Oracle數(shù)據(jù)庫實現(xiàn)車輛軌跡查詢業(yè)務(wù)。此場景主要是用于與其它3種場景進行性能對比評估。

（4）GemfireFun單獨測試。此場景與上面介紹的GemfireFun場景基本相同，不過測試環(huán)境做了微調(diào)，即將壓力測試客戶端與Gemfire集群部署在相同網(wǎng)段，因此壓力機本身的網(wǎng)絡(luò)帶寬可以達到1 000 Mb/s，避免因100 Mb/s網(wǎng)絡(luò)帶寬限制導(dǎo)致不能進一步加壓的問題。GemfireFun單獨測試時為400并發(fā)用戶。

在前面3種測試場景中，因壓力測試的客戶端部署在辦公網(wǎng)，它與Gemfire/Oracle系統(tǒng)之間的帶寬只有100 Mb/s。為了避免網(wǎng)絡(luò)帶寬不足限制對系統(tǒng)性能的充分測試和評估，在執(zhí)行Fun/OQL/SQL查詢測試時僅選取返回5個字段，分別如下：

（1）Fun：返回的參數(shù)是：CAR_NO#RPT_ DATE#TRAIN_NO#CUR_STN_NAME#

DEST_STN_NAME；查詢條件是CAR_NO和RPT_DATE。

（2）OQL：select CAR_NO,RPT_DATE,TRAIN_ NO,CUR_STN_NAME,

DEST_STN_NAME from /gcarevta where CAR_ NO=? And

RPT_DATE=?

（3）SQL：select CAR_NO,RPT_DATE,TRAIN_ NO,CUR_STN_NAME,

DEST_STN_NAME from gcarevta where CAR_ NO=? And

RPT_DATE=?

其中對CAR_NO和RPT_DATE，從測試的原始數(shù)據(jù)文件中抽取了500萬不重復(fù)的鍵值對，并且保證都能查詢到數(shù)據(jù)。

4.3 POC測試結(jié)果

POC測試過程是從測試客戶端向目標端發(fā)起請求，并接收響應(yīng)目標端返回的數(shù)據(jù)。為評估測試效果，選取了5項技術(shù)指標，分別是吞吐量（目標端每秒處理的請求數(shù)）、響應(yīng)時間（目標端處理每次請求的平均時間）、CPU（目標端服務(wù)器的CPU平均使用率）、測試端網(wǎng)絡(luò)帶寬（測試機的網(wǎng)卡帶寬）、Gemfire/ Oracle端網(wǎng)絡(luò)帶寬（目標端服務(wù)器的網(wǎng)卡帶寬）。本次POC測試，選擇了100、200、400這3種不同的并發(fā)用戶規(guī)模，針對每種場景逐一進行測試。詳細測試結(jié)果如下。

4.3.1 100并發(fā)用戶對比測試結(jié)果

表2 100并發(fā)用戶對比測試結(jié)果

說明：表2測試結(jié)果基于相同的查詢條件，100個并發(fā)用戶。Oracle SQL查詢場景下的響應(yīng)時間是123 ms；使用Gemfire OQL查詢場景下的響應(yīng)時間為32 ms；而使用 GemfireFun即查詢接口場景下的響應(yīng)時間可以達到驚人的7 ms。這是因為GemfireFun 沒有象OQL查詢語言那樣有語句解析過程且對查詢進行了深度優(yōu)化，因此速度更快。下面200和400并發(fā)用戶的情況與此類似，都是Gemfire集群比Oracle數(shù)據(jù)庫系統(tǒng)性能優(yōu)異。

4.3.2 200并發(fā)用戶對比測試結(jié)果

200并發(fā)用戶對比測試結(jié)果如表3所示。

表3 200并發(fā)用戶對比測試結(jié)果

4.3.3 400并發(fā)用戶對比測試結(jié)果

400并發(fā)用戶對比測試結(jié)果如表4所示。

表4 400并發(fā)用戶對比測試結(jié)果

4.3.4 GemfireFun 400并發(fā)用戶單獨測試結(jié)果

因測試客戶端開始時部署在辦公網(wǎng)進行測試，網(wǎng)絡(luò)帶寬受限，當測試機加壓后網(wǎng)絡(luò)出口帶寬被占滿，無法對GemFire集群繼續(xù)加壓。為了測試出GemFire的真實性能，將測試機調(diào)整部署在與GemFire相同的網(wǎng)段，測試結(jié)果如表5所示。

表5 400并發(fā)用戶單獨測試結(jié)果

說明：表5測試結(jié)果是將千兆網(wǎng)帶寬占滿后的效果?？梢钥吹叫阅苓_到30 769 TPS/s，而響應(yīng)時間僅僅是13 ms，CPU占用率才36%；也就是說千兆網(wǎng)帶寬被占滿后服務(wù)器性能依然有很大的余量，如果使用萬兆網(wǎng)進行測試性能會更好。

4.3.5 POC測試總結(jié)

從本次POC測試結(jié)果看，Gemfire內(nèi)存數(shù)據(jù)庫集群系統(tǒng)的性能要遠高于傳統(tǒng)的Oracle數(shù)據(jù)庫系統(tǒng)。

當壓力測試客戶端部署在僅具有百兆接入能力的辦公網(wǎng)時，在Gemfire OQL場景下集群系統(tǒng)的性能比Oracle數(shù)據(jù)庫系統(tǒng)提高1倍以上，在GemfireFun場景下其性能提高6倍以上。GemfireOQL測試場景的性能瓶頸是Gemfire集群的服務(wù)器CPU使用率，當在400并發(fā)用戶下已達到90%；而GemfireFun測試場景的性能瓶頸是測試客戶端與Gemfire集群之間的網(wǎng)絡(luò)帶寬，在3種并發(fā)用戶場景下均達到10 Mbit/s（百兆帶寬）。

當壓力測試客戶端部署在與Gemfire集群相同的網(wǎng)段后，基本消除了壓力機的帶寬瓶頸。在GemfireFun場景下集群系統(tǒng)的性能比Oracle數(shù)據(jù)庫系統(tǒng)提高15倍左右，并且最后性能瓶頸不是Gemfire集群本身，而是測試客戶端使用的網(wǎng)絡(luò)帶寬已達到限定值（千兆帶寬）。

5 結(jié)束語

通過本次POC測試，看到 GemFire內(nèi)存數(shù)據(jù)庫集群系統(tǒng)的性能比Oracle數(shù)據(jù)庫要高出15倍左右（千兆網(wǎng)環(huán)境下），如果是萬兆網(wǎng)環(huán)境，性能提升會更加可觀。而且 GemFire集群的運行環(huán)境是基于X86服務(wù)器的Linux環(huán)境，且不需要共享存儲，因為它性能的提升完全依賴于分布式運算的強大處理能力，而不依賴于高性能共享存儲。這與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫提升性能很大程度上依賴于存儲性能的提升完全不同。本次POC測試的代碼開發(fā)與調(diào)試不到兩周，經(jīng)過評估，結(jié)論是：使用 GemFire作為后端數(shù)據(jù)庫，涉及到的修改貨車追蹤應(yīng)用的代碼工作量不大；GemFire提供了與 SQL 語句類似的查詢語言O(shè)QL，降低了研發(fā)人員與后期運維人員的學(xué)習(xí)成本。

因此，無論從前期投入，還是從全生命周期的效益來看，使用GemFire內(nèi)存數(shù)據(jù)庫改善貨車軌跡追蹤應(yīng)用的性能都是非?？扇〉慕鉀Q方案。

[1]蓋國強. 內(nèi)存數(shù)據(jù)庫的基本原理與應(yīng)用[EB/OL]. http:// www.eygle.com/digest/2011/11/memdb_timesten_altibase. html.2011.

責(zé)任編輯 方 圓

Application performance of railway freight car tracking based on in-memory database

YAN Changsheng, FAN Juanjuan, HAI Yang, GAO Mingxing
( China Railway Information Technology Center, Beijing 100844, China )

This paper introduced the background of the railway freight car tracking application and its current performance problem. Based on a comprehensive analysis, a totally new method of using the in-memory database was put forward to solved the problem, the POC test was done afterwards. The test result proved that it was practicable to use the in-memory database to improve performance and reduce cost, from the point of new, whether the early stage investment or the later stage of maintenance, the method was feasible.

in-memory database (IMDB); freight traff i c; freight car tracking

U294∶TP39

A

1005-8451（2015）06-0026-05

2015-01-23

顏昌盛，高級工程師；范娟娟，高級工程師。