大數(shù)據(jù)下MongoDB數(shù)據(jù)庫檔案文檔存儲(chǔ)去重研究

賀建英

摘 要： 針對(duì)大數(shù)據(jù)下檔案存儲(chǔ)的現(xiàn)狀，通過分析存儲(chǔ)檔案文檔存在重復(fù)的原因，提出一種MongoDB存儲(chǔ)檔案文檔的方法，利用MongoDB的GridFs統(tǒng)一處理不同類型和大小的文件，定義3個(gè)集合分別存儲(chǔ)上傳者記錄、文件信息記錄和分塊文件內(nèi)容，提出存儲(chǔ)中通過文件MD5校驗(yàn)碼值是否相同來進(jìn)行去重研究，并實(shí)現(xiàn)去重的程序代碼，有一定的實(shí)際意義。采用的分布式存儲(chǔ)數(shù)據(jù)庫增強(qiáng)了檔案文檔存儲(chǔ)系統(tǒng)的可擴(kuò)展性。實(shí)驗(yàn)表明，該方法能有效地去除重復(fù)的檔案文檔，提高查詢效率。

關(guān)鍵詞： MongoDB； MD5； 大數(shù)據(jù)； 檔案文檔去重； GridFs

中圖分類號(hào)： TN911?34； TP311 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2015）16?0051?05

Research on duplicated document removal in big data archive storage of MongoDB database

HE Jianying

（College of Computer， Sichuan University of Arts and Science， Dazhou 635000， China）

Abstract： In allusion to the present situation in document storage in case of big data， the MongoDB method to save documents is proposed according to the reason analysis of duplication in document storage. GridFs of MongoDB is used to store different type documents. Three different assemblages are definited to store the uploader record， document information record and content of blocked documents respectively. A research is proposed for removing the duplication by checking whether MD5 check code is same or not. It is significant to realize program code for duplicated document removal. The distributive memory database was used to enhance the expandability of the document saving system. The experimental result shows that this method can remove the duplicated documents effectively and improve the efficiency of inquiry.

Keywords： MongoDB； MD5； big data； file document duplicate removal； GridFs

0 引 言

隨著信息技術(shù)的飛躍發(fā)展，各國(guó)各地都在大力發(fā)展電子政務(wù)建設(shè)。在此環(huán)境下檔案局的檔案文檔也跨入了信息化存儲(chǔ)的行列。但檔案局的檔案類型種類較多，除了純文本的之外，還有圖片、聲音、視頻、PDF等各種類型的文檔，這些文檔都是非結(jié)構(gòu)化的數(shù)據(jù)，在傳統(tǒng)的信息系統(tǒng)中，存放這些數(shù)據(jù)是比較困難的。因此在大數(shù)據(jù)環(huán)境下，設(shè)計(jì)信息化檔案存儲(chǔ)系統(tǒng)會(huì)首選非結(jié)構(gòu)化的數(shù)據(jù)庫，即NoSQL數(shù)據(jù)庫。利用NoSQL家族中的MongoDB數(shù)據(jù)庫作為存放檔案文檔的非結(jié)構(gòu)化數(shù)據(jù)是較為理想的。MongoDB對(duì)存放大量的非結(jié)構(gòu)化數(shù)據(jù)有很大的優(yōu)勢(shì)，但因MongoDB本身就是非結(jié)構(gòu)化的，故在存放信息時(shí)會(huì)產(chǎn)生重復(fù)的數(shù)據(jù)。有人提出了像在關(guān)系數(shù)據(jù)庫中一樣建立關(guān)鍵索引來解決重復(fù)數(shù)據(jù)的問題，但在以文檔方式存儲(chǔ)的數(shù)據(jù)而言，當(dāng)數(shù)據(jù)很大時(shí)，這種方式將會(huì)有弊端。本文研究的是在存儲(chǔ)檔案文檔之前就重復(fù)的數(shù)據(jù)進(jìn)行去重處理，然后再存入MongoDB數(shù)據(jù)庫中，這樣在數(shù)據(jù)庫中存放的將是非重復(fù)的數(shù)據(jù)。

1 傳統(tǒng)的檔案存儲(chǔ)分析

在原有的存儲(chǔ)檔案文檔信息系統(tǒng)中，主要是把文檔以文件的形式存放在文件系統(tǒng)中，然后用原數(shù)據(jù)信息建立一個(gè)檔案文件和數(shù)據(jù)庫的鏈接，并把該鏈接的路徑存儲(chǔ)在關(guān)系數(shù)據(jù)庫中，如表1和表2所示。

