基于分布式NoSQL數據庫的檔案大數據存儲與檢索方案研究

施 曉 峰

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

0 引 言

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

相對于傳統關系型數據庫，分布式NoSQL數據庫性能高、成本低、更靈活，結合分布式系統抗單點故障能力和 NoSQL 的天然水平伸縮性特點，能夠從容應對海量數據的挑戰[2]。

本文通過分析傳統檔案數據管理中存在的問題，以分布式NoSQL數據庫為基礎，制定了可行的檔案大數據存儲與檢索方案，并采用業界當前的主流技術，開發了原型系統進行驗證。

1 檔案大數據的特征

在當前高度信息化的社會環境下，包括檔案行業在內的各個領域都在業務工作中都積累了海量的電子數據。

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

通過分析檔案館的數據資源，我們發現檔案大數據具有以下幾個特征：

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

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

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

此外，在實際業務工作中，檔案館的數據還具有以下特性：

(1) 數據大批量集中寫入多，一旦導入，很少發生更改操作。

(2) 數據之間的關聯關系較少。

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

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

2 檔案數據管理現狀及問題

2.1 結構化數據的存儲模式

檔案的結構化與半結構化數據一般是指檔案的元數據。檔案元數據是一組用來描述數字檔案內容與其他特性的元素集，包括傳統的檔案著錄要素，例如檔號、題名、責任者等，也包括文件的產生背景、形成過程、結構格式等，是組織與管理數字檔案資源的基礎數據。

關系型數據庫具有很強的安全性、良好的數學基礎支撐，在許多需要保證事務一致性的行業，如電信、銀行等的關鍵業務系統中應用廣泛。當前，采用成熟的關系型數據庫，集中存儲和管理檔案元數據是業界的主流模式。

但是隨著社會的發展，檔案的門類不斷擴展，各門類檔案既有統一的管理要求，又有各自個性化的需求，檔案元數據也在不斷地更新與變化，半結構化的趨勢愈加明顯。

關系數據庫的模型不靈活、橫向擴展能力較差，使用傳統關系型數據庫進行檔案檢索正面臨越來越嚴峻的挑戰，檢索速度慢、結果質量低[3]，已經難以滿足數據快速增長帶來的更新和查詢需求了。

2.2 非結構化數據的存儲模式

檔案的非結構化數據主要包括紙質檔案的數字化副本、電子文件歸檔形成的電子檔案、照片、音視頻等。目前，檔案的非結構化數據主要采取以下兩種存儲方式：

(1) 直接將非結構化數據以二進制大對象(BLOB)的形式存儲在關系型數據庫中。采用這種方式的優勢在于可以依靠數據庫自身來保障數據的安全性、事務的一致性等。但其劣勢在于，用關系型數據庫存儲非結構化數據時，不斷增加的文件數量會導致數據庫的體積不斷增大，讀寫性能持續下降。在進行數據庫備份和還原時，速度也會變得非常緩慢。

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

3 相關技術

3.1 MongoDB

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

MongoDB是一款面向文檔的分布式NoSQL數據庫，功能十分豐富，易部署、易使用，并且保留了很多關系型數據庫的特性。MongoDB使用BSON作為數據存儲和傳輸的格式，支持內嵌的文檔對象和數組對象，僅用一條記錄就能表示復雜的層次關系，十分靈活[5]。MongoDB支持集群部署、數據分片，具有高性能、可擴展的特點。

3.2 FastDFS

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

(1) 能夠在不中斷服務的情況下實現存儲的線性擴展。

(2) 提供負載均衡，對文件的訪問可以分散到多個服務節點上。

(3) 避免單點故障，系統中的所有角色都可以采用集群部署，實現冗余。

(4) 文件不分塊，直接存儲在文件系統中，不會加重服務器的工作量，適合小文件存儲。

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

3.3 Elasticsearch

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

Elasticsearch(以下簡稱ES)是一個開源的、分布式搜索分析引擎，基于Java開發并使用Lucene作為其核心來實現索引和搜索的功能，具有近實時、高性能、高可用和易擴展等優點。

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

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

4 方案設計與實現

4.1 總體框架

本方案總體框架底層采用了虛擬化資源池，以提高資源利用效率，實現硬件資源的動態分配、靈活調度，特別適合分布式系統的部署與應用。數據服務層采用MongoDB保存結構化與半結構化的檔案數據，用FastDFS存儲電子文件，用ES實現內容索引與檢索，所有服務均采用集群模式部署，實現整體功能的負載均衡與故障轉移。在通用接口層，通過構建對外統一的數據訪問與查詢接口，簡化上層應用與數據服務層之間的交互流程，如圖1所示。

圖1 總體框架設計

4.2 集群構架

4.2.1MongoDB集群

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

圖2 MongoDB 集群構架

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

Shard：數據分片，每個分片根據規則保存完整數據中的一部分，通常采用副本集(Replica Set)的方式部署以保證安全。本研究采用三成員副本集，每個分片包含一個主數據節點(Primary)和兩個備份節點(Secondary)。主節點負責數據寫入，兩個備份節點與主節點保持數據同步，當主節點發生故障時，其中一個備份節點會升級成主節點。

Mongos：路由服務，只負責把客戶端的數據請求轉發到對應的數據分片上，然后把結果返回到客戶端，本身不存儲數據。Mongos可以配置多個節點以實現冗余。

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

