在所有先进的应用程序中,不管是购物站点还是社交网络乃至风景名胜站点,搜索都扮演着关键的角色。Lucene搜索程序库事实上已经成为实现搜索引 擎的标准。苹果、IBM、Attlassian(Jira)、Wolfram以及很多大家喜欢的公司【1】都使用了这种技术。因此,大家对任何能够提升 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]。
标准基于文件系统的后端的缺点在于,随着索引增加性能会下降。人们使用了各种不同的技术来解决这个问题,包括负载均衡和索引分片(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,而不会在内存中存储。尽管这在实际的数据可用性方面会有延迟,但是它会让实现过程非常简单——我们不需要考虑把新建或者更新的数据发送给哪个 缓存。这里的延迟可以通过设置合适的缓存过期时间来控制,从而符合业务需求。
索引内存模型的类图如图4所示。
图4: IndexMemoryModel类图
在这个实现中:
文档内存模型的类图如图5所示。
图5: DocumentMemoryModel类图
在这个实现中:
正如在【9】中说明的,规范(norm)是用于表现文档或字段的加权因子,从而提供更好的搜索结果排序,这需要耗费大量内存。类的实现基于对映射的映射(map of maps),内部映射会存储规范和文档的映射关系,而外部映射会存储规范和字段的映射关系。
尽管规范信息的键值是字段名称,从而可以添加到LuceneIndexMemoryModel类中,但是我们还是决定把对规范的管理实现为单独的类——LuceneDocumentNormMemoryModel。这么做的原因在于,在Lucene使用规范是可选的操作。
有了之前所描述的底层内存模型,实现索引写入程序就很简单了。因为Lucene不会定义IndexWriter接口,所以想要实现 IndexWriter,我们需要实现所有标准Lucene实现中的方法。这个类的主要内容在于addDocument方法。这个方法会遍历所有文档的字 段。对于每个字段,方法都会检查它是否可以令牌化(tokenized),并使用特定的分析器来做到这一点。这个方法还会更新所有三种内存结构——索引、 文档和(可选的)规范,它们会为新增的文档存储信息。
IndexReader会实现Lucene核心所提供的IndexReader接口。因为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索引读取程序,就可以包含新的索引数据,那会经过一定延迟之后为用户所用,而延迟是通过活动参数的缓存时间所控制的。在下一篇文章中我们会 展示如何扩展这个实现,以包含地理搜索支持。
Boris Lublinsky是NAVTEQ的首席架构师,他的工作是为大型数据管理和处理、SOA以及实现各种NAVTEQ项目 定义架构的愿景。他还是InfoQ的SOA编辑,并且参与了OASIS的SOA RA工作组。Boris是一位作者,并经常发表演讲,他最新的著作是《Applied SOA》。
Michael Segel拥有二十多年和客户协作的经验,和他们一起确定并解决业务问题。Michael曾经在多个领域以多种角色工作过。他是一位独立顾问,期望解决任何有挑战性的问题。Michael拥有俄亥俄州立大学的软件工程学位。