elastic search（一）

 

今天我们来介绍下文本搜索引擎elastic search。想必大家都经历过MIS系统搜索框输入后很慢才能看到返回结果的场景（甚至是界面卡住现象）吧，根本原因是：

用专业点的术语是本次查询涉及到的数据量太大，并且产生了全表扫描，导致的慢查询。

好比是下面这个sql：select id, keyword from keywords where keyword like '%中缀模糊搜索%'

因为没法用上索引，导致了全表扫描，性能就一下子一落千丈。

原因清楚了，那怎么解决呢？为什么百度搜索这么快呢？下面我们就介绍一款性能强悍的文本搜索引擎，对，是文本搜索引擎，不是关系型数据库。

 

 

Elastic search：基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口操作ES，也可以利用Java API。

它的应用场景有很多，最核心的场景，就是文本搜索，大数据量的文本检索。

 

关心技术的同学，百度百度，肯定发现了个现象，就是es（elastic search的缩写）总是会拿来和solr对比，这两个什么样的差别，看下图：

 

 solr依赖zookeeper，也就是说部署时需要多部署3个zk节点，当存在更新行为时查询较慢（相对es）

一般都会根据实际情况来选型，这里我们直接略过选型部分，直接定位在es介绍上。

 

下面，不得不提的是es以及solr的共同基础：lucene，20年前的产物。

lucene是个倒排序搜索引擎，底层建立在文件系统之上，配合分词器建立倒排索引，如下图：

 

 这里的索引原理可解释如下过程：

输入：你好，东泽国际物流有限公司。

分词器会将输入分解，比如分解为：你好   东泽   国际   物流   有限公司

然后，存储引擎会建立索引，比如：

 

当再输入：你好，东泽科技。

则变为：

 

 

 看吧，右面的索引是根据单词来检索，进而得出关联文档id的，我们也称为倒排序索引。

刚才，里面有些故意隐藏的点，如切词怎么切的？答：有很多分词器来做切词+转换词元，中英文、数字都有。

 

lucene分词器

1. StopAnalyzer
2. StandardAnalyzer
3. WhitespaceAnalyzer
4. SimpleAnalyzer
5. CJKAnalyzer
6. KeywordAnalyzer
7. SmartChineseAnalyzer
8. IKAnalyzer

上面一堆分词器就是用来切切切词的，比如这句话：你好，china！不同的分词器不同的效果，如StandardAnalyzer会切出下面这效果：你   好    c    h    i    n     a；然后相应的索引就会把这些切出的字符放上去，当然这效果不太好。

总之，用哪种分词器看实际的应用场景。

 

后一个是匹配度问题，专业术语叫评分，比如下面这个搜索排序（基于评分来决定排序）：

 

 lucene里用的是tf idf算法（词频算法）以及改进的BM25算法，主要原理都是建立在tf idf上

算法上的请参考这个：https://my.oschina.net/stanleysun/blog/1617727

主要思路就是对输入的关键字先分词，比如分出了2个单词后，分别计算tf idf乘积，最后再针对每篇doc进行∑求和，根据分别的sum排序。

到这里，lucene基础部分算是介绍完了。

 后续将正式进入es分布式篇。