ElasticSearch学习笔记（一）

思考

现在我们有一座图书馆，管理员非常想找标题或是内容里包含魔法字样的书籍，如果按照一般的思路去寻找的话，就是一本一本书去回忆标题和内容，记不住的就得去挨个查询（一页一页去翻），这简直太费劲了，甚至说得累死这个管理员（整个图书馆得多少书啊），但是我们换个角度从反面去思考这个问题，如果一开始我们就下功夫把标题中含有魔法字样的书籍检索记录下来，那么是不是事情变得简单了，反正都是要看所有内容的，我何不提前就把东西准备好呢？

从这个思路出发，你就具备了倒排索引的思想，按照正向的逻辑，应该是这本书中有魔法字样，key是书籍，value是魔法，我们能获取这个集合的办法就是从头看书籍的内容（查阅key），来确定是不是含有这个魔法字样（value），但是倒排索引，选择把魔法作为key，书籍作为value，逻辑是魔法字样在这个本书中，我们一开始就把所有含有魔法字样书籍整理出来加以保存，这样我管理员去找这个含有魔法字样的书籍就易如反掌了，这就是elasticSearch中的核心思想————倒排索引

有没有种感觉，这上面的过程和咱们浏览器的搜索功能很相似，下面举个例子，我搜了一个加油

是根据加油来检索相关内容的，没错，像浏览器这种拥有海量数据的搜索引擎的核心都是建立倒排索引，与上面管理员找书异曲同工，只不过浏览器中还有一些其他的相关业务而已，比如说网页内容的爬取，停顿词过滤等等，网页的爬取我们都知道，就是把文章相关内容全都拿到，但是停顿词过滤是什么呢？我现在这里有句话，我今天非常的想上班，这里面的“的”，这种本身没什么意义的词语，不需要放进索引的考虑范围内，这就叫做分词过滤也就是常说的分词，这样一个搜索引擎的建立步骤就知道了

1.内容爬取

2.停顿词过滤（分词）

3.建立反向索引

这个工作量无疑是巨大的，但是已经有大佬创造了elasticSearch，也就是我们今天的主角。

elasticSearch介绍

其实 ES 说白了，就是一个专门用来做搜索的工具。我们平时用的 MySQL，它的本职工作是存数据、查数据、做业务增删改查。但它非常不擅长「全文搜索」。举个很直观的例子：如果数据库里有几万条古籍、诗词、文章数据，你想用 MySQL 的模糊查询搜一个关键词，它的逻辑就是从头到尾遍历所有数据，一条条比对，数据量一大，速度就会变得巨慢，而且搜出来的结果乱七八糟，没有优先级。而 Elasticsearch 就是专门为了解决这个痛点诞生的。它底层帮我们提前做好了分词、建好倒排索引。别人搜关键词的时候，它不用遍历全部数据，直接查表匹配，所以搜索速度特别快，基本上都是毫秒级响应。

接下来再讲讲es中的相关概念

1、索引（Index）

你可以直接把它理解成 MySQL 里的一张数据表。我要存古籍数据，就建一个古籍索引；我要存诗词数据，就建一个诗词索引。同一类的数据，统一放在一个索引里面管理。

2、文档（Document）

文档就是 ES 里最小的一条数据，对应 MySQL 表里的一行数据。一本古籍、一首诗词、一条资讯，在 ES 里都叫一个文档，格式就是 JSON，里面包含标题、内容、作者这些字段。

3、分片与副本

如果我的数据量超级大，一台服务器存不下、也扛不住压力，怎么办？

ES 就会把大的索引拆开，分成好几份「主分片」，分散放到不同服务器上。同时还会备份几份「副本分片」，万一某一台机器挂了，备份能直接顶上，保证数据不丢、服务不崩，这就是 ES 分布式、高可用的优势。这里有一个超级形象的图

4、相关性得分（score）

这也是 MySQL 做不到的一点。我们搜索一个关键词，有的文章匹配度高、关键词多，有的匹配度低。ES 会自动给每一条结果打分，匹配越贴合分数越高，排在最前面，搜出来的结果特别贴合用户需求。

简单总结一下：

MySQL 适合老老实实存业务数据，做增删改查；Elasticsearch 专门负责高性能、高质量的全文搜索。所以在做项目的时候，我会选择用 MySQL 做主数据存储，配合 Elasticsearch 实现全站的全文检索功能，解决大数据量下搜索卡顿、匹配效果差的问题。