基于NoSQL的PDM圖文檔存儲(chǔ)

夏秀峰，徐四鵬

XIA Xiu-feng1,2, XU Si-peng1

(1.沈陽航空航天大學(xué) 計(jì)算機(jī)學(xué)院，沈陽 110136；2.沈陽航空航天大學(xué) 遼寧省通用航空重點(diǎn)實(shí)驗(yàn)室，沈陽 110136)

0 引言

圖文檔是指與產(chǎn)品相關(guān)的信息中以圖檔或文檔形式存在的非結(jié)構(gòu)化數(shù)據(jù)，如設(shè)計(jì)任務(wù)書、設(shè)計(jì)規(guī)范、三維模型、技術(shù)文件、各種工藝數(shù)據(jù)文件、制造資源文件、合同文件、技術(shù)手冊(cè)、使用手冊(cè)等，是制造類企業(yè)產(chǎn)品數(shù)據(jù)管理的主要信息資源。

現(xiàn)有的PDM(Product Data Management，產(chǎn)品數(shù)據(jù)管理)圖文檔存儲(chǔ)幾乎全部采用關(guān)系數(shù)據(jù)庫(RDB)和文件系統(tǒng)集成的方式實(shí)現(xiàn)。隨著MBD(Model Based Definition，基于模型的定義)技術(shù)的實(shí)施和PLM(Product lifecycle management，全生命周期管理)的應(yīng)用，企業(yè)中的用戶幾乎“全員參與”。在圍繞三維模型的整個(gè)生命周期中包括需求、分析、設(shè)計(jì)、實(shí)施等環(huán)節(jié)會(huì)產(chǎn)生大量的圖文檔，這些數(shù)據(jù)隨著時(shí)間推移、產(chǎn)品型號(hào)增加等因素的影響，逐步呈現(xiàn)大數(shù)據(jù)態(tài)[1]，基于RDB的PDM系統(tǒng)在高擴(kuò)展性、高并發(fā)訪問和高可用性等方面存在的問題將會(huì)日顯突出——服務(wù)器和用戶終端機(jī)越來越“高檔”、存儲(chǔ)設(shè)備數(shù)量和容量越來越大、用戶訪問速度越來越慢、數(shù)據(jù)備份時(shí)間越來越長。

近年來，出現(xiàn)了以NoSQL為底層的云存儲(chǔ)系統(tǒng)[2]，它既滿足高并發(fā)讀寫性能需求，又適用于服務(wù)器彈性擴(kuò)展的需求。同時(shí)，考慮到部分圖文檔文件較大，而HDFS(Hadoop Distributed File System)能夠支持海量數(shù)據(jù)存儲(chǔ)，且易擴(kuò)展，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序，可以很好地支持百M(fèi)B及GB級(jí)的大文件。本文重點(diǎn)研究PDM圖文檔的存儲(chǔ)策略，將NoSQL數(shù)據(jù)庫加入以HDFS為基礎(chǔ)的企業(yè)私有云存儲(chǔ)平臺(tái)中，組建存儲(chǔ)資源網(wǎng)。

1 相關(guān)工作

采用數(shù)據(jù)庫方法存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)已有先例。文獻(xiàn)[3]采用RDB作為存儲(chǔ)底層，將非結(jié)構(gòu)化數(shù)據(jù)直接存儲(chǔ)于數(shù)據(jù)表中，實(shí)現(xiàn)了非結(jié)構(gòu)化數(shù)據(jù)和元數(shù)據(jù)的分離式存儲(chǔ)和統(tǒng)一管理。文獻(xiàn)[4]將文件數(shù)據(jù)分塊存入RDB，并對(duì)存儲(chǔ)過程和執(zhí)行SQL語句直接存儲(chǔ)兩種方法進(jìn)行效率分析得出最佳分塊大小。然而，由于RDB擴(kuò)展困難，在用戶增多的情況下不能提供高性能服務(wù)。文獻(xiàn)[5]脫離關(guān)系數(shù)據(jù)庫存儲(chǔ)思想，采用非關(guān)系數(shù)據(jù)庫存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，為云存儲(chǔ)提供了一種思路。文獻(xiàn)[2]中提出基于企業(yè)私有云的PDM系統(tǒng)結(jié)構(gòu)，采用NoSQL數(shù)據(jù)庫作為底層數(shù)據(jù)支持環(huán)境，結(jié)構(gòu)如圖1所示。

