基于內存數據庫提升鐵路貨車追蹤應用性能的研究

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

（中國鐵路信息技術中心，北京 100844）

基于內存數據庫提升鐵路貨車追蹤應用性能的研究

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

（中國鐵路信息技術中心，北京 100844）

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

內存數據庫；貨物運輸；貨車追蹤

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

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

1 當前貨車追蹤應用的主要問題

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

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

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

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

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

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

3 內存數據庫的發展及應用情況

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

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

GemFire目前在業界取得的認可主要得益于它在以下幾個方面的技術優勢：

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

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

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

（4）GemFire提供C++/.net的客戶端。其它同類產品對C++/.net應用支持欠佳。

（5）GemFire可以把內存數據持久化在本地應用，同步或是異步均可以。而很多同類產品不支持把數據持久化在本地硬盤，這樣若計算機異常斷電后可能會導致數據丟失。

因此，下文將基于Gemfire內存數據庫產品，研究解決貨車追蹤應用的性能問題。

4 解決貨車追蹤應用性能的POC測試研究

4.1 POC測試總體方案設計

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

圖1 貨車追蹤應用POC測試方案邏輯架構示意圖

圖1中，虛線左邊代表Gemfire系統環境，虛線右邊代表同一局域網下的Oracle系統環境。

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

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

4.2 POC測試環境及場景說明

4.2.1 軟硬件環境配置

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

6臺PC服務器的配置均相同。基本配置：（1）硬件：CPU： Intel Xeon CPU；CPU核數：16核；MEM：128 GB；（2）軟件：OS：Redhat 6.4；Gemfire：GemFire_702。

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

JMeter測試客戶端為1臺筆記本。基本配置：CPU：Intel Core i7-3520M；MEM：16 GB。

服務器端網絡為開發測試環境區域的局域網，Gemfire集群和Oracle數據庫系統之間帶寬是1 000 Mb/s。JMeter測試客戶端部署在辦公區時，與Gemfire集群和Oracle數據庫系統之間的帶寬是100 Mb/s，部署在服務器端時，帶寬可以達到1 000 Mb/s。

4.2.2 測試數據說明

在Oracle測試數據庫中創建貨車追蹤軌跡表（gcarevta），字段與貨車追蹤生產系統保持一致。表結構如表1所示。

在Gemfire集群中創建內存表對象，字段與Oracle數據庫的表結構保持一致。

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

導入Oracle 測試數據庫和Gemfire 集群系統。其中導入Gemfire 集群耗時35 min，內存占用460 GB 左右（數據冗余1 份，共2 份）。

表1 貨車追蹤軌跡表結構

4.2.3 測試場景說明

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

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

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

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

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

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

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

（1）Fun：返回的參數是：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，從測試的原始數據文件中抽取了500萬不重復的鍵值對，并且保證都能查詢到數據。

4.3 POC測試結果

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

4.3.1 100并發用戶對比測試結果

表2 100并發用戶對比測試結果

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

4.3.2 200并發用戶對比測試結果

200并發用戶對比測試結果如表3所示。

表3 200并發用戶對比測試結果

4.3.3 400并發用戶對比測試結果

400并發用戶對比測試結果如表4所示。

表4 400并發用戶對比測試結果

4.3.4 GemfireFun 400并發用戶單獨測試結果

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

表5 400并發用戶單獨測試結果

說明：表5測試結果是將千兆網帶寬占滿后的效果。可以看到性能達到30 769 TPS/s，而響應時間僅僅是13 ms，CPU占用率才36%；也就是說千兆網帶寬被占滿后服務器性能依然有很大的余量，如果使用萬兆網進行測試性能會更好。

4.3.5 POC測試總結

從本次POC測試結果看，Gemfire內存數據庫集群系統的性能要遠高于傳統的Oracle數據庫系統。

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

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

5 結束語

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

因此，無論從前期投入，還是從全生命周期的效益來看，使用GemFire內存數據庫改善貨車軌跡追蹤應用的性能都是非常可取的解決方案。

[1]蓋國強. 內存數據庫的基本原理與應用[EB/OL]. http:// www.eygle.com/digest/2011/11/memdb_timesten_altibase. html.2011.

責任編輯 方 圓

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

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