46°

Lucene 技术分享

问题引入

  • 模糊查询
    • 为什么mysql等不行,为什么ES、Solr就很快
    • 快的原因,快的代价

提纲:

  1. 问题引入:为啥模糊查询搜索引擎比数据库快?快在哪、怎么做到的
  2. 纯Java搜索引擎框架Lucene介绍:
    • ES、Solr都基于Lucene
    • 索引建立过程、搜索过程
      • 索引建立过程、搜索过程都会分词
        • 分词扩展:
          • 扩展字典表 ext_dict
          • 停词表stopword.dicext_stopword.dic
          • 很重要,尤其是汉语分词IK、jieba
    • 浅析为什么查询不准
      • 据业务实际进行查询优化
      • 建立索引过程可以加权,查询也可以加权
    • tf-idf算法
    • 向量模型算法、BM25模型算法
      • BM25模型算法
        • 取对数计算的原因是不让单个此项相关度过高导致其他此项的相关度不起作用
        • 经典检索算法:BM25
    • 几种query原理分析
      • BooleanQuery
        • 分三个子查询 MUST、SHOULD、MUST_NOT
        • 与布尔表达式区别
      • PhraseQuery
        • slop是指两个项的位置之间允许的最大间隔距离
        • 短语查询的评分:
          • 与距离成反比
      • PrefixQuery
      • WildcardQuery
        • 更加通用的PrefixQuery
          • * 代表0个或多个字符
          • ? 代表0个或1个字符
        • 会降低系统性能
          • 以通配符为首的查询,会强制所有索引项进行匹配
          • 通配符查询对评分没有任何影响
      • FuzzyQuery: 基于Levenshtein Edit Distance(莱温斯坦编辑距离)基础上,对索引文档进行模糊搜索
        • 简单理解就是从一个字符串转换成另一个字符串需要增删改几个字符
        • 编辑距离只支持0 1 2
        • 查询效率比termQuery低得多
        • 这里所谓模糊搜索,比如:搜索金杰,也能搜出金视杰这样的品牌名
          • 编辑距离为1
    • Lucene带来的问题数据膨胀
      • 索引文件占存储很大
    • 删除的实现
      • 由于倒排索引结构的使用,后续加入索引不能影响已有索引位置变化
      • 加入.del文件,不是真删除,会把已删除数据加入搜索过程,对结果参照.del文件过滤
      • 如果删除数据过多影响搜索效率,这也就是ES定期合并segment的原因
    • 更新实现
      • 先删除,后添加
    • 对位置信息的存储支持
    • 为什么带高亮位置
      • 为了直观让用户看到搜索结果的相关性
      • 截取相关结果片段部分展示,位置能很好地定位
    • Lucene版本直接API变化挺大
      • 值得注意,为啥变化,可做进一步探索研究
    • IndexSearcher类,包含explain() 方法
      • 类似mysql的explain()该方法
      • 能展示评分计算的所有相关细节
    • 对于匹配结果的扩展
      • 可以考虑放宽部分条件,分楼层展示
      • 与大数据中心协作,对用户进行画像,生成隐含查询条件,返回推荐结果
  3. ES与Lucene关系:
    • 如何使用lucene,分布式存储,倒排索引不可变更,segment定时合并,为啥是近实时搜索引擎,为啥磁盘需要2倍容积等

本文由【Java搬砖工程师】发布于开源中国,原文链接:https://my.oschina.net/u/3847203/blog/3160042

全部评论: 0

    我有话说: