此文章要对ES有一些基础
应用背景：官网重建，需要全网站检索所有的文章、服务、附件等；数据库设计上，由于业务隔离的原因，数据被分散在各个表中
技术选型：在开发周期限制条件下，准备了两个方案：
1、查询直接打到数据库，对各个需要查询的数据做union汇总
2、使用ES全文检索工具
针对第一个方案，从查询速度和数据库压力上考虑放弃实施此方案，首先所有的查询都是模糊搜索，模糊搜索在数据库层面是不走索引的， 其次排序规则也会直接影响查询速度，并且网站对外开放，所有的查询压力都给到了数据库，增加了数据的宕机风险；
针对第二个方案，在研究了ES的特性之后，决定采用此工具做搜索引擎，ES对会所有需要检索的字段信息创建反向索引，根据需要检索的信息定位到反向索引，进而定位到所有包含此信息的所有数据信息，非常适合我们的全网站检索功能。
应用过程：ES要和kibana工具配合使用，并且有严格的版本要求，不兼容的版本，kibana是启动不起来的；一开始考虑的是使用logstash工具将表数据以及结构直接同步到ES中去，然后利用ES可以使用sql的查询方式，直接连表查询；于是我将ES 6.7版本下载下来解压缩，配置好端口数据， 启动boot服务器的时候报错版本不兼容，经过百度才知道，SpringBoot1.X的版本不兼容ES高版本，于是我在github上找到适用我们架构的ES2.2版本，对于要将数据库中的全量数据都同步到ES中去，就用到了上面的logstash初始化全量数据进ES
重要知识点：ES有两个主要的端口，9300给服务器链接使用，9300给kibana连接使用；Es跟关系型数据库对照如下
关系型数据库(MySQL) 非关系型数据库（ElasticSearch）
数据库Database 索引Index
表Table 类型Type
数据行Row 文档Dpcument
数据列Column 字段Field
主要的概念对照关系，ES查询的时候可以只查询指定的Index，在不指定的时候查询的是ES里面所有的数据；至于为什么ES这么快，那就要介绍一下反向索引这个概念，在介绍这个概念之前，先说一下分词器，我们存入的数据，在指定的搜索字段都会带有一个分词器，就是将对应字段的数据进行分词存储（比如“我是中国人” 会被默认的分词器分成多个词存储），而反向索引就是在这个分词的基础上实现的；反向索引的的实现是由1、单词词典 2、倒排列表3、倒排文件 。单词词典就是分词器分词后的结果数据，每个单词存储了一个只想倒排列表的指针而所有的倒排列表存储的文件叫做倒排文件，倒排列表里面的单词对应着文档的位置信息；这里最重要的是利用对我们业务要求有利的分词器，并且对应的Javaapi的模糊字符串精准匹配，这个精准都是相对分词器分词后的结果来精准匹配的，如果分词器中没有就不会查询到结果数据。
应用总结：从一开始的需求到最终确定使用ES是一个对业务理解和新技术探索的过程，充分体现了技术和业务是相辅相成的；在业务的基础上要扩展 技术的广度，在具体的技术应用上要增加技术的深度，像这次使用ES的结果上，由于没有深刻理解精准匹配的前提是分词后的分词结果，对分析器没有准确的使用，导致在搜索的时候，如果搜索某个字段的全量信息，搜索结果就出不来，因为我使用的是汉语分词器，顾名思义汉语分词器就是会根据汉语的习性将对应的词语分开，如果不是词语的话是不会出现在分析结果里面的，这才导致搜索结果有误。在使用新技术之后，在对新技术理解和把控上不是很强的时候，一定有要多测试跟新技术有关的功能，今早暴露问题，尽早解决，避免线上事故。