圖1 私有云存儲(chǔ)四層結(jié)構(gòu)模型

云存儲(chǔ)的核心是應(yīng)用軟件與存儲(chǔ)設(shè)備相結(jié)合，以實(shí)現(xiàn)存儲(chǔ)設(shè)備向存儲(chǔ)服務(wù)的轉(zhuǎn)變，用戶通過云存儲(chǔ)便能使用整個(gè)云存儲(chǔ)系統(tǒng)提供的數(shù)據(jù)訪問服務(wù)。但面對(duì)大量類型多樣的非結(jié)構(gòu)化數(shù)據(jù)，單一的存儲(chǔ)系統(tǒng)不能提供高效的訪問能力。文獻(xiàn)[6]分析了關(guān)系數(shù)據(jù)模型和NoSQL數(shù)據(jù)模型各自的特點(diǎn)，提出了一種可以解決云計(jì)算中海量數(shù)據(jù)存儲(chǔ)管理問題的新數(shù)據(jù)模型。文獻(xiàn)[7]根據(jù)存儲(chǔ)系統(tǒng)執(zhí)行操作的響應(yīng)時(shí)間將非結(jié)構(gòu)化數(shù)據(jù)自適應(yīng)的存儲(chǔ)至相應(yīng)的存儲(chǔ)子系統(tǒng)中。

2 圖文檔存儲(chǔ)模型

2.1 設(shè)計(jì)思想

在上述基于企業(yè)私有云的PDM系統(tǒng)結(jié)構(gòu)的基礎(chǔ)上，借鑒分布式系統(tǒng)的存儲(chǔ)模型，將圖文檔的元數(shù)據(jù)(即描述該圖文檔的數(shù)據(jù))和圖文檔數(shù)據(jù)分離，所有文件的元數(shù)據(jù)信息均保存至NoSQL數(shù)據(jù)庫中進(jìn)行管理，圖文檔數(shù)據(jù)則分布存儲(chǔ)至以NoSQL和HDFS為支撐的私有云存儲(chǔ)中。數(shù)據(jù)分布存儲(chǔ)模型如圖2所示。

圖2 圖文檔存儲(chǔ)模型

存儲(chǔ)模型充分考慮了圖文檔的存儲(chǔ)需求和現(xiàn)有技術(shù)的結(jié)合。圖文檔類型多樣，而且數(shù)據(jù)大小極不規(guī)律，小則幾百字節(jié)，大則幾個(gè)G字節(jié)，因此存儲(chǔ)系統(tǒng)不僅需滿足高效存儲(chǔ)和低成本存儲(chǔ)，還需滿足小文件的快速響應(yīng)及大文件的高吞吐量存取。對(duì)于文件數(shù)據(jù)，NoSQL和HDFS均是將數(shù)據(jù)劃分成統(tǒng)一的塊進(jìn)行存儲(chǔ)，NoSQL的分塊大小一般在幾個(gè)M字節(jié)以下，支持高并發(fā)讀寫及海量存儲(chǔ)，但當(dāng)文件太大時(shí)，數(shù)據(jù)所對(duì)應(yīng)的元數(shù)據(jù)的數(shù)據(jù)量就會(huì)增多，造成存儲(chǔ)空間的極大浪費(fèi)。而HDFS默認(rèn)的數(shù)據(jù)塊的分塊大小是64M，可以很好地支持百M(fèi)B及GB級(jí)的大文件，但由于它是以一定延時(shí)為代價(jià)來滿足高數(shù)據(jù)量吞吐而設(shè)計(jì)的，因此并不適用于低延遲訪問，且由于HDFS在對(duì)文件數(shù)據(jù)存儲(chǔ)管理時(shí)，需將文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所能容納的文件數(shù)目由HDFS的內(nèi)存大小決定，當(dāng)小文件過多時(shí)，將占用大量元數(shù)據(jù)，降低了系統(tǒng)的存取能力和存取效率。

