基于分布式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) 数据查询。可以针对需要的字段进行模糊检索并显示结果列表，如图8所示。

图8 数据查询功能

(3) 数据管理。可以查看已导入的数据情况并进行简单管理。

通过一段时间的测试，原型系统运行稳定，大批量数据的写入与检索性能优良，达到了文本的研究目的。

5 结 语

本文首先分析了档案大数据的特征与存储现状，然后通过对相关技术的比较和研究，设计了一套基于分布式NoSQL数据库的档案大数据存储方案，并开发了原型系统进行验证。

此方案的系统构建成本低、性能强，同时具有良好的可靠性和可扩展性，适合作为智慧档案馆大数据管理的基础平台，为各类档案信息化应用提供通用、开放的数据存储与检索服务，也为今后模式识别、自然语言理解、应用知识库、可视化展示等大数据技术在智慧档案中的应用提供有力保障。