基于分布式NoSQL數(shù)據(jù)庫的檔案大數(shù)據(jù)存儲(chǔ)與檢索方案研究

施 曉 峰

(浦東新區(qū)檔案局 上海 200135)

0 引 言

隨著檔案館資源體系建設(shè)步伐不斷加快及檔案信息化建設(shè)的不斷深入，數(shù)字檔案資源的種類和容量都在快速增長，呈現(xiàn)出海量、多類型與高價(jià)值的大數(shù)據(jù)特征。新技術(shù)的發(fā)展給檔案大數(shù)據(jù)的管理帶來了新的機(jī)遇和挑戰(zhàn)。如何更好地收集、保管和利用檔案信息，是一個(gè)值得認(rèn)真思考的課題[1]。

相對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫，分布式NoSQL數(shù)據(jù)庫性能高、成本低、更靈活，結(jié)合分布式系統(tǒng)抗單點(diǎn)故障能力和 NoSQL 的天然水平伸縮性特點(diǎn)，能夠從容應(yīng)對(duì)海量數(shù)據(jù)的挑戰(zhàn)[2]。

本文通過分析傳統(tǒng)檔案數(shù)據(jù)管理中存在的問題，以分布式NoSQL數(shù)據(jù)庫為基礎(chǔ)，制定了可行的檔案大數(shù)據(jù)存儲(chǔ)與檢索方案，并采用業(yè)界當(dāng)前的主流技術(shù)，開發(fā)了原型系統(tǒng)進(jìn)行驗(yàn)證。

1 檔案大數(shù)據(jù)的特征

在當(dāng)前高度信息化的社會(huì)環(huán)境下，包括檔案行業(yè)在內(nèi)的各個(gè)領(lǐng)域都在業(yè)務(wù)工作中都積累了海量的電子數(shù)據(jù)。

這些數(shù)據(jù)主要分為三種：第一種是結(jié)構(gòu)化數(shù)據(jù)，可以用二維關(guān)系表結(jié)構(gòu)表示，一般存儲(chǔ)在關(guān)系型數(shù)據(jù)庫中；第二種是半結(jié)構(gòu)化數(shù)據(jù)，例如XML、JSON；第三種是非結(jié)構(gòu)化數(shù)據(jù)，包括各種格式的電子文件(TXT、Word、PDF)、圖片、音頻、視頻等。隨著社會(huì)信息技術(shù)的發(fā)展，檔案館接收的數(shù)據(jù)內(nèi)容也在發(fā)生著變化，半結(jié)構(gòu)和非結(jié)構(gòu)化的數(shù)據(jù)越來越多，各類電子文件、多媒體文件正在成為館藏的重要來源。

通過分析檔案館的數(shù)據(jù)資源，我們發(fā)現(xiàn)檔案大數(shù)據(jù)具有以下幾個(gè)特征：

(1) 格式多樣。既有紙質(zhì)檔案的數(shù)字化副本、接收進(jìn)館的電子文件、檔案著錄信息、OCR的成果文本、聲像資料，也有用戶信息、利用記錄、架體位置等各種業(yè)務(wù)數(shù)據(jù)。

(2) 結(jié)構(gòu)復(fù)雜。檔案目錄數(shù)據(jù)同時(shí)具有結(jié)構(gòu)化和半結(jié)構(gòu)化的特征，每條記錄包含幾十個(gè)字段，有一部分是共用的字段，其他字段則隨著檔案類型的不同而變化。

(3) 規(guī)模龐大。無論是目錄數(shù)據(jù)還是電子文件的數(shù)量，都可達(dá)到千萬級(jí)以上，容量可達(dá)幾十TB。

此外，在實(shí)際業(yè)務(wù)工作中，檔案館的數(shù)據(jù)還具有以下特性：

(1) 數(shù)據(jù)大批量集中寫入多，一旦導(dǎo)入，很少發(fā)生更改操作。

(2) 數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系較少。

(3) 需要支持多種查詢方式，要有很好的查詢性能，但實(shí)時(shí)性和并發(fā)訪問要求不高。

(4) 隨著檔案類別的不斷增多，要求數(shù)據(jù)庫具有很好的可擴(kuò)展性。

2 檔案數(shù)據(jù)管理現(xiàn)狀及問題

2.1 結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)模式

檔案的結(jié)構(gòu)化與半結(jié)構(gòu)化數(shù)據(jù)一般是指檔案的元數(shù)據(jù)。檔案元數(shù)據(jù)是一組用來描述數(shù)字檔案內(nèi)容與其他特性的元素集，包括傳統(tǒng)的檔案著錄要素，例如檔號(hào)、題名、責(zé)任者等，也包括文件的產(chǎn)生背景、形成過程、結(jié)構(gòu)格式等，是組織與管理數(shù)字檔案資源的基礎(chǔ)數(shù)據(jù)。

關(guān)系型數(shù)據(jù)庫具有很強(qiáng)的安全性、良好的數(shù)學(xué)基礎(chǔ)支撐，在許多需要保證事務(wù)一致性的行業(yè)，如電信、銀行等的關(guān)鍵業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛。當(dāng)前，采用成熟的關(guān)系型數(shù)據(jù)庫，集中存儲(chǔ)和管理檔案元數(shù)據(jù)是業(yè)界的主流模式。

但是隨著社會(huì)的發(fā)展，檔案的門類不斷擴(kuò)展，各門類檔案既有統(tǒng)一的管理要求，又有各自個(gè)性化的需求，檔案元數(shù)據(jù)也在不斷地更新與變化，半結(jié)構(gòu)化的趨勢愈加明顯。

關(guān)系數(shù)據(jù)庫的模型不靈活、橫向擴(kuò)展能力較差，使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫進(jìn)行檔案檢索正面臨越來越嚴(yán)峻的挑戰(zhàn)，檢索速度慢、結(jié)果質(zhì)量低[3]，已經(jīng)難以滿足數(shù)據(jù)快速增長帶來的更新和查詢需求了。

2.2 非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)模式

檔案的非結(jié)構(gòu)化數(shù)據(jù)主要包括紙質(zhì)檔案的數(shù)字化副本、電子文件歸檔形成的電子檔案、照片、音視頻等。目前，檔案的非結(jié)構(gòu)化數(shù)據(jù)主要采取以下兩種存儲(chǔ)方式：

(1) 直接將非結(jié)構(gòu)化數(shù)據(jù)以二進(jìn)制大對(duì)象(BLOB)的形式存儲(chǔ)在關(guān)系型數(shù)據(jù)庫中。采用這種方式的優(yōu)勢在于可以依靠數(shù)據(jù)庫自身來保障數(shù)據(jù)的安全性、事務(wù)的一致性等。但其劣勢在于，用關(guān)系型數(shù)據(jù)庫存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)時(shí)，不斷增加的文件數(shù)量會(huì)導(dǎo)致數(shù)據(jù)庫的體積不斷增大，讀寫性能持續(xù)下降。在進(jìn)行數(shù)據(jù)庫備份和還原時(shí)，速度也會(huì)變得非常緩慢。

(2) 將非結(jié)構(gòu)化數(shù)據(jù)通過文件系統(tǒng)直接存儲(chǔ)在文件服務(wù)器中。數(shù)據(jù)文件按一定規(guī)則存放于服務(wù)器的指定目錄下，需要訪問數(shù)據(jù)時(shí)，應(yīng)用系統(tǒng)通過保存在關(guān)系型數(shù)據(jù)庫中的存儲(chǔ)路徑讀取服務(wù)器上的文件。這種模式的可擴(kuò)展性較差，不支持?jǐn)?shù)據(jù)復(fù)制，不具備負(fù)載均衡等特性，文件高并發(fā)訪問性能不理想[4]，容易出現(xiàn)系統(tǒng)瓶頸。隨著檔案數(shù)字資源量劇增、業(yè)務(wù)需求激增，傳統(tǒng)文件系統(tǒng)提供的數(shù)據(jù)存儲(chǔ)能力和性能已經(jīng)不能滿足應(yīng)用的需要，也無法更好地解決海量小文件的索引、查找、統(tǒng)計(jì)、備份等一系列問題。

3 相關(guān)技術(shù)

3.1 MongoDB

NoSQL(Not Only SQL)是對(duì)非傳統(tǒng)關(guān)系型數(shù)據(jù)庫的統(tǒng)稱，具有快速讀寫、動(dòng)態(tài)伸縮、模式靈活、高可靠低成本等特點(diǎn)。主要可以分為以下5類：(1) 鍵值(Key-value)數(shù)據(jù)庫，例如Dynamo、Redis；(2) 面向文檔(Document)數(shù)據(jù)庫，例如MongoDB、CouchDB；(3) 面向列(Column)數(shù)據(jù)庫，例如BigTabe、HBase；(4) 圖形(Graph)數(shù)據(jù)庫，例如AllegroGraph、Neo4j；(5) 多模型(Multi-model)數(shù)據(jù)庫，例如ArangoDB、OrientDB。

MongoDB是一款面向文檔的分布式NoSQL數(shù)據(jù)庫，功能十分豐富，易部署、易使用，并且保留了很多關(guān)系型數(shù)據(jù)庫的特性。MongoDB使用BSON作為數(shù)據(jù)存儲(chǔ)和傳輸?shù)母袷?，支持?nèi)嵌的文檔對(duì)象和數(shù)組對(duì)象，僅用一條記錄就能表示復(fù)雜的層次關(guān)系，十分靈活[5]。MongoDB支持集群部署、數(shù)據(jù)分片，具有高性能、可擴(kuò)展的特點(diǎn)。

3.2 FastDFS

FastDFS是一款開源的分布式文件系統(tǒng)，用C語言編寫，支持Linux、FreeBSD、AIX等UNIX系統(tǒng)[6]，提供文件的存儲(chǔ)、同步、訪問等管理功能，已在包括淘寶、京東、迅雷等眾多國內(nèi)互聯(lián)網(wǎng)公司中得到廣泛應(yīng)用。主要包括以下特性：

(1) 能夠在不中斷服務(wù)的情況下實(shí)現(xiàn)存儲(chǔ)的線性擴(kuò)展。

(2) 提供負(fù)載均衡，對(duì)文件的訪問可以分散到多個(gè)服務(wù)節(jié)點(diǎn)上。

(3) 避免單點(diǎn)故障，系統(tǒng)中的所有角色都可以采用集群部署，實(shí)現(xiàn)冗余。

(4) 文件不分塊，直接存儲(chǔ)在文件系統(tǒng)中，不會(huì)加重服務(wù)器的工作量，適合小文件存儲(chǔ)。

FastDFS較好地解決了海量數(shù)據(jù)冗余備份、負(fù)載均衡、線性擴(kuò)容等問題，部署硬件成本低，非常適合用于管理4 KB至500 MB之間的中小型文件，與檔案館需要存儲(chǔ)海量電子文件的使用場景十分吻合。

3.3 Elasticsearch

檢索服務(wù)是檔案數(shù)據(jù)管理與利用的核心。傳統(tǒng)集中式的檢索方式資源覆蓋面較窄， 資源更新和維護(hù)比較困難，檢索速度也比較緩慢[7]。

Elasticsearch(以下簡稱ES)是一個(gè)開源的、分布式搜索分析引擎，基于Java開發(fā)并使用Lucene作為其核心來實(shí)現(xiàn)索引和搜索的功能，具有近實(shí)時(shí)、高性能、高可用和易擴(kuò)展等優(yōu)點(diǎn)。

ES能夠在很短的時(shí)間內(nèi)完成數(shù)據(jù)索引，提供近乎實(shí)時(shí)的搜索體驗(yàn)；同時(shí)，ES可以把一個(gè)完整的索引進(jìn)行分片(Shards)存儲(chǔ)，均勻分配到各個(gè)服務(wù)節(jié)點(diǎn)上，并對(duì)索引和搜索做負(fù)載均衡； ES還可以設(shè)置多個(gè)索引副本(Replicas)，防止硬件故障造成的數(shù)據(jù)丟失；此外，ES很容易進(jìn)行橫向擴(kuò)展，新增的服務(wù)節(jié)點(diǎn)能夠自動(dòng)地加入集群而無需人工干預(yù)。

目前，很多互聯(lián)網(wǎng)公司都使用ES來搭建自己的搜索系統(tǒng)。比如Github(代碼管理網(wǎng)站)使用 ES對(duì)1 300億行代碼進(jìn)行查詢；Wikipedia(維基百科)使用 ES提供帶有高亮片段的全文搜索[8]；百度目前也廣泛使用ES作為文本數(shù)據(jù)分析，采集服務(wù)器上的各類指標(biāo)數(shù)據(jù)及用戶自定義數(shù)據(jù)，并進(jìn)行多維分析展示，給業(yè)務(wù)工作提供輔助決策。

4 方案設(shè)計(jì)與實(shí)現(xiàn)

4.1 總體框架

本方案總體框架底層采用了虛擬化資源池，以提高資源利用效率，實(shí)現(xiàn)硬件資源的動(dòng)態(tài)分配、靈活調(diào)度，特別適合分布式系統(tǒng)的部署與應(yīng)用。數(shù)據(jù)服務(wù)層采用MongoDB保存結(jié)構(gòu)化與半結(jié)構(gòu)化的檔案數(shù)據(jù)，用FastDFS存儲(chǔ)電子文件，用ES實(shí)現(xiàn)內(nèi)容索引與檢索，所有服務(wù)均采用集群模式部署，實(shí)現(xiàn)整體功能的負(fù)載均衡與故障轉(zhuǎn)移。在通用接口層，通過構(gòu)建對(duì)外統(tǒng)一的數(shù)據(jù)訪問與查詢接口，簡化上層應(yīng)用與數(shù)據(jù)服務(wù)層之間的交互流程，如圖1所示。

圖1 總體框架設(shè)計(jì)

4.2 集群構(gòu)架

4.2.1MongoDB集群

MongoDB的集群一般有主從，副本集和分片三種模式，本文采用了分片集群(Sharded Cluster)的方式，如圖2所示。MongoDB可以通過自動(dòng)將數(shù)據(jù)分散存儲(chǔ)到不同機(jī)器上來實(shí)現(xiàn)數(shù)據(jù)庫的水平擴(kuò)展，這樣只需要增加普通服務(wù)器就可以提高數(shù)據(jù)庫的存儲(chǔ)空間與負(fù)載性能。

圖2 MongoDB 集群構(gòu)架

這種方式主要包括三種角色：Shard、Mongos與Config Server。

Shard：數(shù)據(jù)分片，每個(gè)分片根據(jù)規(guī)則保存完整數(shù)據(jù)中的一部分，通常采用副本集(Replica Set)的方式部署以保證安全。本研究采用三成員副本集，每個(gè)分片包含一個(gè)主數(shù)據(jù)節(jié)點(diǎn)(Primary)和兩個(gè)備份節(jié)點(diǎn)(Secondary)。主節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)寫入，兩個(gè)備份節(jié)點(diǎn)與主節(jié)點(diǎn)保持?jǐn)?shù)據(jù)同步，當(dāng)主節(jié)點(diǎn)發(fā)生故障時(shí)，其中一個(gè)備份節(jié)點(diǎn)會(huì)升級(jí)成主節(jié)點(diǎn)。

Mongos：路由服務(wù)，只負(fù)責(zé)把客戶端的數(shù)據(jù)請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的數(shù)據(jù)分片上，然后把結(jié)果返回到客戶端，本身不存儲(chǔ)數(shù)據(jù)。Mongos可以配置多個(gè)節(jié)點(diǎn)以實(shí)現(xiàn)冗余。

Config Server：配置服務(wù)器，存儲(chǔ)分片集群的元數(shù)據(jù)與配置信息，通常也采用兩副本部署。

Mongos啟動(dòng)時(shí)從Config Server上獲取基本信息，在接受到客戶端的請(qǐng)求時(shí)，路由到分片(Shard)服務(wù)器上，然后將返回的數(shù)據(jù)結(jié)果發(fā)回給客戶端。

4.2.2FastDFS集群

與其他分布式文件系統(tǒng)相比，F(xiàn)astDFS的構(gòu)架更加簡潔，只有Tracker Server和Storage Server兩種角色。Tracker Server主要負(fù)責(zé)負(fù)載均衡和任務(wù)調(diào)度，Storage Server則負(fù)責(zé)文件數(shù)據(jù)的存儲(chǔ)。

本方案中，存儲(chǔ)服務(wù)集群采用了兩個(gè)組(Group1和Group2)，每個(gè)組配置了三臺(tái)Storage Server，每個(gè)Server上的數(shù)據(jù)完全一致，互為冗余。集群可以通過添加組來實(shí)現(xiàn)存儲(chǔ)空間的線性擴(kuò)展，如圖3所示。

圖3 FastDFS集群構(gòu)架

跟蹤服務(wù)集群配置了三臺(tái)Tracker Server同時(shí)提供服務(wù)，Server之間的關(guān)系相互平等，負(fù)載均衡，不存在單點(diǎn)故障。

客戶端在需要時(shí)向Tracker Server發(fā)出請(qǐng)求，獲取到可用的Storage Server地址后，直接與之通信，完成文件的上傳和下載。

此外，在每個(gè)Storage Server上還部署了Nginx，解決組內(nèi)Storage Server同步延遲導(dǎo)致文件暫時(shí)無法訪問的問題，同時(shí)提供HTTP訪問服務(wù)。

4.2.3Elasticsearch集群

在ES 5中，集群的節(jié)點(diǎn)(Node)一般有三種角色:Master、Data和Ingest。

