Lucene4.X中的自定义评分机制

摘要: 之前写过Lucene3.X中的自定义评分机制，Lucene在4.0中相应的接口有个很大的改变。究其根本，是因为Lucene在4.0中提出了DocValue的概念，可以将doc id与 field value映射关系存放到索引文件中（实际上，索引文件中同时也存放了很多统计的信息，比如词频之类）。

之前写过Lucene3.X中的自定义评分机制，Lucene在4.0中相应的接口有个很大的改变。究其根本，是因为Lucene在4.0中提出了DocValue的概念，可以将doc id与 field value映射关系存放到索引文件中（实际上，索引文件中同时也存放了很多统计的信息，比如词频之类）。

用户在建索引的时候需要建立特殊的DocValueField域(正常情况下是DocvalueField的子类)，然后再根据DocValueField的值做评分、排序、分组等等功能。FieldCache默认也使用DocValue代替直接将filedvalue[]数组加载到内存中，这样做的好处是可以对数据做很大的压缩，有效减少内存的负荷。这点我们以后在有关DocValue的文章中再谈。

具体说到自定义评分，Lucene4.0中依旧使用CustomScoreQuery来综合计算正常查得分和功能查询（funtionQuery）得分，开发者可以继承CustomScoreProvider来改变正常查询与功能查询得分的计算方法，默认是相乘。如图所示



但与Lucene3.0不同的是，Lucene4.0取消了ValueSourceQuery这个类，改用FunctionQuery来替代。实际上，仅仅只是换个名称，构造方法并没有改变,都是直接用ValueSource来构造。



与Lucene3.0不同的是Lucene4.0在function包中直接取消了DocValues类和FieldScoreQuery类。DocValues类在Lucene4.0中另有含义，表示DocValue的相关概念。而FieldScoreQuery本身就是对ValueSourceQuery类的进一步包装。实际上，随着Lucene索引支持的数据类型的增多，可以直接用FunctionQuery的构造方法即可。

值得注意的是FunctionValues类的提出，它本身是一个抽象类，实际上是提供了一个根据doc id 获取各种数据类型的方法。



但我们使用的是FunctionValues的各种子类，它们代表了不同的数据类型的获取



查看源代码，很容易发现这些子类实际上也是不同的抽象类，实际上需要编写这些子类的编码器，针对性的对子类解码，转换成我们需要的数据类型。比如Float子类



Lucene4.0的功能查询中有很多类让人混淆不清，比如valuesource,funtionvalues,看起来好像都差不多。实际上Valuessource代表从IndexReader中提取出functionvalues出来，Functionvalues则专注于不同的数据类型的获取。至于怎么从valuessource提取出functionvalues，则需要使用到valuesource的各种子类，以FloatFieldSource为例，只需要传入field名，就可以获取functionValue的子类，根据doc id获取float值。这里同样使用到了域缓存的机制。



与3.0相比，Lucene4.0提供个各种丰富的FunctionQuery的子类，查询各种数值（并不一定使用域缓存机制），比如TF/IDF信息