一、ElasticSearch简介
ElasticSearch是一种分布式、高可用、高性能、可伸缩的搜索和分析系统。
官网：https://www.elastic.co/cn/
问题：
什么是搜索？
百度：我们比如说想找寻任何的信息的时候，就会上百度去搜索一下，比如说找一部自己喜欢的电影，或者说找一本喜欢的书，或者找一条感兴趣的新闻（提到搜索的第一印象）。垂直搜索（站内搜索）
互联网的搜索：电商网站，招聘网站，新闻网站，各种app
IT系统的搜索：OA软件，办公自动化软件，会议管理，日程管理，项目管理，员工管理，搜索“张三”，“张三儿”，“张小三”；有个电商网站，卖家，后台管理系统，搜索“牙膏”，订单，“牙膏相关的订单”搜索，就是在任何场景下，找寻你想要的信息，这个时候，会输入一段你要搜索的关键字，然后就期望找到这个关键字相关的有些信息搜索，就是在任何场景下，找寻你想要的信息，这个时候，会输入一段你要搜索的关键字，然后就期望找到这个关键字相关的有些信息。使用数据库搜索结果会怎样?
数据一般都是存储在数据库里面的，比如说电商网站的商品信息，招聘网站的职位信息，新闻网站的新闻信息，等等吧。所以说，很自然的一点，如果说从技术的角度去考虑，如何实现如说，电商网站内部的搜索功能的话，就可以考虑，去使用数据库去进行搜索。
1、比方说，每条记录的指定字段的文本，可能会很长，比如说“商品描述”字段的长度，有长达数千个，甚至数万个字符，这个时候，每次都要对每条记录的所有文本进行扫描， like判断说，你包不包含我指定的这个关键词（比如说“牛奶”）。
2、还不能将搜索词拆分开来，尽可能去搜索更多的符合你的期望的结果，比如输入“生化机”，就搜索不出来“生化危机”。
用数据库来实现搜索，是不太靠谱的。通常来说，性能会很差的。
select * from goods where name '%牛奶%'
- 什么是全文检索和Lucene?
全文检索，倒排索引
例如数据库现在有100W条数据，按照之前的思路，其实就要扫描100W次，而且每次扫描都要匹配那个文本的所有字符，确认是否包含搜索的关键字，而且还不能将关键字拆解开来进行检索。
利用倒排索引进行搜索的话，假如100W数据，拆分出来的词语假设有1000W个，那么在倒排索引中就有1000W行，在实际检索的时候可能并不需要检索1000W次，很可能在搜索到第一次的时候就可以找到对应的数据也可能是第100次，1000次。
倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引。通俗地来讲，正向索引是通过key找value，反向索引则是通过value找key。
倒排索引是个什么样子呢？
倒排索引
假设有个user索引，它有四个字段：分别是name，gender，age，address。
| id | name | gender | age | address |
|---|---|---|---|---|
| 1 | 张三 | 1 | 22 | 天津市东丽区 |
| 2 | 李四 | 0 | 21 | 天津西青区 |
| 3 | 王五 | 1 | 23 | 天津和平区 |
Term（单词）：一段文本经过分析器分析以后就会输出一串单词，这一个一个的就叫做Term（直译为：单词）
Term Dictionary（单词字典）：顾名思义，它里面维护的是Term，可以理解为Term的集合
Term Index（单词索引）：为了更快的找到某个单词，我们为单词建立索引
Posting List（倒排列表）：倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。
根据倒排列表，即可获知哪些文档包含某个单词。（实际的倒排列表中并不只是存了文档ID这么简单，还有一些其它的信息，比如：词频（Term出现的次数）、偏移量（offset）等，可以想象成是Python中的元组，或者Java中的对象）
（如果类比现代汉语词典的话，那么Term就相当于词语，Term Dictionary相当于汉语词典本身，Term Index相当于词典的目录索引）
每个文档都有一个ID，如果插入的时候没有指定的话，Elasticsearch会自动生成一个。
Elasticsearch建立的索引大致如下：
name字段：
| Term | Posting List |
|---|---|
| 张三 | 1 |
| 李四 | 2 |
| 王五 | 3 |
age字段：
| Term | Posting List |
|---|---|
| 21 | 2 |
| 22 | 1 |
| 23 | 3 |
gender字段：
| Term | Posting List |
|---|---|
| 1 | [1,3] |
| 0 | 2 |
address字段：
| Term | Posting List |
|---|---|
| 天津市 | [1,2，3] |
| 东丽区 | 1 |
| 西青区 | 2 |
| 和平区 | 3 |
Elasticsearch分别为每个字段都建立了一个倒排索引。
比如，在上面“张三”、“天津市”、22 这些都是Term，而[1，3]就是Posting List。
Posting list就是一个数组，存储了所有符合某个Term的文档ID。
只要知道文档ID，就能快速找到文档。可是，要怎样通过我们给定的关键词快速找到这个Term呢？
当然是建索引了，为Terms建立索引，最好的就是B-Tree索引（PS：MySQL就是B树索引最好的例子）。
首先，让我们来回忆一下MyISAM存储引擎中的索引是什么样的：
我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的，MyISAM中，索引和数据是分开，通过索引可以找到记录的地址，进而可以找到这条记录。
在倒排索引中，通过Term索引可以找到Term在Term Dictionary中的位置，进而找到Posting List，有了倒排列表就可以根据ID找到文档了。
可以这样理解，类比MyISAM的话，Term Index相当于索引文件，Term Dictionary相当于数据文件。
可以这样理解倒排索引：通过单词找到对应的倒排列表，根据倒排列表中的倒排项进而可以找到文档记录。
Lucene
lucene，就是一个jar包，里面包含了封装好的各种建立倒排索引，以及进行搜索的代码，包括各种算法。我们就用java开发的时候，引入lucene jar，然后基于lucene的api进行去进行开发就可以了。用lucene，我们就可以去将已有的数据建立索引，lucene会在本地磁盘上面，给我们组织索引的数据结构。另外的话，我们也可以用lucene提供的一些功能和api来针对磁盘上的数据进行搜索。
- Elasticsearch是什么？
如果用我们使用lucene封装了搜索引擎的功能，部署在单台机器上。假设磁盘就500G，当数据量很大超过了500G，这时候在一台机器上是放不下的。增加机器后单服务就变成了分布式集群了，那么前端在检索的时候要跟多台机器进行通信，还要保证系统的高可用，数据不丢失，如何建立高性能的索引等，都是我们需要考虑的问题。
Elasticsearch 底层封装了 lucene ，可以建立一个Elasticsearch集群，每一个节点就是一个es节点，每一个es节点都封装了lucene 暴露给用户的就是一个统一的地址。
Elasticsearch 会自动维护数据的分布到多个节点的建立，还有搜索请求到多个节点的执行自动维护数据的冗余副本，保证一些机器宕机了，不会丢失任何数据，封装了更多的高级功能，给我们提供更多高级支持，让我们快速开发应用，开发更加复杂的应用，更加复杂的搜索功能，聚合分析的功能，基于地理搜索的功能。
Elasticsearch的好处：
1、自动维护数据的分布到多个节点的索引的建立，还有搜索请求分布到多个节点的执行。
2、自动维护数据的冗余副本，一些机器宕机了，不会丢失任何的数据。
3、封装了更多的高级功能，以给我们提供更多高级的支持。让我们快速的开发应用，开发更加复杂的应用：复杂的搜索功能，聚合分析的功能，基于地理位置的搜索（距离我当前位置1公里内的烤肉店）
- Elasticsearch 和 Solr 的区别
背景:
它们都是基于Lucene搜索服务器基础之上开发，一款优秀的，高性能的企业级搜索服务器。【是因为他们都是基于分词技术构建的倒排索引的方式进行查询】
开发语言：java语言开发
Solr ：2004年诞生
Es：2010年诞生
区别
1、当实时建立索引的时候，solr会产生io阻塞，而es则不会，es查询性能要高于solr。
2、在不断动态添加数据的时候，solr的检索效率会变的低下，而es则没有什么变化。
3、Solr利用zookeeper进行分布式管理，而es自身带有分布式系统管理功能。Solr一般都要部署到web服务器上，比如tomcat。启动tomcat的时候需要配置tomcat与solr的关联。【Solr 的本质 是一个动态web项目】
4、Solr支持更多的格式数据 [ xml , json , csv等 ]，而 es 仅支持 json 文件格式。
5、Solr是传统搜索应用的有力解决方案，但是es更适用于新兴的实时搜索应用。 a) 单纯的对已有数据进行检索的时候，solr效率更好，高于es。
6、Solr官网提供的功能更多，而es本身更注重于核心功能，高级功能多有第三方插件。
- 什么是distributed document store
Elasticsearch在跑起来以后，其实起到的第一个最核心的功能，就是一个分布式的文档数据存储系统。ES是分布式的。文档数据存储系统。文档数据，存储系统。
文档数据：es可以存储和操作json文档类型的数据，而且这也是es的核心数据结构。
存储系统：es可以对json文档类型的数据进行存储，查询，创建，更新，删除，等等操作。其实已经起到了一个什么样的效果呢？其实ES满足了这些功能，就可以说已经是一个NoSQL的存储系统了。
围绕着document在操作，其实就是把es当成了一个NoSQL存储引擎，一个可以存储文档类型数据的存储系统，在操作里面的document。
ES适合什么类型的应用程序呢？
（1）数据量较大，es的分布式本质，可以帮助你快速进行扩容，承载大量数据;
（2）数据结构灵活多变，随时可能会变化，而且数据结构之间的关系，非常复杂，如果我们用传统数据库，那是不是很坑，因为要面临大量的表;
（3）对数据的相关操作，较为简单，比如就是一些简单的增删改查，用我们之前讲解的那些document操作就可以搞定;
（4）NoSQL数据库，适用的也是类似于上面的这种场景。
例如：
像一些网站系统，或者是普通的电商系统，博客系统，面向对象概念比较复杂，但是作为终端网站来说，没什么太复杂的功能，就是一些简单的CRUD操作，而且数据量可能还比较大。这个时候选用ES这种NoSQL型的数据存储，比传统的复杂的功能使用支持SQL的关系型数据库，更加合适一些。无论是性能，还是吞吐量，可能都会更好。
二、Elasticsearch的功能
- 全文检索，结构化检索，数据分析
全文检索：我想搜索商品名称包含牙膏的商品，
select * from products where product_name like “%牙膏%”
结构化检索：我想搜索商品分类为日化用品的商品都有哪些，
select * from products where category_id=‘日化用品’
部分匹配、自动完成、搜索纠错、搜索推荐 数据分析：我们分析每一个商品分类下有多少个商品，
select category_id,count(*) from products group by category_id
对海量数据进行近实时的处理
分布式：ES自动可以将海量数据分散到多台服务器上去存储和检索
海量数据的处理：分布式以后，就可以采用大量的服务器去存储和检索数据，自然而然就可以实现海量数据的处理了
近实时：检索个数据要花费1小时（这就不要近实时，离线批处理，batch-processing）；在秒级别对数据进行搜索和分析
跟分布式/海量数据相反的：lucene，单机应用，只能在单台服务器上使用，最多只能处理单台服务器可以处理的数据量Elasticsearch的适用场景
国外：
1、维基百科，类似百度百科，牙膏，牙膏的维基百科，全文检索，高亮，搜索推荐
2、The Guardian（国外新闻网站），类似搜狐新闻，用户行为日志（点击，浏览，收藏，评论）+ 社交网络数据（对某某新闻的相关看法），数据分析，给到每篇新闻文章的作者，让他知道他的文章的公众反馈（好，坏，热门，垃圾，鄙视，崇拜）
3、Stack Overflow（国外的程序异常讨论论坛），IT问题，程序的报错，提交上去，有人会跟你讨论和回答，全文检索，搜索相关问题和答案，程序报错了，就会将报错信息粘贴到里面去，搜索有没有对应的答案
4、GitHub（开源代码管理），搜索上千亿行代码
5、电商网站，检索商品
6、日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch + logstash + kibana）
7、商品价格监控网站，用户设定某商品的价格阈值，当低于该阈值的时候，发送通知消息给用户，比如说订阅牙膏的监控，如果高露洁牙膏的家庭套装低于50块钱，就通知我，我就去买
8、BI系统，商业智能，Business Intelligence。比如说有个大型商场集团，BI，分析一下某某区域最近3年的用户消费金额的趋势以及用户群体的组成构成，产出相关的数张报表，XX 区，最近3年，每年消费金额呈现100%的增长，而且用户群体85%是高级白领，开一个新商场。ES执行数据分析和挖掘，Kibana进行数据可视化
国内
站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析（ES热门的一个使用场景）
附：
Doug Cutting
1985年，Cutting毕业于美国斯坦福大学。他并不是一开始就决心投身IT行业的，在大学时代的头两年，Cutting学习了诸如物理、地理等常规课程。因为学费的压力，Cutting开始意识到，自己必须学习一些更加实用、有趣的技能。这样，一方面可以帮助自己还清贷款，另一方面，也是为自己未来的生活做打算。因为斯坦福大学座落在IT行业的“圣地”硅谷，所以学习软件对年轻人来说是再自然不过的事情了。
Cutting的第一份工作是在Xerox做实习生，Xerox当时的激光扫描仪上运行着三个不同的操作系统，其中的一个操作系统还没有屏幕保护程序。因此，Cutting就开始为这套系统开发屏幕保护程序。由于这套程序是基于系统底层开发的，所以 其他同事可以给这个程序添加不同的主题。这份工作给了Cutting一定的满足感，也是他最早的“平台”级的作品。
尽管Xerox让Cutting积累了不少技术知识，但他却认为，自己当时搞的这些研究只是纸 上谈兵，没有人试验过这些理论的可实践性。于是，他决定勇敢地迈出这一步，让搜索技术可以为更多人所用。
1997年底，Cutting开始以每周两天的时间投入，在家里试着用Java把这个想法变成现实，不久之后，Lucene诞生了。作为第一个提供全文文本搜索的开源函数库，Lucene的伟大自不必多言。之后，Cutting再接再厉，在 Lucene的基础上将开源的思想继续深化。
2004年，Cutting和同为程序员出身的Mike Cafarella决定开发一款可以代替当时的主流搜索产品的开源搜索引擎，这个项目被命名为Nutch。Doug Cutting 希望以开源架构开发出一套搜索技术，类似于现在的 Google Search 或是微软的 Bing，刚好 2004 年 Google Labs 发布了关于自家大数据分析、MapReduce 算法的论文。Doug Cutting 利用 Google 公开的技术扩充他已经开发出来的 Lucene 搜索技术，进而打造出了 Hadoop。
