制作梦核的网站,做网站注意哪方面,东莞网站制作公司,网站热销榜怎么做Apache Lucene项目可能会在几个月后发布其下一个主要版本7.0#xff01; 请记住#xff0c;Lucene开发人员通常会努力为下一个非主要#xff08;功能#xff09;发行版移植新功能#xff0c;而即将发布的6.5已经有了很多重大更改 #xff0c;因此新的主要发行版令人兴奋… 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而引起的兴趣要小 7.0编解码器现在可以稀疏地编码稀疏的doc值和长度归一化因子“范数” 离群值不再占用过多空间 我们基于文档值的查询利用了新的API 现在在稀疏情况下 顶级的仅浏览的构面计数和查询中命中的构面计数都更快 新的advanceExact方法可实现更有效的跳过 通过这些更改您最终只需为您实际使用的文档值付费包括索引大小索引性能等。这与索引的其他部分如发布存储的字段术语向量等相同并且意味着具有稀疏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还没有被释放所以如果你有任何额外的主要释放值得改变想法你想探索请伸手 [我在亚马逊工作并且本网站上的帖子属于我自己不一定代表亚马逊的职位] 翻译自: https://www.javacodegeeks.com/2017/03/apache-lucene-7-0-coming-soon.html
