基于 Hibernate搜索的数据库全文检索系

1
概述 数据库与全文检索系统的部署不同步，或是由于某些原因造

Internet中 80%的数据是属于网络隐藏的，虽然网络隐藏成索引库文件丢失时，手动模式可以依据数据库中数据恢复
的数据可以被访问，但却难以被搜索引擎检索，这些网络隐Lucene索引库。
藏的数据大多被存储在关系数据库中 [1]。而关系数据库本身(2)数据处理模块：它与索引更新模块有着紧密的联系，

提供的检索服务还有很多不足，例如：受分词技术的制约，主要负责对 Lucene不能直接处理的数据进行预处理工作，以

其全文检索服务不能很好地支持中文。对于存储在数据中的及提取数据中与数据处理相关联的信息。数据处理模块主要
非结构化数据，如采用二进制格式存储的文本文件，可能是 由处理桥 (HandlerBridge)构成，数据通过这些处理桥的处理
PPT, PDF或 Excel等多种类型，这些文件中的有用文本信息便能交予 Lucene建立索引了。
难以直接获取，数据库针对其内容提供的检索服务十分有限(3)查询模块：主要负责提供查询服务。查询模块依据外

且不易扩展。
部提供的查询参数，调用如日期、域内容、二次查询等相应

Hibernate搜索(Hibernate Search)是 Hibernate提供的一种的过滤器得到正确的查询结果。
开源的数据库检索工具。 Hibernate Search通过简单的设置和数据库全文检索系统的总体架构如图 1所示。
通用的 API，为数据持久域模型以及相应的 Hibernate框架[2]
提供全文检索支持。其内部调用 Apache Lucene[3]，提供了对
传统 Lucene API的支持，并且弥补了 Lucene在为复杂的对
象域模型建立索引时，难以应对诸如建立时间索引、处理索
引结构与对象域模型不匹配、查询不匹配等缺陷[4]。

本文针对现有数据库全文检索服务的不足，通过采用
Hibernate Search等技术设计了一个能较好支持中文的、易于
扩展的数据库全文检索系统。

2
系统总体架构
数据库全文检索系统主要包括以下 3个模块：

数据库
Lucene
索引库
DocumentDocumentDocument Search
索引更新查询
Time
Index
查询过滤器 HandlerBridge
Word PPTPDF
Hibernate
+
Hibernate Search
(1)索引更新模块：主要有自动和手动 2种工作模式。在
自动模式下，索引更新模块主要负责监听外部通过 Hibernate
对数据库的访问。当数据库中的数据发生更改时，索引更新
模块通过调用相应的事件处理器对 Lucene的索引库进行同
步更新。手动模式是对自动模式在特殊情况下的补充。手动
模式与自动模式的最大区别在于，在手动模式下建立索引无
需通过 Hibernate的事件监听器，而直接由用户进行操作。当
图 1 数据库全文检索系统的总体架构

 

3 相关技术细节

3.1 映射关系的建立
要实现通过
Lucene API对数据库的全文检索，就必须为
Lucene索引库中
Document与
Hibernate框架中的
POJO(Plain
Old Java Object)类建立映射关系。
Hibernate ORM与
Lucene
全文索引库之间的区别与联系如下：

(1)业务所要使用到的基础数据单元：1)Hibernate ORM：
对象持久化得到的
POJO(对应关系数据库中的记录)；
2)Lucene索引：
Document逻辑文件对象
(对应实际的物理
文件)。
(2)基础数据单元的组成结构：
1)Hibernate ORM：每个
POJO中包含有许多属性(对应关系数据库中单个记录的许多
字段)；2)Lucene索引：每个
Document包含很多
Field(这些
域对应物理文件的文件名、文件内容、创立时间等信息
)。
(3)针对数据单元提供的
CRUD操作：1)Hibernate ORM：
为持久化的
POJO提供了
update(), insert(), delete()等操作；
2)Lucene索引：提供了
addDocument(), delete()等增减
Document逻辑文件的操作。
(4)查询得到的结果集：1)Hibernate ORM：List容器存放
包含所要查询关键字的
POJO集；2)Lucene索引：Hits保存
有按由关键字相似度排序的
Document对象集。
由此可知，如果将
Hibernate关系映射框架中的
POJO与
Lucene索引库中的
Document对象建立映射关系，便可以实
现对数据库的全文检索。

