how solr support DocValues

虽然说lucene,solr目前都是以相同版本同时release,并这并不意味着lucene级别的新功能,在solr级别一定会及时得到支持。拿lucene 4.0中的HighLight DocValues来说,在solr同版本中并没有得到支持。

如果让你来写一个patch,你会如何下手呢?

当然第一步是深入了解solr和lucene是如何结合在一起。

先看一下 lucene 4.0中是如何使用DocValues的

 Java |  copy code |? 
1
 
2
Document doc = new Document();
3
 doc.add(new IntDocValuesField(name, 22));
4
 doc.add(new IntField(name, 6, Field.Store.NO));
5
  

如上所示,同样是针对一个int value,如果使用DocValues,则使用的Field和一般场景是不一样的。

而目前solr 4.0中的现状是只针对IntField做了配置上处理以及映射。还未对IntDocValuesField作出支持。

再看一下solr是如何和lucene将这些field结合在一起的

step1 schema.xml中的配置:

 XML |  copy code |? 
01
02
<fields>
03
.......
04
<field name="popularity" type="int" indexed="true" stored="true" />
05
</fields>
06
 
07
<types>
08
<fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/>
09
</types>
10

其实真正理解这两部分是关键。

修改思路:
切入点:
solr有 solrInputField, SolrInputDocument, 这是很明显对应于lucene中的 Field, Document.

因此中间的一个所谓转换器 or其它概念的 东东 一定存在, 实际代码中就是:

DocumentBuilder
但实际上,这个类真的只是一个切入点。

对照schema.xml中的配置,

其实关键的是 schemaField, 以及各种 FieldType类。

各种不同的filed 都是通过FieldType create出来的。

花了点时间搞了个小patch,未全面测试,只提供了一个小test。
LOVE-219

DocValues的理解应用

在lucene-4.0-alpha的Hightlights中有这么一段:

  • Added support for per-document values (DocValues). DocValues can be used for custom scoring factors (accessible via Similarity), for pre-sorted Sort values, and more.它的主要作用是custom scoring factors。

    其实第一眼看到这HightLight,想到的是这对比原来的Document级别的Boost有哪些不同。Document级别的Boost虽然不是一个custom scoring factor, 但它也可以用来影响整体score(在根据score进行排序的情况下)。

    Document boost的特点:

  • default value is 1.0
  • This value will be multiplied intothe score of all hits on this document.
  • Values are multiplied into the value of Fieldable#getBoost() of
    each field in this document. Thus, this method in effect sets a default boost for the fields of this document, 也就是说this value会被传递影响到field boost,如果field boost是1.0的话,也就相当于给所有field 设置了一个和document一样的boost。
  • 作用norm的一部分,这个boost没有单独的一块地方来store它。只能和其它norm共存一室。
    基于这些点,这个boost所起的作用是被固定的。
    相对于4.0中的DocValues。4.0中docvalues

    应该说4.0中的docvalues是伴随着4.0中similarity做成一个component后而出现的。
    在4.0之前整体体系结构上是使用 its hard-wired classic vector space scoring model。

    在4.0中,我们可以通过similarity的封装,在计算score时,按自己的需要来决定docvalues中的值来影响socre。

     Java |  copy code |? 
    01
    @Override
    02
    public ExactSimScorer exactSimScorer(SimWeight stats, AtomicReaderContext context) throws IOException {
    03
    final ExactSimScorer sub = sim.exactSimScorer(stats, context);
    04
    final Source values = context.reader().docValues(boostField).getSource();
    05
     
    06
    return new ExactSimScorer() {
    07
    @Override
    08
    public float score(int doc, int freq) {
    09
    return (float) values.getFloat(doc) * sub.score(doc, freq);
    10
    }
    11
     
    12
    @Override
    13
    public Explanation explain(int doc, Explanation freq) {
    14
    Explanation boostExplanation = new Explanation((float) values.getFloat(doc), "indexDocValue(" + boostField + ")");
    15
    Explanation simExplanation = sub.explain(doc, freq);
    16
    Explanation expl = new Explanation(boostExplanation.getValue() * simExplanation.getValue(), "product of:");
    17
    expl.addDetail(boostExplanation);
    18
    expl.addDetail(simExplanation);
    19
    return expl;
    20
    }
    21
    };
    22
    }

    在这里是直接使用docvalues中的值乘以原先的score。当然我们也可以相加,or其它运算。

Native C/C++ Like Performance For Java Object Serialisation

title就直接引用一下人家的吧。

具体文章见:
Native C/C++ Like Performance For Java Object Serialisation

从中能看到的关键几个技术点是:
1) ByteBuffer
2) Unsafe

其实对于这两点,在 https://github.com/eishay/jvm-serializers 都能找到影子。

在deserialize相差不大的情况下,我是更倾向于选择支持前后兼容,自描述的实现方案。

重启blog

两年前,起过一个念头想坚持写blog,期间也坚持了一段时间。刚才想找N多理由来表达后来没有坚持下来是因为1)没有自己的空间,偶尔出了几次问题影响了自己的持续性 2)工作有段时间太忙,把这事丢在一边 。。。。。哈哈,其实这些是坚不可摧的理由吗?不用回答,你也懂的 :)

还是之前的名字:蛋珠珠的生活快照。希望这里除了那么点技术记录外,还会有我的其它影子。