通過表1和表2的分析可知，表2中filePathId與表1中的filePathId中的字段關(guān)聯(lián) ，這樣在訪問表1中的某個(gè)文件時(shí)，只需要訪問表2中與filePathId字段關(guān)聯(lián)的記錄的fileRealPath的值即可訪問該文件。對(duì)于以文件系統(tǒng)方式存放的檔案文件會(huì)產(chǎn)生大量的重復(fù)文件。即使在存儲(chǔ)的時(shí)候能簡(jiǎn)單的通過人工的方式來檢查是否有重復(fù)的文件存放，但也不能大面積的檢查是否有重復(fù)的文件，在這種方式下，存儲(chǔ)空間很快會(huì)被耗盡，要靠不斷的增加存儲(chǔ)設(shè)備來解決大量檔案數(shù)據(jù)存放的問題，而且不利于管理，數(shù)據(jù)極其不安全，擴(kuò)展性較差。人們對(duì)此已有逐步的認(rèn)識(shí)，也進(jìn)行了相應(yīng)的研究。本文的重點(diǎn)是利用MongoDB數(shù)據(jù)庫來存儲(chǔ)這些非結(jié)構(gòu)化的數(shù)據(jù)，并且在存放之前就完成對(duì)重復(fù)檔案文檔的去重操作。

表1 文件基本信息表

表2 文件存儲(chǔ)路徑映射表

2 基于MongoDB的文檔存儲(chǔ)模型

2.1 MongoDB的存儲(chǔ)機(jī)制

MongoDB是NoSql家族中的一員，具有模式自由等特性。它與關(guān)系數(shù)據(jù)庫一樣具有3個(gè)層次：分別是數(shù)據(jù)庫層、集合層、文檔對(duì)象層。分別對(duì)應(yīng)關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)庫、表和記錄。在MongoDB中文檔類似于JSON的鍵/值對(duì)，集合則是一組文檔的集合，它們是無模式限制的。MongoDB數(shù)據(jù)庫非常適合實(shí)時(shí)數(shù)據(jù)的插入、查詢、更新、刪除及數(shù)據(jù)備份等操作。尤其適合充當(dāng)由幾十臺(tái)或者幾百臺(tái)服務(wù)器組成的集群數(shù)據(jù)庫?，F(xiàn)在大多數(shù)的地理規(guī)劃等領(lǐng)域都在利用MongoDB數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲(chǔ)。MongoDB數(shù)據(jù)庫不僅支持分布式系統(tǒng)，它本身還支持分片存儲(chǔ)數(shù)據(jù)（Mongod）、客戶端請(qǐng)求（Clients）、集群配置（Config Server）和路由協(xié)議（Mongos）[1]。它采用的是內(nèi)存映射的方式作為存儲(chǔ)引擎，能有效地提高輸入/輸出的效率[2]。endprint

2.2 MongoDB數(shù)據(jù)庫中重復(fù)數(shù)據(jù)來源

目前的檔案管理系統(tǒng)還處于信息孤島的層面，各個(gè)省市的數(shù)據(jù)結(jié)構(gòu)不同，存放的方式也不同，惟一能統(tǒng)一的是從市級(jí)單位及其下級(jí)單位，如區(qū)、縣、鄉(xiāng)、鎮(zhèn)單位。利用檔案管理系統(tǒng)上傳檔案文件進(jìn)行存儲(chǔ)的也是這些相關(guān)單位。如果同一份檔案文檔被市級(jí)單位分發(fā)到其他單位，其他單位會(huì)把它作為重要檔案文檔給上傳到檔案管理系統(tǒng)中存儲(chǔ)起來，這樣就會(huì)產(chǎn)生多個(gè)重復(fù)的檔案文檔。而有部門在不知道的情況下，同一個(gè)人上傳了幾份相同的檔案文檔；或者利用shp文件批量上傳檔案文檔時(shí)遇到其他異常情況，沒有一次性的上傳完，下次再上傳的時(shí)候，又是從頭開始上傳，導(dǎo)致以前的檔案文檔被重復(fù)存儲(chǔ)；或者在批量上傳的shp文檔本身被人為的不小心做成了含有重復(fù)的檔案文檔記錄，這樣導(dǎo)入shp文件時(shí)也會(huì)產(chǎn)生重復(fù)記錄。通過對(duì)以上情況的分析可知，檔案文檔存儲(chǔ)時(shí)在MongoDB數(shù)據(jù)庫中產(chǎn)生重復(fù)數(shù)據(jù)的來源主要有以下幾點(diǎn)：同一個(gè)檔案文檔被不同的單位、部門重復(fù)上傳；同一個(gè)人對(duì)同一個(gè)檔案文檔上傳多次；批量檔案文檔準(zhǔn)備過程中人為的產(chǎn)生了重復(fù)文檔；批量上傳時(shí)，中斷上傳，下次再上傳時(shí)將產(chǎn)生重復(fù)文檔。

