Lucene技术分享

Z时代
2024-01-10
分类：综合

问题引入：
- 为啥模糊查询搜索引擎比数据库快？快在哪、快的原因，快的代价
  - 为什么mysql等不行，为什么ES、Solr就很快
- B+树和FST数据结构比较一下，说明其快的原因
- FST数据结构
  - 详细介绍：Lucene索引存储结构

基于Java的搜索引擎框架Lucene介绍：
- ES、Solr都基于Lucene
- 索引建立过程、搜索过程
  - 索引建立过程、搜索过程都会分词
    - 分词扩展：
      - 扩展字典表 ext_dict
      - 停词表stopword.dic、ext_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
  - QueryParser：定制开发
    - ```
    query.toString()查看dsl语句
```
- 可以对前述各个查询进行实现、扩展，功能强大
- Lucene带来的问题数据膨胀
  - 索引文件占存储很大
- 删除的实现
  - 由于倒排索引结构的使用，后续加入索引不能影响已有索引位置变化
  - 加入.del文件，不是真删除，会把已删除数据加入搜索过程，对结果参照.del文件过滤
  - 如果删除数据过多影响搜索效率，这也就是ES定期合并segment的原因
- 更新实现
  - 先删除，后添加
- 对位置信息的存储支持
- 为什么带高亮和位置
  - 为了直观让用户看到搜索结果的相关性
  - 截取相关结果片段部分展示，位置能很好地定位
- Lucene版本直接API变化挺大
  - 值得注意，为啥变化，可做进一步探索研究
- IndexSearcher类，包含explain() 方法
  - 类似mysql的explain()该方法
  - 能展示评分计算的所有相关细节
- 对于匹配结果的扩展
  - 可以考虑放宽部分条件，分楼层展示
  - 与大数据中心协作，对用户进行画像，生成隐含查询条件，返回推荐结果