以
POJO持久类
File为例，为其建立映射的代码如下：
@Entity
@Indexed
public class File {
@Id
@DocumentId
private Integer id;
@Field(index=Index.TOKENIZED, store=Store.YES)
@FieldBridge(impl=org.yankee.demo.bridge.NameBridge.class)
private String name;
@Field(index=Index.TOKENIZED, store=Store.NO)
@FieldBridge(impl=org.yankee.demo.bridge.HandlerBridge.class)

private byte[] content;
.}
如果去掉代码中“
@”定义的标签，则上述代码只是一

个普通的
POJO类。加上这些标签以后，
POJO对象本身及其
所包含的属性都与
Lucene中
Document对象及其所包含的
Field建立了一一对应的映射关系。其中主要标签的意义为：
@Indexed声明当前
POJO对象要被检索；@Id声明了当前
POJO对象的主键与
Document中的
DocumentId的匹配，通
过这种匹配，系统就可以查找到
Lucene索引库中
Document
对象所对应的
POJO；@Field声明了当前属性与
Document
中
Field的对应关系。通过上述设置，将数据库表中的记录与
Lucene索引库中的
Document建立关联，如图
2所示。

数据库中的
File表
Id( PM ) |name| content
.

Hibernate POJO File
Class File {
int id;
String name;
byte [ ] content
…}
Lucene Document
Field:DocumentID
图
2 关系数据库与
Lucene索引库的映射关系

3.2 大字段检索
数据库本身难以提供对非结构化数据的检索服务，这些
非结构化数据大多按二进制大字段格式存储，按其性质主要
分为
2类：(1)不可检索的文件，如视频、音频、图片等；

(2)可检索而数据库难以提供检索服务的文件，如
PPT, PDF,
Excel等文本文件，这一类数据是数据库全文检索的重点。
前文定义了
File的
Hibernate POJO类，Hibernate框架中
的
File类对应着数据库中的文件表。当要对数据库中存储的
文件建立索引时，系统先通过
Hibernate获取到文件所对应的
POJO对象，再依据
File类中定义的标签对对象中的不同属
性采取相应的处理方式。由于数据库中存储的文件格式多种
多样，因此系统先要判断出当前文件的所属类型。文件数据
处理过程如图
3所示。

Hibernate POJO File
Class File {
int id;
String name;
byte [ ] content;
.}
NamBridge
HandlerBridge
WordHandlerBridge
ExcelHandlerBridge
PDFHandlerBridge Type
Type？
Lucene
Document
图
3 文件数据处理过程

根据在
File类中@FieldBridge的设置，系统通过
Name
Bridge对象获取到所要检索文件的文件名并提取文件的类型
参数(filetype)，由于
HandlerBridge继承自
Namebridge，因此
HandlerBridge对象可以得到当前文件类型。如果文件是不可
检索的类型，则返回一个空串；否则根据文件的具体类型，
如
PDF, Excel等调用相应的
PDFHandlerBridge, ExcelHandler
Bridge等处理桥进行处理。

例如，当
ExcelHandlerBridge接收到传输给它的二进制
信息时，转换桥会先将这些二进制信息转换为字符串数据。
根据
Excel文件的结构，转换桥会逐个提取其中的
Sheet，对
于文件中的每一个
Sheet，按行和列的顺序读取其中非空
Cell
小方格中的文本数据。通过这样的处理，系统便得到了以二
进制格式存储的
Excel文件中的文本信息，并将文本信息交
予
Lucene建立索引。
Lucene索引建立之后，系统便能通过
查找索引实现全文检索。