綜合以上情況，存儲(chǔ)模型采用NoSQL和HDFS共同支撐數(shù)據(jù)存儲(chǔ)，既可以減輕NoSQL的負(fù)擔(dān)，充分利用存儲(chǔ)空間，又能保證系統(tǒng)的高效存取，提高HDFS的元數(shù)據(jù)利用率。

2.2 存儲(chǔ)系統(tǒng)綜合評(píng)判模型

存儲(chǔ)模型是以文件大小作為依據(jù)進(jìn)行數(shù)據(jù)劃分，實(shí)現(xiàn)小文件存儲(chǔ)至NoSQL，大文件存儲(chǔ)至HDFS。為有效減小決策的主觀性和不確定性，本文設(shè)計(jì)了存儲(chǔ)系統(tǒng)評(píng)判模型，通過對(duì)多個(gè)代價(jià)指標(biāo)進(jìn)行綜合評(píng)判，確定文件最優(yōu)存儲(chǔ)位置。下面給出模型的形式化描述。

設(shè)文件大小為L，存儲(chǔ)系統(tǒng)為m，定義代價(jià)綜合評(píng)判值為該文件的存儲(chǔ)時(shí)間代價(jià)、讀取時(shí)間代價(jià)和文件分塊元數(shù)據(jù)(即描述文件分塊的數(shù)據(jù)，與文件元數(shù)據(jù)區(qū)分)占用空間代價(jià)的加權(quán)平均值，用Cost(L,m)表示，則有：

其中，w(u)+w(d)+w(s)=1，0＜w(u)，w(d)，w(s)＜1，m=1，2。Tup(L,m)、Tdown(L,m)、S(L,m)分別表示大小為L的文件在存儲(chǔ)系統(tǒng)為m的存儲(chǔ)時(shí)間代價(jià)、讀取時(shí)間代價(jià)和文件分塊元數(shù)據(jù)占用空間代價(jià)，w(u)、w(d)、w(s)分別為對(duì)應(yīng)權(quán)值，m=1表示HDFS，m=2表示NoSQL，本文選用NoSQL之中的文檔型數(shù)據(jù)庫MongoDB進(jìn)行實(shí)驗(yàn)研究，因此這里m=2時(shí)表示MongoDB。

由于評(píng)價(jià)指標(biāo)是定量的，所以在綜合評(píng)價(jià)前應(yīng)先進(jìn)行統(tǒng)一量綱的處理。式(1)中時(shí)間代價(jià)單位取ms(毫秒)，空間代價(jià)單位取Byte(字節(jié))，相應(yīng)的數(shù)值表示代價(jià)評(píng)分，數(shù)值越小表示代價(jià)越小。模型中選取分塊元數(shù)據(jù)占用空間代價(jià)作為評(píng)判指標(biāo)是因?yàn)槲募?shù)據(jù)的存儲(chǔ)是將文件分塊后對(duì)一個(gè)或多個(gè)文件分塊和分塊對(duì)應(yīng)的元數(shù)據(jù)的存儲(chǔ)，不同存儲(chǔ)系統(tǒng)對(duì)文件分塊的管理所需元數(shù)據(jù)空間代價(jià)不同。

本文設(shè)計(jì)的存儲(chǔ)平臺(tái)部署在一個(gè)高速交換網(wǎng)絡(luò)中，所以在計(jì)算存取代價(jià)時(shí)，網(wǎng)絡(luò)影響因素可以忽略不計(jì)。CPU頻率、內(nèi)存等計(jì)算機(jī)系統(tǒng)因素也會(huì)對(duì)存取代價(jià)產(chǎn)生影響，但是這類因素很不穩(wěn)定，難以通過調(diào)節(jié)這些因素來改進(jìn)存取效率，因此也忽略這些因素。

