您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
集成Lucene和HBase
 
作者:Boris Lublinsky 来源:InfoQ 发布于   2016-6-12
来自于要资料   548 次浏览     评价:      
 

在所有先进的应用程序中,不管是购物站点还是社交网络乃至风景名胜站点,搜索都扮演着关键的角色。Lucene搜索程序库事实上已经成为实现搜索引擎的标准。苹果、IBM、Attlassian(Jira)、Wolfram以及很多大家喜欢的公司【1】都使用了这种技术。因此,大家对任何能够提升Lucene的可伸缩性和性能的实现都很感兴趣。

Lucene简介Lucene中可搜索的实体都表现为文档(document),它由字段(field)和值(value)组成。每个字段值都由一个或多个可搜索的元素——即词汇(term)——组成。Lucene搜索基于反向索引,其中包含了关于可搜索文档的信息。在使用正常索引时,你可以搜索文档,以了解它包含哪些字段,但使用反向索引与之不同,你会搜索字段的词汇,以了解所有包括该词汇的文档。

图1显示的是高层次的Lucene架构【2】。它的主要组件包括IndexSearcher、IndexReader、IndexWriter 和Directory。IndexSearcher实现了搜索逻辑。IndexWriter为每个插入的文档写入反向索引。IndexReader会在IndexSearcher的支持下读取索引的内容。IndexReader和IndexWriter都依赖于Directory,它会提供操作索引数据集的API,而该API会直接模拟文件系统API。

图1: 高层次的Lucene架构

标准的Lucene分发包中有多个目录实现,包括基于文件系统和基于内存的[1]。

相关厂商内容

海量服务架构:虽千万人,吾往矣 创业者故事=苟且+诗和远方? 云下的支撑:探索更稳固的架构 你离成为一位合格的技术领导者还有多远? 证券行业的Docker应用实践 相关赞助商

ArchSummit深圳2016将于07月15-16日在华侨城洲际大酒店举行,现价9折抢购,团购报名更多优惠!

标准基于文件系统的后端的缺点在于,随着索引增加性能会下降。人们使用了各种不同的技术来解决这个问题,包括负载均衡和索引分片(index sharding)——在多个Lucene实例之间切分索引。尽管分片功能很强大,但它让总体的实现架构变得更复杂,并且需要大量对期望文档的预测知识,才能对Lucene索引进行合适地分片。

另一种不同的方法是,让索引后端自身对数据进行正确地分片,并基于这样的后端构建出实现。这种后端可以是NoSQL数据库。在本文中我们会描述基于HBase的实现【4】。

实现方法

正如在【3】中所说明的,在高层次上,Lucene会操作两个单独的数据集: 索引数据集中保存了所有字段/词汇对(还有其他信息,像术语频率、位置等),以及在恰当的字段包含这些词汇的文档。 文档数据集中存储所有文档,包括存储的字段等。 正如我们已经在上面提到的,想要把Lucene移植到新的后端中,直接实现directory接口并不总会是最简单(最方便)的方法。所以,很多对Lucene的移植,包括从Lucene的contrib.module支持的优先内存索引、Lucandra【5】和HBasene【6】分别采用了不同的方法【2】,不仅重写了directory,还重写了高级的Lucene类——IndexReader和IndexWriter,从而绕开了Directory的API(如图2)。

图2: 将Lucene和没有文件系统的后端整合

尽管这种方法通常需要更多工作【2】,但是它能够带来更强大的实现,让我们可以完全利用后端的本地功能。

文中所展现的实现[2]也遵循了这种方法。

总体架构

总体上的实现(如图3)是在基于内存的后端之上构建的,并将其用作内存缓存、同步缓存和HBase后端的机制。

图3: 基于HBase的Lucene实现的总体架构

该实现试图平衡两种相互冲突的需求,性能: 在内存中,缓存能够最小化HBase用于搜索和文件返回的数据读取量,从而极大提升性能;可伸缩性: 按照需要运行为多个Lucene示例以支持日益增长的搜索客户端的能力。后者需要最小化缓存的生命周期,从而和HBase实例(上面提到实例的副本)中的内容同步。通过为活动参数实现可配置的缓存时间,限制每个Lucene实例中展现的缓存,我们可以达成一种折中方案。

内存缓存中的底层数据模型

