Elasticsearch全文检索优化研究

背景

今年工作的一个重点是“新技术新模式”的导入和研究。Elasticsearch技术比较火,各项目和产品用的都也比较多。其中某团队遇到一个问题:“在TB级的数据量下进行全文检索时,ES集群检索响应速度比较慢”。虽然由于各种原因没有接触到系统,没有看到代码,甚至都没见到具体现象,但是任务分配下来了,就要有结果就要出方案。“没吃过猪肉,也得先见见猪跑”,先在一个30GB级别的ES集群下做一下优化研究。

全文检索的原理

  • 全文检索的定义
    全文检索和普通查询最大的区别是,全文检索判断的是“相关度”,普通查询判断是“是与非”。比如在全文检索里搜索“我爱你”,除了返回包含“我爱你”的文档,可能还会返回“我不爱你”、“我喜欢你”、“我中意你”、“我爱她” 等文档。相关度越高,也就是得分越高的文档越在前面。
  • 检索流程
    全文检索的基本流程可以分为两部分,“存”和“取”。“存”部分就是将输入的“字符串”,经过分析器,切分成多个“词”,将这些“词”存储到倒排索引中。“取”部分就是将用户搜索的"字符串",使用相同的分析器,切分成多个“词”,在倒排索引中检索是否包含这些“词”,包含就将这些词对应的文档返回。

Elasticsearch全文检索优化研究_elasticsearch

  • 分析器
    在整个全文检索过程中,分析器扮演着非常重要的角色,ES提供的有内置的分析器,社区也提供各种分析器插件(如中文的ik分析器)。分析器由以下几个组件构成:
  • 字符过滤器(char filters)
    主要职责是在分词器前过滤字符流,在源字符流中添加、删除、替换字符。一个分析器中可以有0个或多个字符过滤器。主要包括:html char filter、mapping char filter等。
  • 分词器
    主要职责是将接收到的字符流,按照某些规则切分成若干个“词”,并记录这些“词”在源字符串中的位置。比如将“我爱你”切分成"我"、“爱”、“你”、“我爱”,“爱你”,“我爱你”等等。分析器中有且只能有一个分词器。
  • 分词过滤器
    主要职责是将分好的“词”进行某种规则的过滤,可以添加、移除、替换“词”,但是不能修改“词”在源字符串中的相对位置。一个分析器中可以有0个或多个分词过滤器。常用的分词过滤器包括:大小写转换过滤器、停用词过滤器、同义词过滤器、拼音过滤器 等等

一个分析器可以有字符过滤器、分词器、分词过滤器自由组合,形成新的自定义的分析器。

  • 推理总结
    根据全文检索的原理和流程可以推理出以下几点:
  • 全文检索本质上是精确匹配。如果某分析器将“我爱你”切分成了“我爱”和“爱你”两个词。那么直接搜索“爱”,是查不到任何文档的。
  • 全文检索本质上是预处理的检索。分析器将所有可能被检索的“词”都预先建立了索引。理论上不能搜索没有被切分的词。
  • 高频词会影响检索的性能。比如1000万文档,900万都包含“爱”字。那么检索“爱”字时就会把900万文档都查出来,然后计算出“爱”在每份文档的得分,返回得分最高的文档。
  • 分析器会增加索引空间大小。比如某分词器将“我爱你”切分成"我"、“爱”、“你”、“我爱”,“爱你”,“我爱你”,要比切分成"我爱你"一个词的空间大N倍。
  • 好的的分析器应该在分词的精确度和碎片度之间平衡,即能保证查的到、查的准,又能保证不大量增加索引空间

分析器对比

分析器有很多种,有ES内置的和社区提供的。其中主流的分析器包括:standard 、ansj、ik、smartcn、icu、mmseg、pinyin,且均能支持中文分词。

  • 基本用法
#查看集群安装的分析器插件
GET /_nodes/plugins