在HDFS中，文件的存儲(chǔ)時(shí)間和讀取時(shí)間均包括啟動(dòng)代價(jià)StartCost()和數(shù)據(jù)傳輸代價(jià)TransferCost()，數(shù)學(xué)表達(dá)分別如下：

每一個(gè)文件、文件夾和Block需要占據(jù)150Byte 左右的空間，因此單個(gè)文件塊元數(shù)據(jù)占用至少300Byte。元數(shù)據(jù)的空間代價(jià)可表示如下：

其中，B為HDFS塊大小，默認(rèn)為64MB，[L/B]向上取整表示文件分塊塊數(shù)。

對(duì)于MongoDB，GridFS是其上的一種輕量級(jí)分布式文件存儲(chǔ)規(guī)范，它是將大文件對(duì)象分割成多個(gè)小的chunk(文件片段)，利用了MongoDB的分布式存儲(chǔ)機(jī)制來實(shí)現(xiàn)文件存儲(chǔ)，適用于大量尺寸較小的文件，它的數(shù)據(jù)分塊大小C一般為256kB，文件分塊的元數(shù)據(jù)一般占用25Byte。則有：

由于所有文件的元數(shù)據(jù)均存儲(chǔ)至MongoDB，在對(duì)HDFS和MongoDB的代價(jià)綜合評(píng)判時(shí)考慮的是文件數(shù)據(jù)的存儲(chǔ)，因此對(duì)于MongoDB的文件存儲(chǔ)代價(jià)主要是指對(duì)文件分塊和與之相對(duì)應(yīng)的分塊元數(shù)據(jù)的存儲(chǔ)。存儲(chǔ)時(shí)間包括文件分塊I/O時(shí)間和分塊提交數(shù)據(jù)庫所有時(shí)間，如式(6)：

其中，T0表示文件分塊I/O所用時(shí)間，T1表示每個(gè)文件分塊提交數(shù)據(jù)庫所用時(shí)間。

讀取時(shí)間主要包括文件分塊的查詢時(shí)間和傳輸時(shí)間，其數(shù)學(xué)表達(dá)為：

其中，Tq(L,2)表示對(duì)于文件分塊總的查詢時(shí)間，V0表示使用MongoDB時(shí)文件數(shù)據(jù)的傳輸速度。

式(1)中各指標(biāo)的權(quán)值可以利用層次分析法(AHP)[8]進(jìn)行計(jì)算。AHP是美國運(yùn)籌學(xué)家托馬斯薩迪提出的一種層次權(quán)重決策分析方法，是對(duì)定性問題進(jìn)行定量分析的一種簡便、靈活而實(shí)用的多準(zhǔn)則決策方法。具體計(jì)算步驟如下。

步驟1：構(gòu)造比較矩陣A。ai（i=1，2，3）表示評(píng)判指標(biāo)。

其中：

步驟2：構(gòu)造判斷矩陣B：

式中：

步驟3：計(jì)算出B的特征值和特征向量，將特征向量歸一化處理即得到與指標(biāo)對(duì)應(yīng)的權(quán)值。

在PDM系統(tǒng)中，對(duì)文件主要有上傳、下載、讀取等操作，由于讀取文件是最頻繁的操作，因此認(rèn)定Tdown是最重要的，按照存儲(chǔ)模型設(shè)計(jì)思想，S次之，Tup重要性最弱。經(jīng)計(jì)算，3個(gè)指標(biāo)的權(quán)值如表1所示。

表1 各指標(biāo)權(quán)值

3 實(shí)驗(yàn)及結(jié)果分析