为了能提供对多种格式文本文件的全文检索需要，在
Apache以及其他开源组织提供的
API基础上，笔者为系统开
发了支持
PDF, Excel, PPT等格式的处理桥。根据实际需要，
通过扩展桥的种类，系统也可以提供对其他类型文件的支持。

3.3 中文分词
为了让全文检索工具能够较好地支持中文，采用成熟的
中文分词器是必不可少的。在建立索引的过程中，为了能满
足中英文混合查询的需要，系统采用了中科院的
JE-Analysis
分词器作为
Lucene API建立索引时的默认分析器。这种分词
器采用正向最大匹配算法进行中文分词。机械匹配式的切分
词方法已经相当成熟了，其中最大匹配算法是机械匹配式切
分词方法的代表算法，该算法已被国内很多研究机构采用
[5]。
通过采用成熟的中文分词工具，全文检索系统便可以较好地
支持中文。在实际使用中根据应用需要，通过修改配置文件
系统也能够采用其他更适合的分词工具。

3.4 倒排索引的建立与更新
数据库全文检索的对象是数据库中的数据。数据库作为
信息存储的核心，其存储的数据更新频繁，因此，要实现对

—75—

数据库的全文检索就要保持索引库与数据库间的同步更新。

在
Hibernate上配置事件监听器可以有效捕捉数据库的
更新。通过在
hibernate.cfg.xml配置文件上配置
update, insert,
delete 3类事件的监听器及其事件处理对象，便能在数据库中
的数据改变时对
Lucene索引库进行同步更新。索引库的更新
操作主要包括以下
2个方面：

(1)建立
Lucene索引：当数据库中有新的数据被插入时，
设置在
Hibernate中的事件监听器便可以捕捉到这一事件，通
过事件处理对象调用
Lucene API，建立对应的
Document对
象并存储在索引库中。
(2)删除
Lucene索引：利用
Hibernate Search技术所建立
的映射关系，通过事件监听器，当数据库中的文件表项被删
除时，系统便会同步删除索引库中对应主键的
Document。
3.5
数据查询
系统最初的查询对象是
Lucene索引，当用户输入关键字
并选择了相应的查询条件后，系统根据对应的查询条件调用
过滤器处理并返回正确结果。要对某个
POJO类使用过滤器，
需要在该
POJO类中写入标签，指明该类将会用到的过滤器，
代码如下：

@FullTextFilterDefs ({

 @FullTextFilterDef(name = "keywordFilter",

impl = KeywordFilterFactory.class),

@FullTextFilterDef(name = "dateFilter",

impl = DateFilterFactory.class),

.})

过滤器可以对查询的结果进行限制，如对文件上传日期
的过滤，对某个域的内容进行过滤等。常用的过滤器有日期
过滤器、域内容过滤器以及二次查询过滤器。

(1)日期过滤器：系统实现的日期过滤器继承自
Lucene
的
RangeFilter，通过设置天数来限制查询结果。当用户想查
找最近一个月内的文件，只需设置过滤条件为
30天，也可以
通过输入起始时间和终止时间来限制得到某段时间内相应的
结果。
(2)域内容过滤器：通过输入域名称和过滤关键字来进行
过滤。当用户希望搜索结果的文件名中带有“
book”这个单
词，则设置域过滤器域名称为“filename”，域关键字为“book”。
通过域内容过滤器也可以实现结果保密性的过滤，只需在对
应的
POJO类中增加一个保密性的域，并指定保密程度。搜
索时根据不同用户的权限来过滤可搜索的范围。
(3)二次查询过滤器：如果用户希望在某次搜索的结果中
进行再搜索，则需要二次查询过滤器。通过将上一次搜索的
关键字和条件作为过滤器的条件进行设置，则第
2次查询的
范围会被限制在第
1次查询的结果之内。另外也可以对一个
查询同时使用多个过滤器。在实际过程中，还可以根据需要
开发更多的过滤器。
过滤器在实际查询中的调用顺序由于采用的是交集，因
此，对查询结果没有影响，但对查询的效率会有一定影响。
查询时应该根据查询条件，尽量先采用能够一次性过滤最多
数据项的过滤器，其次采用能过滤次多数据项的过滤器，以
此类推。系统通过过滤器获得需要的查询结果后，再根据结
果集中的
Documented获取对应的
Hibernate POJO集。