2.3 檔案存儲(chǔ)模型的建立

檔案存儲(chǔ)時(shí)采用分布式的方式進(jìn)行上傳存儲(chǔ)的，各個(gè)市、區(qū)、縣、鄉(xiāng)、鎮(zhèn)的不同部門可能在不同的時(shí)間和地點(diǎn)對(duì)檔案文檔進(jìn)行上傳操作。數(shù)據(jù)庫采用MongoDB數(shù)據(jù)庫，其分布式存儲(chǔ)結(jié)構(gòu)如圖1所示。

圖1 分布式數(shù)據(jù)庫存儲(chǔ)圖

從圖1可以看出，各市、縣、鄉(xiāng)、鎮(zhèn)的用戶可以隨時(shí)在不同地點(diǎn)上傳檔案文檔到不同的MongoDB服務(wù)器中，操作方便。檔案文檔不同于一般的文檔，將遵循“誰操作誰負(fù)責(zé)”的原則。故將設(shè)置上傳者的權(quán)限，且將記錄上傳者的詳細(xì)信息：如上傳時(shí)間、地點(diǎn)等的一些信息。而對(duì)于檔案文檔本身而言其文件大小不能統(tǒng)一標(biāo)準(zhǔn)化，且檔案文檔的格式有差異，考慮到要處理數(shù)據(jù)大小和類型都可能不同的檔案文檔，本文將借助于MongoDB的GridFs來處理，GridFs是一種處理大文件的規(guī)范，可以存儲(chǔ)上百萬的文件而不用擔(dān)心其擴(kuò)容性[3]。在MongoDB中存放數(shù)據(jù)時(shí)將涉及到3個(gè)集合：userInfo.users，fileInfo.files，fileContent.chunks。

userInfo.users集合用來存放上傳檔案文檔的上傳者信息，其結(jié)構(gòu)如下：

{

“_ID”： //惟一值

“UserID”： //用戶的ID值

“UploadGeography”： //上傳的地理位置

“GeoType”： //地址位置的類型，如城//鎮(zhèn)、居民點(diǎn)等

“UploadGeoName”： //地理名稱

“UploadGeoNameID”：< String > //地理名稱主鍵值

“UploadGeoAddress”： //上傳的城鎮(zhèn)地址等

“CityName”： //城鎮(zhèn)名稱

“CountyName”：< String > //縣級(jí)名稱

“TownName”：< String > //鄉(xiāng)鎮(zhèn)名稱

“StreetName”：< String > //街道名稱

“GeoPts”： //地理坐標(biāo)

“Type”：< String > //坐標(biāo)類型

“GeoCoordinates”：< String > //坐標(biāo)位置

“UploadFileID”：< objectID> //上傳存放文件信息的ID編號(hào)

“UploadTime”：< timestamp > //上傳者操作的

//體時(shí)間

“UploadCount”： //同一文檔上傳的次數(shù)

}

fileInfo.files集合中存放信息的結(jié)構(gòu)為：

{

“fileID”：

//存放文件ID值與userInfo.users集合中upLoadFileID對(duì)應(yīng)

“fileLength”：< num > //文件的大小

“fileChuckSize”：< num > //文件分塊存儲(chǔ)的分塊數(shù)

“fileName”：< String > //上傳文件的名稱

“fileMD5”：< hash > //文件內(nèi)容的MD5校驗(yàn)碼值

“fileCountType”：< String > //文件的類型

}

fileContent.chucks集合中存放上傳文檔的結(jié)構(gòu)如下：

{

“f_ID”：< objectID > //惟一的值

“fileID”：< objectID > //與fileInfo.files集

//合中的fileID對(duì)應(yīng)

“countOrder”：< num > //存放上傳文件的第幾個(gè)分塊

“countData”：< binary > //存放文檔對(duì)應(yīng)分塊部分//的二進(jìn)制內(nèi)容

}

