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

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

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

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

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

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

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

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

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

1 當(dāng)前貨車追蹤應(yīng)用的主要問(wèn)題

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

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

2 解決貨車追蹤性能問(wèn)題的思路選擇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 POC測(cè)試環(huán)境及場(chǎng)景說(shuō)明

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

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

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

Oracle數(shù)據(jù)庫(kù)服務(wù)器為1臺(tái)Oracle SPARC T5-4小型機(jī)?；九渲茫海?）硬件：CPU核數(shù)：32核；MEM：32 GB；（2）軟件：OS： SunOS；Oracle 11g。

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

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

4.2.2 測(cè)試數(shù)據(jù)說(shuō)明

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

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

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

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

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

4.2.3 測(cè)試場(chǎng)景說(shuō)明

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

本次POC測(cè)試共設(shè)計(jì)了4種隨即讀場(chǎng)景，分別說(shuō)明如下：

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

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

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

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

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

（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=?

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

4.3 POC測(cè)試結(jié)果

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

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

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

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

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

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

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

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

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

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

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

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

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

說(shuō)明：表5測(cè)試結(jié)果是將千兆網(wǎng)帶寬占滿后的效果。可以看到性能達(dá)到30 769 TPS/s，而響應(yīng)時(shí)間僅僅是13 ms，CPU占用率才36%；也就是說(shuō)千兆網(wǎng)帶寬被占滿后服務(wù)器性能依然有很大的余量，如果使用萬(wàn)兆網(wǎng)進(jìn)行測(cè)試性能會(huì)更好。

4.3.5 POC測(cè)試總結(jié)

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

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

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

5 結(jié)束語(yǔ)

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

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

[1]蓋國(guó)強(qiáng). 內(nèi)存數(shù)據(jù)庫(kù)的基本原理與應(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

顏昌盛，高級(jí)工程師；范娟娟，高級(jí)工程師。