實(shí)驗(yàn)環(huán)境為：三臺(tái)機(jī)架服務(wù)器和一個(gè)磁盤陣列。三個(gè)機(jī)架服務(wù)器中，一個(gè)為12核、24線程、16G內(nèi)存，型號(hào)為A620r-G；另兩個(gè)機(jī)架服務(wù)器為24核、48線程、64G內(nèi)存，型號(hào)為A840r-G；磁盤陣列有10T容量，型號(hào)為DS200-N10。在服務(wù)器上，搭建MongoDB和HDFS的云環(huán)境，HDFS包含1個(gè)namenode節(jié)點(diǎn)、1個(gè)snamenode和8個(gè)datanode節(jié)點(diǎn)，MongoDB由1個(gè)路由進(jìn)程、1個(gè)配置服務(wù)器和6個(gè)分片節(jié)點(diǎn)構(gòu)成。Hadoop軟件版本為1.2.1。MongoDB的版本為2.4.8。Java版本為jdk1.7.0_40。

本文以視頻文件為例，首先通過實(shí)驗(yàn)1獲取不同長度的文件在HDFS的啟動(dòng)代價(jià)以及存儲(chǔ)時(shí)間和讀取時(shí)間，計(jì)算出每塊數(shù)據(jù)塊的上傳和下載傳輸速度。然后再通過實(shí)驗(yàn)2獲取文件在MongoDB的存儲(chǔ)時(shí)間和讀取時(shí)間，并將之與實(shí)驗(yàn)1數(shù)據(jù)進(jìn)行對(duì)比。最后給出HDFS和MongoDB的代價(jià)綜合評(píng)判值對(duì)比。

實(shí)驗(yàn)1選取文件長度為275k、679k、1.04M、1.5 9 M、2.5 7 M、3.5 5 M、4.5 3 M、5.5 4 M、5.9 9 M、7.3 2 M、9.5 1 M、1 5.4 M、1 9.6 M、2 4.9 M、3 2.1 M、3 5.0 M、3 9.2 M、4 6.5 M、53.5M、60.8M進(jìn)行存儲(chǔ)和下載，并且在不同的時(shí)段重復(fù)這樣的實(shí)驗(yàn)10次。分別統(tǒng)計(jì)啟動(dòng)代價(jià)、存儲(chǔ)時(shí)間和下載時(shí)間，并計(jì)算出兩種情況下傳輸不同文件長度的速度，結(jié)果如圖3所示。

圖3 HDFS下文件上傳和文件下載時(shí)傳輸速度

經(jīng)實(shí)驗(yàn)測(cè)得上傳啟動(dòng)代價(jià)在734ms～766ms范圍內(nèi)，下載啟動(dòng)代價(jià)在820ms～860ms范圍內(nèi)。從圖3和圖4中可以看出，傳輸速度隨著文件大小的增加不斷提高，下載的傳輸速度在文件大小為3.55M以后穩(wěn)定在11M/s左右，上傳時(shí)的傳輸速度在25M以后開始穩(wěn)定在10MB/s左右，在15M～20M之間上傳速度約9.7MB/s。

實(shí)驗(yàn)2分別統(tǒng)計(jì)MongoDB下文件存儲(chǔ)時(shí)間和讀取時(shí)間。取長度為275k、679k、1.04M、1.59M、2.57M、3.55M、4.53M、5.54M、5.99M、7.32M、9.51M、15.4M、19.6M、24.9M、32.1M、35.0M、39.2M、46.5M、53.5M、60.8M的視頻文件進(jìn)行存儲(chǔ)和讀取，并且在不同的時(shí)段重復(fù)這樣的實(shí)驗(yàn)10次。統(tǒng)計(jì)平均值，將最終實(shí)驗(yàn)結(jié)果與實(shí)驗(yàn)1得到的存儲(chǔ)時(shí)間和下載時(shí)間進(jìn)行比較，如圖4所示。

圖4 HDFS和MongoDB文件上傳時(shí)間和下載時(shí)間對(duì)比

MongoDB具有小文件存取優(yōu)勢(shì)，存儲(chǔ)效率在25M以后低于HDFS，而文件讀取效率一直高于HDFS。

通過上述實(shí)驗(yàn)數(shù)據(jù)計(jì)算出各存儲(chǔ)系統(tǒng)的代價(jià)綜合評(píng)判值，其中元數(shù)據(jù)占用存儲(chǔ)空間代價(jià)可以直接計(jì)算得出。對(duì)比結(jié)果如圖5所示。