Mongos啟動時從Config Server上獲取基本信息，在接受到客戶端的請求時，路由到分片(Shard)服務器上，然后將返回的數據結果發回給客戶端。

4.2.2FastDFS集群

與其他分布式文件系統相比，FastDFS的構架更加簡潔，只有Tracker Server和Storage Server兩種角色。Tracker Server主要負責負載均衡和任務調度，Storage Server則負責文件數據的存儲。

本方案中，存儲服務集群采用了兩個組(Group1和Group2)，每個組配置了三臺Storage Server，每個Server上的數據完全一致，互為冗余。集群可以通過添加組來實現存儲空間的線性擴展，如圖3所示。

圖3 FastDFS集群構架

跟蹤服務集群配置了三臺Tracker Server同時提供服務，Server之間的關系相互平等，負載均衡，不存在單點故障。

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

此外，在每個Storage Server上還部署了Nginx，解決組內Storage Server同步延遲導致文件暫時無法訪問的問題，同時提供HTTP訪問服務。

4.2.3Elasticsearch集群

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

Master：主節點，主要用于維護集群狀態和配置集群，比如索引的創建與刪除、分片的分配等。

Data：數據節點，保存包含索引的數據分片，負責與數據、搜索與聚合相關的操作，這些操作對CPU、內存和 I/O 資源的消耗較大。

Ingest：轉換節點，執行常見的數據轉換和預處理，如果不需要則無需配置。

默認情況下，一個節點可以同時擔任Master和Data兩種角色，但為了保證集群的可伸縮性，建議不同的類型節點分開部署。本文采用的集群配置如圖4所示。

圖4 Elasticsearch集群構架

設置三個主節點(Master-only)，負責統籌集群層面的事務，維護數據節點的索引和分片。另外規劃三節點的數據集群(Data-only)，專注于索引數據的存儲和面向客戶端的檢索服務。同時，將索引數據分為3個片，每個分片各有2個副本分片作為備份。整個集群實現了負載均衡以及數據冗余，避免了單點故障。

4.3 數據模型設計

在MongoDB中，設計數據模型的關鍵應圍繞文檔的結構和應用程序如何表示數據之間的關聯關系。MongoDB中有兩種方式來表示這些關系：嵌入式文檔和引用。

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

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

{

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

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

″archivesname″:″XXX房地產檔案(產權)″,

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

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

″savetimeout″:″永久″,

″papernumber″:″17″,

″drawnumber″:″6″,

″receiveno″:″200425138XXXX″,

″certificationno″:″浦2004122XXX″,

″owner″:″鄧XX″,

″idno″:″35010254080XXXX″,

″houseplace″:″德平路24弄2X號6XX室″,

″buildarea″:″49.21″

}

將卷內目錄存放在集合Archives_File中，每一條卷內目錄作為一個MongoDB文檔。卷內目錄文檔中保存案卷目錄文檔的acode引用，便于關聯查詢。一條卷內目錄文檔如下：

{

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

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

″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″ //對應電子文件在FastDFS中的索引(FID)

}

卷內目錄對應的電子文件保存在FastDFS文件系統中，文件索引(FID)由組名、虛擬磁盤路徑、數據兩級目錄和文件名組成。

4.4 存儲與檢索流程的實現

4.4.1數據存儲流程

結構化與半結構化的數據按照預先定義的數據模型，通過程序接口保存到MongoDB中。

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

最后，通過mongo-connector將MongoDB中的數據自動同步到ES中，同步過程中elastic2_doc_manager負責將數據寫入到ES，如圖5所示。

圖5 數據存儲流程

4.4.2數據檢索流程

用戶通過客戶端向ES發起查詢請求，ES返回摘要結果，需要查看詳細結果時，通過摘要記錄的ID查找MongoDB數據庫，返回詳細記錄。

需要訪問對應的文件時，根據記錄中保存的文件索引(FID)向FastDFS發起請求，FastDFS通過解析FID，定位到文件所在的存儲服務器組與磁盤目錄，并根據文件名找到相應的文件，最后將文件下載到客戶端，如圖6所示。

圖6 數據檢索流程

4.5 原型系統搭建

原型系統采用虛擬化平臺進行搭建，由于實驗條件限制，使用了2臺PC服務器機，采用簡化設置，共7個節點，配置情況如表1所示。

表1 服務器角色配置表

系統采用PHP進行開發。MongoDB對PHP支持良好，尤其是高并發和schema-free(自由結構)特性，使PHP開發變得更加靈活和高效。

系統主要包括三個功能，如圖7所示。

圖7 系統主界面

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

(2) 數據查詢?？梢葬槍π枰淖侄芜M行模糊檢索并顯示結果列表，如圖8所示。

圖8 數據查詢功能

(3) 數據管理?？梢圆榭匆褜氲臄祿闆r并進行簡單管理。

通過一段時間的測試，原型系統運行穩定，大批量數據的寫入與檢索性能優良，達到了文本的研究目的。

5 結 語

本文首先分析了檔案大數據的特征與存儲現狀，然后通過對相關技術的比較和研究，設計了一套基于分布式NoSQL數據庫的檔案大數據存儲方案，并開發了原型系統進行驗證。

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