4
实验分析
在数据库全文检索系统的基础上，使用实现的系统和直
接采用
Lucene API这
2种方式，分别对存储在数据库和存放

在硬盘目录上不同大小的纯文本
Word文档建立索引并进行
对比。实验的硬件设备为：
CPU AMD 3800+双核，主频
2.0 GHz，内存
DDR2667, 1 GB，硬盘
7 200转。实验采用
MySQL5.0数据库以及相同的分词器。实验结果数据见表
1。
表
1 文件建立索引的实验对比结果

建立索引的时间
/ms

Word文档大小
/KB
Disk Database

28 1 140 1 453
68 1 235 1 438
161 1 266 1 875
265 1 422 1 735
445 1 313 1 672
861 1 359 1 907
1 511 1 453 1 953
3 631 2 031 3 047
5 887 1 734 3 718
8 838 2 297 4 500

表
1中的
Disk行表示直接采用
Lucene API对存储在硬
盘文件目录不同大小
Word文档建立索引的时间；
Database
行表示采用所实现的数据库全文检索模块对存储在数据库中
相对应
Word文档建立索引的时间。对比实验中的数据源都
是相同的
Word文档集，只是文档的存储方式不同。

实验表明，同样采用
Lucene API作为检索引擎的核心，
数据源为
Word文档时，对硬盘文件目录建立索引的效率要
比系统对数据库建立索引的效率高，并且随着数据源增大对
数据库文件建立索引的时间消耗增长更明显。

对数据库建立索引时效率较低，主要是由数据库的存取
方式决定的，但是这种效率上的差距并不影响对关系数据库
建立索引的意义。因为对数据库建立索引并实现对数据库全
文检索是对数据库存储优势的进一步补充，且文献
[6]实验证
明，通过对数据库建立
Lucene索引能有效提高数据挖掘的
效率。

5
结束语

本文结合
Hibernate Search技术及
Lucene等开源工具，
实现了一个能对关系数据库中的数据进行全文检索的原型。
该原型能满足对数据库中的结构化数据以及多种文本类型的
非结构化数据的检索需要，在权限允许的条件下可以提供安
全高效的站内数据库检索服务。
Hibernate与
Lucene相结合，
可以充分发挥两者的优势，确保了检索的高效性，实现了索
引库与数据库的同步。

参考文献

[1] Bohlen M, Bukauskas L, Dyreson C. The Jungle Database Search
Engine[C]//Proc. of the ACM SIGMOD International Conf. on
Management of Data. San Diego, California, USA: [s. n.], 1999.
[2] Bauer C, King G. Hibernate in Action[M]. Greenwich, CT, USA:
Manning Publications Co., 2005.
[3] Hatcher E, Gospodnetic O. Lucene in Action[M]. Greenwich, CT,
USA: Manning Publications Co., 2005.
[4] Hibernate. Hibernate Search[Z]. (2008-01-01). http://www. hibernate.
org/410.html.
[5]
张滨, 李文翔, 夏德麟
, 等. 基于汉语句模的中文分词算法
[J].
计算机工程
, 2004, 30(1): 1-3.
[6]
Zhou Ning, Wu Jiaxin, Zhang Shaolong. Mining Weighted
Association Rules with Lucene Index[C]//Proc. of WiCom’07.
Shanghai, China: [s. n.], 2007.