今天我们来介绍下文本搜索引擎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分词器
- StopAnalyzer
- StandardAnalyzer
- WhitespaceAnalyzer
- SimpleAnalyzer
- CJKAnalyzer
- KeywordAnalyzer
- SmartChineseAnalyzer
- 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分布式篇。