Apache Lucene 7.0即将发布！

最新推荐文章于 2021-04-19 13:57:34 发布

dnc8371

最新推荐文章于 2021-04-19 13:57:34 发布

阅读量88

点赞数

文章标签： python java 大数据数据库 mysql

Apache Lucene项目可能会在几个月后发布其下一个主要版本7.0！

请记住，Lucene开发人员通常会努力为下一个非主要（功能）发行版移植新功能，而即将发布的6.5已经有了很多重大更改，因此新的主要发行版令人兴奋，因为这意味着仅7.0的功能，我我们现在描述的是那些我们认为无法在6.5下移植的特别大的变量。

当然，在每个主要版本中，我们还会做更多平凡的事情，例如删除不推荐使用的6.x API，并放弃对旧索引的支持（使用Lucene 5.x或更早版本编写）。

这只是7.0新功能的一部分。有关完整列表的信息，请参见后面的CHANGES.txt的7.0.0部分。

Doc值作为迭代器

7.0中最大的变化是将文档值从随机访问API更改为限制性更强的迭代器API 。

Doc值是Lucene在所有文档中按列跨步的数字，按文档排序或二进制的字段存储。它们可用于保存评分信号，例如单字节（默认情况下）文档长度编码或与应用程序相关的信号，或用于排序，构面或分组，甚至是一些查询中可能用于范围过滤的数字字段。他们的列跨步存储意味着跨文档访问一个字段的所有值是有效的，而行跨步存储用于存储单个字段的所有字段值。

长期以来，帖子是通过迭代器消耗的，因此，这是相对自然的更改，并且两者共享相同的基类，
DocIdSetIterator ，以单步执行或搜索每次DocIdSetIterator 。

最初死记硬背地切换到迭代器API的过程实际上只是一次管道交换，并且比随后的所有对用户有影响的改进（由于限制性更强的API）而引起的兴趣要小：

通过这些更改，您最终只需为您实际使用的文档值付费，包括索引大小，索引性能等。这与索引的其他部分（如发布，存储的字段，术语向量等）相同，并且意味着具有稀疏doc值的用户不再会花费不合理的时间进行合并或合并时索引异常庞大。

我们基于NYC Trip Data语料库的夜间稀疏基准测试表明，上述每项更改（以及更多！）都取得了令人印象深刻的收益。

再见索引时间的提升

现在已弃用了索引时间提升功能，它使您可以提高特定文档相对于其他文档的先验得分，该功能已在7.0版中删除。

这一直是一个脆弱的功能：它与字段的长度一起被编码为一个字节值，因此精度很低。此外，现在可以直接将自定义增强功能写入自己的doc值字段，并使用函数查询在搜索时应用增强功能。最后，随着索引时间的增加，长度编码更加精确，尤其是前九个长度值（1到9）是不同的。

查询计分更简单

BooleanQuery长期以来一直暴露一种令人困惑的评分功能，称为协调因子（ coord ），以奖励包含更高百分比的搜索字词的匹配。但是，只有在对TF / IDF之类的术语具有“弱”饱和度的评分模型时，才需要使用此技巧，以使文档中单个术语的多次出现比从查询中添加另一个术语的一次出现更为强大。由于这是特定于一个评分模型TFIDFSimilarity ，并且由于Lucene现在默认已切换到更好的Okapi BM25评分模型，因此我们现在已从 BooleanQuery和Similarity 完全删除了7.0中的协调因子。

同样，评分的查询规范化阶段将被删除。此阶段尝试使不同查询和索引之间的得分均等，以使它们具有更高的可比性，但未更改命中的排序顺序，并且也是TF / IDF特有的。

通过这些评分简化，当相同的子条款出现不同的Occur约束时， BooleanQuery现在可以进行更具进取性的查询优化，这以前是不可能的，因为分数会发生变化。

经典查询解析器不再在空白处拆分

Lucene原来的查询解析器现在称为“经典”，始终将传入的查询文本预分割为空白，然后将这些单个标记分别发送给查询时间分析器。这意味着多令牌过滤器（例如SynonymGraphFilter或ShingleFilter ）将不起作用。

例如，如果用户要求“拒绝服务攻击”，而您将同义词“拒绝服务”映射到DOS，则经典查询解析器将分别分析“拒绝”，“ of”和“服务”，因此您的同义词将永不匹配。

我们已经在查询解析器中添加了一个选项，该选项不对空格进行预分割，但对于6.x版本保留默认值，以保持向后兼容性。最后，在7.0版中，我们修复了该默认设置，以便分析人员可以一次看到多个令牌，并且同义词将起作用。

更多东西

从7.0开始，Lucene将（最终！）记录到索引元数据中，Lucene版本最初是使用该版本创建它的。这些知识可以帮助我们实现将来的向后兼容性。

有限状态转换器在Lucene中以多种方式使用，曾经有一个复杂的方法调用pack ，它会占用更多字节，以进一步缩小FST的体积。但是代码很复杂，很少使用，有时甚至使FST更大，因此我们在7.0中将其删除。

用于在索引中添加，更新和删除文档的IndexWriter 将不再接受有时由错误的令牌过滤器产生的损坏的令牌偏移。偏移量用于突出显示，而断开的偏移量（单个标记的结束偏移量在开始偏移量之前，或者令牌的起始偏移量相对于先前的标记向后偏移）只能破坏搜索时突出显示。因此，通过此更改，Lucene通过抛出异常来防止在索引时发生此类错误。为了在用户甚至不知道其分析仪产生损坏的偏移量的情况下简化此过渡，我们还添加了一些令牌过滤器来“校正”偏移量，然后再将其传递给
IndexWriter 。

Lucene的高级用户经常需要在搜索时为每个段缓存一些自定义的内容，但是用于此目的的API过于庞大，并且可能导致意外的内存泄漏，因此我们已对这些API进行了大修，以减少意外滥用的机会。

最后，维度点API 现在会预先获取一个字段名称，以提供按字段的点访问，从而与doc值API的工作方式匹配。

Lucene的7.0还没有被释放，所以如果你有任何额外的主要释放值得改变想法，你想探索请伸手！

[我在亚马逊工作，并且本网站上的帖子属于我自己，不一定代表亚马逊的职位]