基于MongoDB物流流量研究性能優(yōu)化探究

1、基于mongodb物流流量研究性能優(yōu)化探究摘要：mongodb是一個(gè)開源的文檔類型的，基于 分布式文件存儲的數(shù)據(jù)庫，其在數(shù)據(jù)存儲與分析方面較傳統(tǒng) 關(guān)系型數(shù)據(jù)庫有明顯優(yōu)勢。該文在物流訂單軌跡流量分析方 面進(jìn)行了探索與相關(guān)實(shí)驗(yàn)，證明了 mongodb在此類型大數(shù)據(jù) 處理方面具有優(yōu)勢。關(guān)鍵詞：mongodb；物流流量分析；關(guān)系型數(shù)據(jù)庫；大 數(shù)據(jù)；性能優(yōu)化；集群；分片中圖分類號：tp311文獻(xiàn)標(biāo)識碼：a文章編號：1009-3044 (2013) 33-7627-04目前隨著網(wǎng)絡(luò)信息化、電子商務(wù)和物流業(yè)的爆炸式發(fā) 展，我們正加速進(jìn)入數(shù)據(jù)快速增長的'大數(shù)據(jù)”時(shí)代，“大 數(shù)據(jù)”已經(jīng)在各方面對人們的生

2、活帶來深刻的影響。而傳統(tǒng) 的數(shù)據(jù)存儲與分析技術(shù)在“大數(shù)據(jù)”時(shí)代也顯得力不從心， “大數(shù)據(jù)”給it產(chǎn)業(yè)帶來了新的挑戰(zhàn)和機(jī)遇。1概述目前物流行業(yè)蓬勃發(fā)展，各大物流企業(yè)在熱點(diǎn)時(shí)間段頻 頻爆倉，大量快件滯留在始發(fā)站和中轉(zhuǎn)站，給物流企業(yè)帶來 了非常大的管理壓力，所以物流訂單流量進(jìn)行實(shí)時(shí)分析和非 實(shí)時(shí)統(tǒng)計(jì)分析成為物流企業(yè)規(guī)劃物流運(yùn)力和倉儲能力重要 決策數(shù)據(jù)。而目前物流企業(yè)訂單管理系統(tǒng)大部分基于傳統(tǒng)關(guān) 系型數(shù)據(jù)庫，這對于訂單跟蹤目前還能勝任，但是對于海量 的數(shù)據(jù)統(tǒng)計(jì)分析則顯得力不從心。1.1問題描述一方面，物流企業(yè)的訂單管理系統(tǒng)目前主要使用傳統(tǒng)關(guān) 系型數(shù)據(jù)庫如oracle, sql server等。在數(shù)據(jù)庫

3、中存放訂 單配送的主要數(shù)據(jù)包括以下兩個(gè)方面：1）訂單的基本信息，包括訂單編號、發(fā)件人信息、收 件人信息、發(fā)貨時(shí)間、發(fā)貨地點(diǎn)、收貨地點(diǎn)等信息。2）訂單配送過程的軌跡信息，在關(guān)系型數(shù)據(jù)庫中會形 成模式如（單號，出發(fā)地，到達(dá)地，出發(fā)時(shí)間，到達(dá)時(shí)間） 的多條記錄。例如一件物品從上海發(fā)往合肥客戶，經(jīng)由軌跡 信息就是上海一昆山南京合肥。會形成（id1,上海， 昆山,timel, time2）, （id1,昆山，南京，time3, time4）,（id1,南京，合肥，time5, time6）三條記錄。由于訂單數(shù)目巨大，形成的軌跡信息往往是數(shù)以億計(jì)， 甚至更多。對于統(tǒng)計(jì)在某段時(shí)間內(nèi)容從地點(diǎn)a到地點(diǎn)b的總 訂

4、單數(shù)等信息往往要等待很長時(shí)間，甚至對于更為復(fù)雜的統(tǒng) 計(jì)分析講無法給出查詢結(jié)果。另一方面，目前現(xiàn)有系統(tǒng)已普遍使用，不適合更換現(xiàn)有 數(shù)據(jù)庫，我們需要在不更換現(xiàn)有數(shù)據(jù)庫的基礎(chǔ)上提供相應(yīng)的 統(tǒng)計(jì)分析查詢服務(wù)?；谝陨蟽煞矫鎲栴}，我們提出基于mongodb的物流流 量分析性能優(yōu)化方案。1.2相關(guān)技術(shù)mongodb是一個(gè)開源的文檔類型的，基于分布式文件存 儲的數(shù)據(jù)庫。旨在為web應(yīng)用提供可擴(kuò)展的高性能數(shù)據(jù)存儲 解決方案。mongodb支持松散式數(shù)據(jù)結(jié)構(gòu)bson格式，可以存 儲復(fù)雜的數(shù)據(jù)類型。可貴的是它的查詢語言非常強(qiáng)大，可以 適用于多種查詢場合。mongodb具有面向集合存儲、高可用、高性能的特點(diǎn)， 且具