正如之前所提到的,内部Lucene数据模型基于两种主要的数据集——索引和文档,它们会被实现为两种模型——IndexMemoryModel和DocumentMemoryModel。在我们的实现中,读写操作(IndexReader/IndexWriter)都是通过内存缓存完成的,但是它们的实现有很大区别。对于读取操作,缓存首先会检查所需要的数据是否在内存中,并且没有过期[3],如果那样的话就会直接使用。否则缓存就会从HBase读取或者刷新数据,然后把它返回给IndexReader。相反,对于写操作,数据会直接写入到HBase,而不会在内存中存储。尽管这在实际的数据可用性方面会有延迟,但是它会让实现过程非常简单——我们不需要考虑把新建或者更新的数据发送给哪个缓存。这里的延迟可以通过设置合适的缓存过期时间来控制,从而符合业务需求。

IndexMemoryModel索引内存模型的类图如图4所示。

图4: IndexMemoryModel类图

在这个实现中:

LuceneIndexMemoryModel类包含了当前存在于内存中所有字段的FieldTermDocuments类。它还提供了所有对于实现IndexReader和IndexWriter必要的内部API。

FieldTermDocuments类会为每个字段值管理TermDocuments。通常,对于可扫描的数据库,字段的列表和字段值的列表可以组合在可导航的字段/词汇值列表中。对于基于内存的缓存实现,我们已经把它们切分为两个独立的部分,从而让搜索的时间更可预测。

TermDocuments类为每个文档ID包含了一系列TermDocument类。

TermDocument类包含了针对给定文档在索引中存储的信息——文档使用频度和位置的数组。

DocumentMemoryModel文档内存模型的类图如图5所示。

图5: DocumentMemoryModel类图

在这个实现中:

LuceneDocumentMemoryModel类包含DocumentStructure类与每个被索引文档的映射关系。

DocumentStructure类中包含了单个文档的信息。针对每个文档,它都包含了为每个索引后字段保存的字段和信息。

FieldData类包含为存储字段(stored field)所保存的信息,包括字段名称、值和二进制或者字符串型的标识。

DocumentTermFrequency类包含了关于每个被索引字段的信息,包括对相应索引结构(索引、词汇)的向后引用、文档中词汇使用频率、词汇在文档中的位置以及从文档开始的偏移量。

LuceneDocumentNormMemoryModel

正如在【9】中说明的,规范(norm)是用于表现文档或字段的加权因子,从而提供更好的搜索结果排序,这需要耗费大量内存。类的实现基于对映射的映射(map of maps),内部映射会存储规范和文档的映射关系,而外部映射会存储规范和字段的映射关系。

尽管规范信息的键值是字段名称,从而可以添加到LuceneIndexMemoryModel类中,但是我们还是决定把对规范的管理实现为单独的类——LuceneDocumentNormMemoryModel。这么做的原因在于,在Lucene使用规范是可选的操作。

IndexWriter

有了之前所描述的底层内存模型,实现索引写入程序就很简单了。因为Lucene不会定义IndexWriter接口,所以想要实现IndexWriter,我们需要实现所有标准Lucene实现中的方法。这个类的主要内容在于addDocument方法。这个方法会遍历所有文档的字段。对于每个字段,方法都会检查它是否可以令牌化(tokenized),并使用特定的分析器来做到这一点。这个方法还会更新所有三种内存结构——索引、文档和(可选的)规范,它们会为新增的文档存储信息。

IndexReader

IndexReader会实现Lucene核心所提供的IndexReader接口。因为Hbase中所获得的列表和单独的读操作相比要快很多,所以我们使用一些方法来扩展这个类,从而可以读取多个文档。类本身没有把更多的处理转交给几个类,它会对其进行管理:

尽管文档ID通常是字符串,但Lucene内部还是对整型数操作。DocIDManager这个类会负责管理从字符串到数字的转换。IndexReader会以ThreadLocalStorage的形式使用这个类,从而可以在线程结束之后自动清理。

MemoryTermEnum类扩展了Lucene提供的TermEnum类,负责扫描字段/词汇的值。

MemoryTermFrequencyVector类会实现Lucene提供的TermDocs和TermPositions接口,负责为给定的字段/词汇对(field/tem pair)处理与文档相关的信息。

MemoryTermFrequencyVector类实现了Lucene提供的TermFreqVector和TermPositionVector接口,负责针对给定的文档ID返回文档字段频率和位置信息。

HBase表以上提出的解决方案基于两个主要的HBase表——Index表(图6)和document表(图7)。

图6: HBase的Index表

(点击图像可以放大)

图7: HBase的document表

如果需要支持规范的话,可选择实现第三个表(图8)。