集合fileInfo.files中的fileID與集合userInfo.users集合中的upLaodfileID相同，用來關(guān)聯(lián)上傳的文件信息。集合fileContent.chucks中的fileID與集合fileInfo.files中的fileID相同，用來關(guān)聯(lián)文件存放的具體內(nèi)容，根據(jù)上面3個(gè)集合中結(jié)構(gòu)的設(shè)計(jì)，當(dāng)一個(gè)具有操作權(quán)限的用戶在某一地點(diǎn)上傳了某個(gè)檔案文件后，將記錄該用戶上傳的詳細(xì)信息：如操作者，上傳的具體區(qū)、縣、鄉(xiāng)的詳細(xì)地址，上傳的日期、文件名、文件的大小、長(zhǎng)度、類型等。當(dāng)該用戶再次上傳相同的檔案文檔時(shí)，根據(jù)表的關(guān)聯(lián)查找，將會(huì)做出已在同一地點(diǎn)或不同地點(diǎn)已經(jīng)上傳了相同的檔案文件的提示信息。

3 MongoDB中的去重算法

本算法的設(shè)計(jì)思想是，根據(jù)上傳的檔案文檔判斷，無論是否已經(jīng)被上傳過，都會(huì)存儲(chǔ)上傳檔案文檔操作者的相關(guān)信息，即生成一個(gè)userInfo.users集合中的一條記錄。上傳檔案文件時(shí)為了節(jié)省服務(wù)器的開銷和資源，所上傳文檔的MD5 校驗(yàn)碼值的計(jì)算都會(huì)在客戶端進(jìn)行。在客戶端計(jì)算并上傳檔案文檔的MD5校驗(yàn)碼值后再在分布式存儲(chǔ)數(shù)據(jù)庫中查找遍歷fileInfo.files中的每一條記錄，查看每條記錄中存儲(chǔ)的檔案文檔的MD5碼值是否與將要上傳的檔案文檔的MD5碼值相同，如果不同，則將在userInfo.user集合中存儲(chǔ)一條上傳者信息的記錄，并且把該記錄中的“UploadCount”值設(shè)置為1。同時(shí)生成集合fileInfo.files中的一條記錄，在該記錄中通過“fileMD5”存儲(chǔ)檔案文檔的MD5碼值。獲得要上傳的檔案文檔的大小fileSize，確定檔案分塊存儲(chǔ)的總塊數(shù)fileChuckSize。在算法中為了規(guī)范，不管文件的大小和類型，均采用統(tǒng)一大?。╢ixedSize）的分塊對(duì)檔案文檔進(jìn)行存放，即總分塊數(shù)如下所示：

fileChuckSize=（fileSize%fixedSize）？（fileSize/fixedSize）：

（fileSize/fixedSize+1）

并把該值記錄到fileInfo.files集合中對(duì)應(yīng)記錄中。然后對(duì)檔案文檔進(jìn)行上傳并對(duì)文檔內(nèi)容按固定的分塊大小存放到fileContent.chucks集合中，在該集合里會(huì)存儲(chǔ)fileChuckSize條記錄。如果要上傳的檔案文檔的MD5碼值和分布式數(shù)據(jù)庫中存儲(chǔ)的fileInfo.files集合中存儲(chǔ)的某個(gè)記錄的fileMD5值相同，則取出該條記錄對(duì)應(yīng)的fileID值并把該值存放到一個(gè)臨時(shí)存儲(chǔ)字段tempFileID中，已備后期使用。然后提取上傳者的信息和tempFileID的值組合成userInfo.users集合中的一條記錄，并與集合中的其他記錄進(jìn)行比較，如果有相同的記錄，則在該條記錄的UploadCount值加1。而組合的這條記錄將不再存儲(chǔ)在userInfo.users集合中。其中UploadCount值加1是判斷該用戶是否經(jīng)常在同一個(gè)地點(diǎn)上傳相同的檔案文檔。

如果在該集合中沒有相同的記錄，則存儲(chǔ)該組合好的記錄。下次在訪問這個(gè)檔案文檔時(shí)，通過userInfo.users集合中的upLoadfileID關(guān)聯(lián)到fileInfo.files集合，再通過fileInfo.files集合中的fileID關(guān)聯(lián)到fileContent.chucks集合，則順利訪問到需要的檔案文檔，其過程流程圖如圖2所示。