5、備通過shard模式支持橫向擴(kuò)展性，為大數(shù)據(jù)存儲與處 理奠定了基礎(chǔ)。2方案設(shè)計(jì)2.1處理流程從圖1我們可以看出方案處理場景主要包含三部分：1）系統(tǒng)接入時(shí)從原oracle數(shù)據(jù)庫全量批量式導(dǎo)入訂單 及其軌跡信息進(jìn)入分布式mongodb數(shù)據(jù)庫。2）物流訂單入庫、出庫、中轉(zhuǎn)及配送的軌跡信息更新 時(shí)增量記錄于原oracle數(shù)據(jù)庫及mongode數(shù)據(jù)庫。3）物流流量分析人員基于mongodb數(shù)據(jù)庫內(nèi)數(shù)據(jù)實(shí)時(shí) 統(tǒng)計(jì)分析流量數(shù)據(jù)。以上使用場景對mongodb提出了具有良好數(shù)據(jù)寫入性能 和數(shù)據(jù)查詢新能的要求。另一方面該使用場景對于數(shù)據(jù)的高 可靠性沒有較高要求，系統(tǒng)的寫入和查詢性能更為關(guān)鍵。2. 2mongodb

6、的數(shù)據(jù)寫入性能分析mongodb的數(shù)據(jù)寫入性能測試主要包含以下幾個(gè)場景模 式，包含單機(jī)與集群分片的性能比較。2. 2. 1正常模式數(shù)據(jù)寫入2. 2.2批量模式數(shù)據(jù)寫入2. 2. 3安全模式數(shù)據(jù)寫入2. 2.4數(shù)據(jù)寫入模式的選擇通過上述3種寫入模式的分析我們可以看出，mongodb 的正常模式寫入和批量模式寫入具有較好的寫入性能，但是 批量模式并沒有預(yù)期上比正常模式有更高的性能，主要原因 在于寫鎖的存在，導(dǎo)致了并沒有較好的性能提升。而安全模 式為了保證數(shù)據(jù)的不丟失性，寫入性能較差，考慮到我們的 使用場景對于單條數(shù)據(jù)沒有較高的數(shù)據(jù)可靠性要求，所以我 們采用mongodb的正常模式作為系統(tǒng)實(shí)現(xiàn)方案。

7、另一方面我們的訂單數(shù)據(jù)是海量的且持續(xù)增長的，考慮 到單機(jī)存在不能滿足數(shù)據(jù)存儲的要求，我們采用集群式的分 片模式，這樣在后期數(shù)據(jù)增長的情況下可以做到平滑擴(kuò)容。3性能優(yōu)化方案效果分析基于以上方案我們設(shè)計(jì)實(shí)現(xiàn)了該方案，并針對千萬級訂 單、億級訂單軌跡信息進(jìn)行了系統(tǒng)測試，表明基于mongodb 的流量分析較傳統(tǒng)oracle數(shù)據(jù)庫有著更好地查詢與統(tǒng)計(jì)性 能達(dá)到了我們預(yù)期目標(biāo)。針對物流流量分析場景我們進(jìn)行了物流站點(diǎn)吞吐量和 路徑流量等多種實(shí)際數(shù)據(jù)測試，均表明mongodb具有更高的 查詢性能。3. 1實(shí)驗(yàn)環(huán)境實(shí)測環(huán)境的數(shù)據(jù)庫版本為：mongodb： 2.4oracle： 10g3. 2物流流量分析場景實(shí)驗(yàn)

8、結(jié)果3. 2. 1物流站點(diǎn)吞吐量分析在表1的實(shí)驗(yàn)環(huán)境下，我們就各物流站點(diǎn)的吞吐率進(jìn)行 了統(tǒng)計(jì)分析，實(shí)驗(yàn)表明mongodb在做站點(diǎn)吞吐量分析時(shí)性能 較oracle更優(yōu)。具體數(shù)據(jù)如表2。3. 2. 2其他各種查詢條件比較我們也對其他復(fù)雜查詢統(tǒng)計(jì)條件進(jìn)行了測試比較， mongodb在查詢性能上較oracle整體具有優(yōu)勢。詳見表3。4總結(jié)本文針對物流行業(yè)訂單軌跡的數(shù)據(jù)分析性能優(yōu)化進(jìn)行 了探索，證明了在此場景下以mongodb為代表的非關(guān)系型分 布式數(shù)據(jù)庫具有良好的擴(kuò)展性和性能，為我們在'大數(shù)據(jù)” 時(shí)代深度發(fā)掘數(shù)據(jù)內(nèi)在商業(yè)價(jià)值提供了有效的分析手段。同 時(shí)我們也能看到目前開源的大數(shù)據(jù)存儲、分析解決方案層出 不窮，為迎接'大數(shù)據(jù)”時(shí)代的到來奠定了技術(shù)基礎(chǔ)。參考文獻(xiàn)：_1 mongodb 使用 手冊. http : /docs. mongodb. org/manual/.