图8: HBase的norm表

HBase的Index表(图6)会完成实现的主要工作。这个表对每个Lucene实例所知道的字段/词汇组合都设置了入口,其中包含一个列族(column family)——documents族。这个列族为包含这个字段或词汇的所有文档都包含了一列(名称是文档的ID)。每个列的内容都是TermDocument类的值。

HBase的document表(图7)存储了文档本身、对索引或规范的向后引用,它会为文档处理引用这些文档以及一些Lucene使用的附加信息。它对所有Lucene实例知道的文档都设置了入口(row)。每个文档都通过文档ID(键值)唯一标识,并包含两个列族——字段族和索引族。字段列族针对所有存储在Lucene中的文档字段包含一列(名称为字段的名称)。列的值是值的类型(字符串或者字符数组)和值本身的组合。索引列族为每个引用这个文档的索引包含了一列(名称是字段或者术语)。列的值包括给定字段/词汇在文档的使用频率、位置和偏移量。

HBase的norm表(图8)为每个字段存储了文档的规范。它对所有Lucene实例知道的每个字段(键值)都设置了入口(行)。每行都只包含一个列族——规范族。这个族对每个需要存储给定字段规范的文档都有一列(名称是文档ID)。

数据格式

最终的设计方案确定了在HBase中存储数据的数据格式。对于这个实现,我们基于性能、结果数据的最小规模以及和Hadoop的紧密整合程度选择了Avro【10】。

实现主要使用的数据结构是TermDocument(代码1)、文档的FieldData(代码2)和DocumentTermFrequency(代码3)。

{
"type" : "record",
"name" : "TermDocument",
"namespace" : "com.navteq.lucene.hbase.document",
"fields" : [ {
"name" : "docFrequency",
"type" : "int"
}, {
"name" : "docPositions",
"type" : ["null", {
"type" : "array",
"items" : "int"
}]
} ]
}

代码1 词汇文档AVRO定义

{
"type" : "record",
"name" : "FieldsData",
"namespace" : "com.navteq.lucene.hbase.document",
"fields" : [ {
"name" : "fieldsArray",
"type" : {
"type" : "array",
"items" : {
"type" : "record",
"name" : "singleField",
"fields" : [ {
"name" : "binary",
"type" : "boolean"
}, {
"name" : "data",
"type" : [ "string", "bytes" ]
} ]
}
}
} ]
}

代码2 字段数据AVRO定义

{
"type" : "record",
"name" : "TermDocumentFrequency",
"namespace" : "com.navteq.lucene.hbase.document",
"fields" : [ {
"name" : "docFrequency",
"type" : "int"
}, {
"name" : "docPositions",
"type" : ["null",{
"type" : "array",
"items" : "int"
}]
}, {
"name" : "docOffsets",
"type" : ["null",{
"type" : "array",
"items" : {
"type" : "record",
"name" : "TermsOffset",
"fields" : [ {
"name" : "startOffset",
"type" : "int"
}, {
"name" : "endOffset",
"type" : "int"
} ]
}
}]
} ]
}

代码3 TermDocumentFrequency的AVRO定义

结论本文中描述的简单实现完全支持所有Lucene功能,针对Lucene核心和普通模块的单元测试都验证了这一点。我们可以将它作为基础,构建可扩展性很强的搜索实现,支持HBase固有的可扩展性以及完全对称的设计,让我们可以添加任意数量服务于HBase数据的进程。它还可以避免需要关闭打开状态的Lucene索引读取程序,就可以包含新的索引数据,那会经过一定延迟之后为用户所用,而延迟是通过活动参数的缓存时间所控制的。在下一篇文章中我们会展示如何扩展这个实现,以包含地理搜索支持。

 

   
 订阅
  捐助
相关文章 相关文档 相关课程



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
 

APP推广之巧用工具进行数据分析
Hadoop Hive基础sql语法
应用多级缓存模式支撑海量读服务
HBase 超详细介绍
HBase技术详细介绍
Spark动态资源分配
更多...   

Hadoop与Spark大数据架构
Hadoop原理与高级实践
Hadoop原理、应用与优化
大数据体系框架与应用
大数据的技术与实践
Spark大数据处理技术

领先IT公司 android开发平台最佳实践
北京 Android开发技术进阶
某新能源领域企业 Android开发技术
某航天公司 Android、IOS应用软件开发
阿尔卡特 Linux内核驱动
艾默生 嵌入式软件架构设计
西门子 嵌入式架构设计
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号