根據(jù)算法流程圖，定義幾個(gè)類UserInfo，F(xiàn)ileInfo，F(xiàn)ileContent分別對(duì)應(yīng)3個(gè)集合，定義操作數(shù)據(jù)庫的類DBObj，定義去重的類RemoveRepeat。

圖2 算法流程圖

去重的關(guān)鍵代碼實(shí)現(xiàn)如下：

/ *在fileInfo.files集合中查找有沒有與指定的hashMD5碼相同的記錄存在*/

private String findByFileMD5（hash fileMD5） {

String tempFileID=null；

List repeatList = new ArrayList（）；

GeoEntiy ge = null；

/*取得傳遞的fileMD5參數(shù) */

String json = "{fileMD5 ： ＼"" + fileMD5 + "＼"}"；

DBObj fileMD5 = （DBObj） JSON.parse（json）；

DBCursor dbcursor = getDBColl（）.find（fileMD5）；

/* 根據(jù)坐標(biāo)點(diǎn)查詢的記錄數(shù)量*/

int rowCount = dbcursor.count（）；

/*如果結(jié)果大于0則說明有相同的MD5碼存在，則存放該記錄的fileID值*/

if （rowCount > 0） {

tempFileID= rowCount.get（"fileID"）.toString（）；

}

}

return tempFileID；

}

public List findRepeatData（） {

/* 構(gòu)建數(shù)據(jù)查重的MongoDB語句，并進(jìn)行查重 */

DBObj groupObj = new BasicDBObj（"$group"， JSON.parse（" {_ID： { "

+ " UserID ： ＼"$UserID＼" ， "

+ " UploadGeography ： ＼"$UploadGeography＼" "

+ " GeoType ： ＼"$GeoType＼" ， "

+ " UploadGeoName ： ＼"$UploadGeoName＼" ， "

+ " UploadGeoNameID： ＼"$UploadGeoNameID＼" ， "

+ " UploadGeoAddress ： ＼"$UploadGeoAddress＼" ， "

+ " CityName ： ＼"$CityName＼" ， "

+ " CountyName ： ＼"$CountyName＼" ， "

+ " TownName ： ＼"$TownName＼" ， "

+ " StreetName ： ＼"$StreetName＼" ， "

+ " GeoPts ： ＼"$GeoPts＼" ， "+ " Type ： ＼"$Type＼" ， "

+ " GeoCoordinates： ＼"$UploadFileID＼" ， "

+ " UploadTime ： ＼"$UploadTime＼" ， "

+ " UploadCount： ＼"$UploadCount＼"）；

// 排序條件 ?? 按照關(guān)鍵字_ID降序排列

DBObj sortObj = new BasicDBObj（"$sort"，JSON.parse（"{ _ID：?1 }"））；

// 確定疑似重復(fù)數(shù)據(jù)的條件返回的結(jié)果為1

DBObj matchObj = new BasicDBObj（"$match"，JSON.parse（"{ _ID：?1 }）；

// key code

AggregationOutput output = getDBColl（）.aggregate（groupObj， sortObj，matchObj）；

Iterator iter = output.results（）.iterator（）；

//獲取查詢結(jié)果集

List list = new ArrayList（）；

while （iter.hasNext（）） {

DBObj dbo = iter.next（）；

String _idValue = dbo.get（"_ID"）.toString（）；

//通過key，獲取對(duì)應(yīng)的value

if （_idValue ！= null） {//如果查詢結(jié)果不為空，則將結(jié)

果轉(zhuǎn)換

JSONObj pointJson = com.alibaba.fastjson.JSON.parseObject（_idValue）；

// 如果存在坐標(biāo)點(diǎn)或有想太多 其他值，則獲取

if （pointJson.get（"GeoPts"） ！= null） {

list.addAll（findByPoints（pointJson.get（"GeoPts"）.toString（）））；

}

}

}

return list；

}

在代碼中定義了findByFileMD5（）方法判斷在已經(jīng)存儲(chǔ)的fileInfo.files集合的記錄中有沒有與將要上傳的檔案文檔的MD5校驗(yàn)碼相同的記錄存在。定義方法findRepeatData（）用來檢查有無重復(fù)上傳檔案文檔上傳者信息，即判斷在usersInfo.user中有沒有重復(fù)的數(shù)據(jù)記錄，這些方法在批量導(dǎo)入數(shù)據(jù)記錄時(shí)也會(huì)調(diào)用逐一判斷。