#结果:
...
"plugins": [
{
"name": "analysis-icu",
"version": "5.5.1",
"description": "The ICU Analysis plugin integrates Lucene ICU module into elasticsearch, adding ICU relates analysis components.",
"classname": "org.elasticsearch.plugin.analysis.icu.AnalysisICUPlugin",
"has_native_controller": false
},
{
"name": "analysis-ik",
"version": "5.5.1",
"description": "IK Analyzer for Elasticsearch",
"classname": "org.elasticsearch.plugin.analysis.ik.AnalysisIkPlugin",
"has_native_controller": false
},
{
"name": "analysis-mmseg",
"version": "5.5.1",
"description": "Mmseg Analyzer for Elasticsearch",
"classname": "org.elasticsearch.plugin.analysis.mmseg.AnalysisMMsegPlugin",
"has_native_controller": false
},
{
"name": "analysis-pinyin",
"version": "5.5.1",
"description": "Pinyin Analysis for Elasticsearch",
"classname": "org.elasticsearch.plugin.analysis.pinyin.AnalysisPinyinPlugin",
"has_native_controller": false
},
{
"name": "analysis-smartcn",
"version": "5.5.1",
"description": "Smart Chinese Analysis plugin integrates Lucene Smart Chinese analysis module into elasticsearch.",
"classname": "org.elasticsearch.plugin.analysis.smartcn.AnalysisSmartChinesePlugin",
"has_native_controller": false
},
{
"name": "elasticsearch-analysis-ansj",
"version": "5.5.1.0",
"description": "elasticsearch analysis by ansj",
"classname": "org.ansj.elasticsearch.plugin.AnalysisAnsjPlugin",
"has_native_controller": false
}
]
...

查看比较火的ik分词器效果:

GET /medcl/_analyze
{
"text": "武汉市长江大桥",
"analyzer": "ik_max_word"
}

#结果:
{
"tokens": [
{
"token": "武汉市",
"start_offset": 0,
"end_offset": 3,
"type": "CN_WORD",
"position": 0
},
{
"token": "武汉",
"start_offset": 0,
"end_offset": 2,
"type": "CN_WORD",
"position": 1
},
{
"token": "市长",
"start_offset": 2,
"end_offset": 4,
"type": "CN_WORD",
"position": 2
},
{
"token": "长江大桥",
"start_offset": 3,
"end_offset": 7,
"type": "CN_WORD",
"position": 3
},
{
"token": "长江",
"start_offset": 3,
"end_offset": 5,
"type": "CN_WORD",
"position": 4
},
{
"token": "大桥",
"start_offset": 5,
"end_offset": 7,
"type": "CN_WORD",
"position": 5
}
]
}
  • 分词准确度比较
    比较几种分析器对武汉市长江大桥这句话分词的准确度。

分析器

分词效果

standard

"武"、"汉"、“市”、“长”、“江”、“大”、“桥”

ik

"武汉市"、"武汉"、“市长”、“长江大桥”、“长江”、“大桥”

smartcn

"武汉市"、“长江”、“大桥”

ansj

"武汉市"、“长江”、“大桥”

mmseg

"武汉"、“市”、“长江”、“大桥”

icu

"武汉"、“市”、“长江”、“大"、"桥”

结论:smartcn和ansj是比较准确和智能的分析器

  • 分词后索引空间比较
  • 分词速度比较

优化方案

  • 部署架构优化
    在部署方式上应该采用分布式思想。
  • 8台16核64G内存RAID0磁盘阵列的中配计算集集群 性能好于1台128核512G内存RAID10磁盘阵列的高配计算机。
  • ES实例参数优化
  • OS层调优参见官文和本人博客《Linux参数调优积累》
  • JVM的最大最小堆内存应为RAM的40%,且最大不超过30G。
  • index的分片数量应该设置成8片,并根据实际情况扩充至16片或更多。
  • 分析器建议选择smartcn或者ansj。
  • ES查询语句优化
  • 尽量少使用父子文档模型,减少父子联查。
  • 禁用_all等索引和映射的元数据。
  • 禁用script_field和function_score。
  • 禁用 wildcard、prefiexd、fruzzd等模糊查询。
  • 优先使用filter过滤掉不需要的数据,减小计算评分的数据量。