Master：主節(jié)點(diǎn)，主要用于維護(hù)集群狀態(tài)和配置集群，比如索引的創(chuàng)建與刪除、分片的分配等。

Data：數(shù)據(jù)節(jié)點(diǎn)，保存包含索引的數(shù)據(jù)分片，負(fù)責(zé)與數(shù)據(jù)、搜索與聚合相關(guān)的操作，這些操作對(duì)CPU、內(nèi)存和 I/O 資源的消耗較大。

Ingest：轉(zhuǎn)換節(jié)點(diǎn)，執(zhí)行常見的數(shù)據(jù)轉(zhuǎn)換和預(yù)處理，如果不需要?jiǎng)t無需配置。

默認(rèn)情況下，一個(gè)節(jié)點(diǎn)可以同時(shí)擔(dān)任Master和Data兩種角色，但為了保證集群的可伸縮性，建議不同的類型節(jié)點(diǎn)分開部署。本文采用的集群配置如圖4所示。

圖4 Elasticsearch集群構(gòu)架

設(shè)置三個(gè)主節(jié)點(diǎn)(Master-only)，負(fù)責(zé)統(tǒng)籌集群層面的事務(wù)，維護(hù)數(shù)據(jù)節(jié)點(diǎn)的索引和分片。另外規(guī)劃三節(jié)點(diǎn)的數(shù)據(jù)集群(Data-only)，專注于索引數(shù)據(jù)的存儲(chǔ)和面向客戶端的檢索服務(wù)。同時(shí)，將索引數(shù)據(jù)分為3個(gè)片，每個(gè)分片各有2個(gè)副本分片作為備份。整個(gè)集群實(shí)現(xiàn)了負(fù)載均衡以及數(shù)據(jù)冗余，避免了單點(diǎn)故障。

4.3 數(shù)據(jù)模型設(shè)計(jì)

在MongoDB中，設(shè)計(jì)數(shù)據(jù)模型的關(guān)鍵應(yīng)圍繞文檔的結(jié)構(gòu)和應(yīng)用程序如何表示數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系。MongoDB中有兩種方式來表示這些關(guān)系：嵌入式文檔和引用。

以檔案中最常見的數(shù)據(jù)對(duì)象——案卷目錄與卷內(nèi)目錄(按件歸檔時(shí)則為歸檔文件目錄與件內(nèi)文件目錄)為例，兩者為“1”對(duì)“N”的關(guān)系。案卷目錄和卷內(nèi)目錄都可以單獨(dú)進(jìn)行查詢、更新等操作。綜合考慮，這里采用了父引用方式建模。

將案卷目錄存放在集合Archives中, 每一條案卷目錄作為一個(gè)MongoDB文檔。一條案卷目錄的文檔如下：

{

″_id″:ObjectId(″59f470a3e95db40408000029″),

″acode″:″6.D4.7.2004-006331″,

″archivesname″:″XXX房地產(chǎn)檔案(產(chǎn)權(quán))″,

″gatherunit″:″上海市房屋土地資源管理局(浦東新區(qū))″,

″gatherdate″:″2004/11/11″,

″savetimeout″:″永久″,

″papernumber″:″17″,

″drawnumber″:″6″,

″receiveno″:″200425138XXXX″,

″certificationno″:″浦2004122XXX″,

″owner″:″鄧XX″,

″idno″:″35010254080XXXX″,

″houseplace″:″德平路24弄2X號(hào)6XX室″,

″buildarea″:″49.21″

}

將卷內(nèi)目錄存放在集合Archives_File中，每一條卷內(nèi)目錄作為一個(gè)MongoDB文檔。卷內(nèi)目錄文檔中保存案卷目錄文檔的acode引用，便于關(guān)聯(lián)查詢。一條卷內(nèi)目錄文檔如下：

{

″_id″:ObjectId(″59f3de27e95db46408000029″),

″acode″:″6.D4.7.2004-006331″,//案卷級(jí)文檔的引用

″sequenceid″:″2″,

″filecode″:″″,

″person″:″″,

″title″:″封面目錄備考表″,

″datevalue″:″2003/11/5″,

″pageno″:″4″,

″pagecount″:″3″,

″remark″:″″,

″filename″:″6.D4.7.2004-006331_4.tif″,

″filepath″:″group2/M00/00/89/eQ6h3FKfPRl8p4AUz4wO8tqaA688.tif″ //對(duì)應(yīng)電子文件在FastDFS中的索引(FID)

}

卷內(nèi)目錄對(duì)應(yīng)的電子文件保存在FastDFS文件系統(tǒng)中，文件索引(FID)由組名、虛擬磁盤路徑、數(shù)據(jù)兩級(jí)目錄和文件名組成。

4.4 存儲(chǔ)與檢索流程的實(shí)現(xiàn)

4.4.1數(shù)據(jù)存儲(chǔ)流程

結(jié)構(gòu)化與半結(jié)構(gòu)化的數(shù)據(jù)按照預(yù)先定義的數(shù)據(jù)模型，通過程序接口保存到MongoDB中。

文件對(duì)象通過程序接口直接上傳到FastDFS，服務(wù)器會(huì)將文件的索引(FID)返回給客戶端，客戶端再將FID寫入MongoDB對(duì)應(yīng)的記錄中，用于以后該文件的訪問。

最后，通過mongo-connector將MongoDB中的數(shù)據(jù)自動(dòng)同步到ES中，同步過程中elastic2_doc_manager負(fù)責(zé)將數(shù)據(jù)寫入到ES，如圖5所示。

圖5 數(shù)據(jù)存儲(chǔ)流程

4.4.2數(shù)據(jù)檢索流程

用戶通過客戶端向ES發(fā)起查詢請(qǐng)求，ES返回摘要結(jié)果，需要查看詳細(xì)結(jié)果時(shí)，通過摘要記錄的ID查找MongoDB數(shù)據(jù)庫，返回詳細(xì)記錄。

需要訪問對(duì)應(yīng)的文件時(shí)，根據(jù)記錄中保存的文件索引(FID)向FastDFS發(fā)起請(qǐng)求，F(xiàn)astDFS通過解析FID，定位到文件所在的存儲(chǔ)服務(wù)器組與磁盤目錄，并根據(jù)文件名找到相應(yīng)的文件，最后將文件下載到客戶端，如圖6所示。

圖6 數(shù)據(jù)檢索流程

4.5 原型系統(tǒng)搭建

原型系統(tǒng)采用虛擬化平臺(tái)進(jìn)行搭建，由于實(shí)驗(yàn)條件限制，使用了2臺(tái)PC服務(wù)器機(jī)，采用簡化設(shè)置，共7個(gè)節(jié)點(diǎn)，配置情況如表1所示。

表1 服務(wù)器角色配置表

系統(tǒng)采用PHP進(jìn)行開發(fā)。MongoDB對(duì)PHP支持良好，尤其是高并發(fā)和schema-free(自由結(jié)構(gòu))特性，使PHP開發(fā)變得更加靈活和高效。

系統(tǒng)主要包括三個(gè)功能，如圖7所示。

圖7 系統(tǒng)主界面

(1) 數(shù)據(jù)導(dǎo)入。支持Access數(shù)據(jù)文件與TIFF圖像的導(dǎo)入，一次可以導(dǎo)入幾萬或者十幾萬條，容量達(dá)到幾GB甚至幾十GB。

(2) 數(shù)據(jù)查詢。可以針對(duì)需要的字段進(jìn)行模糊檢索并顯示結(jié)果列表，如圖8所示。

圖8 數(shù)據(jù)查詢功能

(3) 數(shù)據(jù)管理?？梢圆榭匆褜?dǎo)入的數(shù)據(jù)情況并進(jìn)行簡單管理。

通過一段時(shí)間的測試，原型系統(tǒng)運(yùn)行穩(wěn)定，大批量數(shù)據(jù)的寫入與檢索性能優(yōu)良，達(dá)到了文本的研究目的。

5 結(jié) 語

本文首先分析了檔案大數(shù)據(jù)的特征與存儲(chǔ)現(xiàn)狀，然后通過對(duì)相關(guān)技術(shù)的比較和研究，設(shè)計(jì)了一套基于分布式NoSQL數(shù)據(jù)庫的檔案大數(shù)據(jù)存儲(chǔ)方案，并開發(fā)了原型系統(tǒng)進(jìn)行驗(yàn)證。

此方案的系統(tǒng)構(gòu)建成本低、性能強(qiáng)，同時(shí)具有良好的可靠性和可擴(kuò)展性，適合作為智慧檔案館大數(shù)據(jù)管理的基礎(chǔ)平臺(tái)，為各類檔案信息化應(yīng)用提供通用、開放的數(shù)據(jù)存儲(chǔ)與檢索服務(wù)，也為今后模式識(shí)別、自然語言理解、應(yīng)用知識(shí)庫、可視化展示等大數(shù)據(jù)技術(shù)在智慧檔案中的應(yīng)用提供有力保障。