從圖5中可以看出文件大小在15M～20M時(shí)，二者的代價(jià)綜合評(píng)判值基本持平。以上實(shí)驗(yàn)是存儲(chǔ)系統(tǒng)低負(fù)載下對(duì)單文件的存取，數(shù)據(jù)分塊的搜索時(shí)間很短，可以忽略不計(jì)，將求得的各參數(shù)代入模型，當(dāng)二者代價(jià)綜合評(píng)判值相等時(shí)得出文件長度為17MB?？紤]到在MongoDB存儲(chǔ)的文件越大，分塊數(shù)就會(huì)越多，勢(shì)必會(huì)增加數(shù)據(jù)庫負(fù)擔(dān)，同時(shí)增加文件分塊的搜索代價(jià)，因此設(shè)置文件存儲(chǔ)閾值不應(yīng)超過17MB，當(dāng)文件大小低于存儲(chǔ)閾值時(shí)，將數(shù)據(jù)存儲(chǔ)至MongoDB，反之則存入HDFS。

該存儲(chǔ)評(píng)判模型確定的閾值可以實(shí)現(xiàn)存儲(chǔ)平臺(tái)在快速響應(yīng)和高吞吐量之間的平衡，面對(duì)大中型企業(yè)海量圖文檔數(shù)據(jù)存儲(chǔ)，可以有效實(shí)現(xiàn)數(shù)據(jù)的均衡分布，既滿足大文件高吞吐量存取，又能滿足小文件的及時(shí)響應(yīng)。對(duì)于小型企業(yè)，在大文件不是海量的情況下，可以考慮僅以MongoDB作為底層數(shù)據(jù)支持開發(fā)PDM系統(tǒng)。

圖5 代價(jià)綜合評(píng)判值對(duì)比

4 結(jié)束語

傳統(tǒng)基于RDB的PDM圖文檔存儲(chǔ)系統(tǒng)已無法滿足海量數(shù)據(jù)存儲(chǔ)需求。針對(duì)圖文檔妥善存儲(chǔ)問題，本文結(jié)合NoSQL和HDFS面對(duì)不同類型非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)優(yōu)勢(shì)，提出一種代價(jià)綜合評(píng)判模型，兼顧快速響應(yīng)和高效存儲(chǔ)，通過實(shí)驗(yàn)并結(jié)合多維屬性決策理論得出文件存儲(chǔ)閾值。在云存儲(chǔ)環(huán)境下，NoSQL數(shù)據(jù)庫存儲(chǔ)技術(shù)為PDM圖文檔存儲(chǔ)提供了一種新思路，下一步將對(duì)查詢進(jìn)行優(yōu)化，以實(shí)現(xiàn)對(duì)文件及文件塊的快速搜索。

[1] 夏秀峰,趙小磊,孔慶云.MBE與大數(shù)據(jù)給PDM帶來的思考[J].制造業(yè)自動(dòng)化,2013,10(35)：70-72.

[2] 申德榮,于戈,王習(xí)特,聶鐵錚,寇月.支持大數(shù)據(jù)管理的NoSQL系統(tǒng)研究綜述.軟件學(xué)報(bào),2013,24(8)：1786-1803.http：//www.jos.org.cn/1000-9825/4416.htm.

[3] 謝華成,陳向東.面向云存儲(chǔ)的非結(jié)構(gòu)化數(shù)據(jù)存取[J].計(jì)算機(jī)應(yīng)用,2012,32(7)：1924 -1928,1942.

[4] 宋國兵,陳奇.文件數(shù)據(jù)的數(shù)據(jù)庫Blob存儲(chǔ)及效率分析[J].計(jì)算機(jī)工程與設(shè)計(jì),2010,31(21)：4625-4626.

[5] 張艷霞,豐繼林,郝偉,單維鋒,沈焱萍.基于NoSQL的文件型大數(shù)據(jù)存儲(chǔ)技術(shù)研究[J],制造業(yè)自動(dòng)化,2014,03(3)：27-28.