4 實(shí)驗(yàn)結(jié)果與分析

本實(shí)驗(yàn)使用Hadoop作為分布式文件系統(tǒng)運(yùn)行在不同地理位置的10臺(tái)主機(jī)組成的集群上，在Window7系統(tǒng)中，采用MyEclipse8.5做Java代碼開發(fā)，分布式數(shù)據(jù)庫MongoDB作數(shù)據(jù)存儲(chǔ)，采用的是8核CPU，8 GB內(nèi)存，320 GB硬盤。批量導(dǎo)入使用的是shp文件。shp文件的格式定義同集合文件的格式。對(duì)單個(gè)的文檔上傳進(jìn)行驗(yàn)證無誤外，為了對(duì)更多的數(shù)據(jù)進(jìn)行驗(yàn)證，在shp文件中模擬產(chǎn)生10萬，20萬，30萬數(shù)據(jù)。結(jié)果如圖3所示。

圖3 實(shí)驗(yàn)數(shù)據(jù)測(cè)試結(jié)果圖

該方法在數(shù)據(jù)去重中達(dá)到90%以上，去重效果還比較理想。算法采用的是分布式文件系統(tǒng)，對(duì)文件去重效率較高，且系統(tǒng)具有相應(yīng)的擴(kuò)展性。

5 結(jié) 語

本算法中采用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫MongoDB對(duì)檔案文檔進(jìn)行存儲(chǔ)和去重，利用MongoDB數(shù)據(jù)庫的GridFs來處理不同類型和大小的檔案文檔，統(tǒng)一對(duì)檔案文檔進(jìn)行處理。提出利用了去重的算法思想，并通過實(shí)驗(yàn)?zāi)M測(cè)試去重效果較為理性。該方法具有一定的可行性。為以后大數(shù)據(jù)的存儲(chǔ)的去重有一定的借鑒性。

參考文獻(xiàn)

[1] 雷德龍，郭殿升，陳崇成，等.基于MongoDB的矢量空間數(shù)據(jù)云存儲(chǔ)與處理系統(tǒng)[J].地理信息科學(xué)，2014（7）：508?514.

[2] 吳秀君.面向電子政務(wù)的MongoDB與MySQL混合存儲(chǔ)策略[J].計(jì)算機(jī)與現(xiàn)代化，2014（8）：62?65.

[3] CHODOROW Kristina.MongoDB 權(quán)威指南[M].北京：人民郵電出版社，2010.

[4] 郭武士.基于MongoDB GridFS的圖片存儲(chǔ)方案的實(shí)現(xiàn)[J].四川工程職業(yè)技術(shù)學(xué)院學(xué)報(bào)，2011（4）：41?43.

[5] 衛(wèi)啟云，渠偉勇，黃鴻，等.城市地理編碼的部門信息共享與應(yīng)用實(shí)踐[J].測(cè)繪通報(bào)，2014（10）：101?104.

[6] 陳超，王亮，閆浩文，等.一種基于NoSQL 的地圖瓦片數(shù)據(jù)存儲(chǔ)技術(shù)[J].測(cè)繪科學(xué)，2013（1）：142?143.

[7] MANBER U. Finding similar files in a large file system [C]// Proceedings of the Winter 1994 USENIX Technical Conference. San Fransisco， CA， USA： [s.n.]， 1994： 1?10.

[8] BRODER A Z. On the resemblance and containment of documents [C]// Proceedings of the International Conference on Compression and Complexity of Sequences. Salerno， Italy： [s.n.]， 1997： 21?29.

[9] 孫有軍，張大興.海量圖片文件存儲(chǔ)去重技術(shù)研究[J].計(jì)算機(jī)應(yīng)用與軟件，2014（4）：56?57.

[10] RIVEST R. The MD5 message?digest algorithm [J]. RFC 1321， Internet Engineering Task Force， 1992， 22（1） ： 15?26.

[11] 成功，李小正，趙全軍.一種網(wǎng)絡(luò)爬蟲系統(tǒng)中URL去重方法的研究[J].中國(guó)新技術(shù)新產(chǎn)品，2014（12）：23?24.

[12] 楊祥清.存儲(chǔ)系統(tǒng)數(shù)據(jù)去重策略研究[J].信息通信，2014（8）：132?133.

[13] 高翔，李兵.中文短文本去重方法研究[J].計(jì)算機(jī)工程與應(yīng)用，2014（16）：196?201.