ElasticSearch - 从这一步开启你的搜索引擎旅程

ElasticSearch - 从这一步开启你的搜索引擎旅程

1.什么是全文搜索引擎？

 我们要学习搜索引擎，我们首先就需要知道什么是搜索，什么又是全文搜索。要想了解这些，就从我们的生活中出发，技术服务于生活才会显得更有意义。
 
 提到搜索引擎，我们第一时间就会想起平常经常使用的百度、谷歌，这两家公司所提供的的主要服务就是搜索网站。


 首先从数据的分类来介绍，我们主要可以分为两种：

1. 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。对于这种数据我们十分熟悉，我们使用的关系型数据库(Mysql或者Oracle)的方式存储和搜索就是结构化数据，我们可以通过建立索引采用BTREE等数据结构快速搜索数据。
    
2. 非结构化数据：全文数据，指不定长度或无固定格式的数据，如邮件，word文档等。对于这种数据，即全文数据的搜索方式主要有顺序扫描法和全文搜索法两种。
    

 对于结构化数据我们已经十分熟悉了，这里我们主要就对于全文数据的搜索方式进行探索。

1. 顺序扫描：根据字面意思我们大胆猜测一下它的搜索方式。没错，就是通过顺序扫描的方式查找到特定的关键字。比如我们阅读一篇博客，要找出ElasticSearch这个名词在哪些地方出现过。我们就需要把这篇博客从头到尾阅读一遍，并且标记出这个关键字出现的位置。
    
   这种方法对于短篇内容来说效率可能还不错，但是如果这篇文章十分长，那么这种方法的效率就可想而知了。
    
2. 全文搜索：对于非结构化数据进行顺序扫描存在性能瓶颈，我们能否想一些方式进行优化呢？如果能够将非结构化数据转化得有一定结构是否可行？我们将非结构化数据中的一部分信息提取出来重新进行组织，使其拥有一定的结构，此时我们再对这些拥有一定结构的数据进行搜索就能够更快地找到我们所需的数据。这就是全文搜索的基本思路，而这一部分从非结构化中提取重组的信息就是索引。
    
   举个栗子，我们贼喜欢逛技术论坛博客，我们现在就是想学ElasticSearch，那怎么样才能快速找到所有关于ElasticSearch的博客呢？全文索引的方式就是将所有博客中技术名词维度来对关键字进行提取，比如ElasticSearch、JVM、Redis等，然后对这些关键字建立索引，维护每个关键字和关联文章的关系，这样我们通过ElasticSearch这个关键字索引就可以快速地找到所有相关的博客了。
    

 那么全文搜索引擎又是什么呢？全文搜索引擎是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词，对每一个词建一个索引，指明该词在文章中出现的次数和位置。当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户。而这就将开始我们的ElasticSearch旅程。

2.为什么不用Mysql做全文搜索？

 在介绍ElasticSearch之前我们要先思考一个问题，为什么全文搜索不用关系型数据库Mysql、Oracle等来实现？我们直接通过数据库查询不就可以了吗？
 
 在没有引入搜索引擎之前，确实我们大部分的功能都是通过数据库去查询的。当出现性能比较低的场景，我们通过创建索引和优化SQL来提升效率。在一些情况我们甚至还引入Redis等缓存来缓解数据库的压力。如果数据量不断变大，我们还可以通过分库分表来分担压力。
 
 这里从几个角度来讲一下为什么我们"强行"要使用全文搜索引擎。

2.1 数据类型

 首先是全文搜索引擎很好地支持了非结构化数据的搜索。例如百度、谷歌的网站搜索，都是根据网页中的关键字生成索引。当我们输入某个关键字的时候，它们就会根据这个关键字索引将匹配的网页数据进行返回；另外一个使用比较多的场景就是应用日志搜索，做后端开发和运维的同学肯定听过ELK，其中就是对应用日志进行收集处理和提供检索的。对于这些非结构化的数据文本，关系型数据库搜索不能够很好的支持。

2.2 搜索性能

 以Mysql为例，假如我们有article表，我们需要根据表中title字段查找出所有包含ElasticSearch的文章，我们的SQL需要怎么写？

select * from article where title like '%ElasticSearch%';

 大家都使用过Mysql。可想而知，当我们的数据量达到百万千万甚至更多的时候，这条SQL的性能有多差了。而全文搜索引擎就很好的解决了这个问题。
 
 全文索引在很多情况下存储的都是长文本类型数据，而我们一般也不会使用关系型数据库存储长文本字段。如果对长文本字段进行全文搜索的话需要扫描全表，数据量起来了之后即使通过各种手段优化效果也不是很好。而且过多的索引也不利于维护，对于insert和update来说都会重新构建索引。

2.3 更加灵活的搜索

 当我们在百度输入ElasticSearch的时候，不但可以对输入的关键词直接进行搜索，还会提供一个关联列表，对于用户来说像是相关推荐。

 而当我们想要搜索Redis相关网站时，由于一时大意少输入一位或者忘记了单词正确应该如何拼写，我们输入redi时可以看到同样给了我们一个关联列表，对于用户来说这个列表更像是一个输入纠正。而搜索引擎还提供了更多其他的功能，使得搜索变得更加高效灵活。

3.ElasticSearch概述

3.1 ElasticSearch是什么？

 讲了半天终于要进入正题了，在介绍ElasticSearch之前给大家推荐一篇文章【浅谈ElasticSearch架构以及集成】。这篇文章主要介绍了聊聊搜索引擎的前世今生，以主人公Doug Cutting为中心对整个搜索引擎的发展进行展开。
 
 Elaticsearch是一个基于Lucene的开源分布式全文搜索引擎。Lucene可以被认为是目前功能最全、性能最好的搜索引擎库。但是Lucene只是一个库，想要使用它就必须将其集成到我们的Java应用中，而且Lucene十分复杂，我们需要深入了解检索的相关知识来理解它是如何工作的才能够更好的使用。
 
 Elasticsearch是使用Java开发并且以Lucene作为核心来实现所有索引和检索的功能，它提供了一个分布式的全文搜索引擎，主要目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而使全文搜索变得更加简单。
 
 Elasticsearch不仅仅是Lucene和全文搜索，以下也可以称之为其特征：

1. 分布式的实时文件存储，每个字段都被索引并可被搜索
2. 分布式的实时分析搜索引擎
3. 可以扩展到上百台服务器，处理PB级结构化或非结构化数据
    

 所有的这些功能被集成到一个服务里，而应用知需要通过简单的RESTful API、各种语言的客户端甚至命令行就能与之交互。
 
 当我们稍微了解Elasticsearch开发团队最初的核心理念和架构设计可以发现它还具备以下几个特征：

1. 开箱即用：安装好ElasticSearch后，所有参数的默认值都自动进行了比较合理的设置，基本不需要额外的调整。包括内置的发现机制(比如Field类型的自动匹配)和自动化参数配置。
2. 天生集群：ElasticSearch默认工作在集群模式下。节点都将视为集群的一部分，而且在启动的过程中自动连接到集群中。
3. 自动容错：ElasticSearch通过P2P网络进行通信，这种工作方式消除了单点故障。节点自动连接到集群中的其它机器，自动进行数据交换及以节点之间相互监控。索引分片
4. 扩展性强：无论是处理能力和数据容量上都可以通过一种简单的方式实现扩展，即增添新的节点。
5. 近实时搜索和版本控制：由于ElasticSearch天生支持分布式，所以延迟和不同节点上数据的短暂性不一致无可避免。ElasticSearch通过版本控制(versioning)的机制尽量减少问题的出现。

3.2 ElasticSearch应用场景

 技术咱们还是要回归应用，那么我们来看看ES被实际应用于哪些场景。

1. 维基百科/百度百科：全文检索、高亮、搜索推荐
2. 腾讯新闻/搜狐新闻：用户行为日志(点击、阅读、收藏、评论、转发)
3. Stack Overflow：IT技术问题以及讨论的检索
4. GitHub：开源代码管理平台，检索代码
5. 淘宝/京东/苏宁：商品信息检索
6. 日志数据分析(ELK)：logstash采集日志、es分析检索数据、kibana展示数据
    

 除了上面我们列举的，其实ES的应用场景还远不如此，数据对象是大量的非结构化的文本数据、文本数据量数百万以上的业务、大量基于交互式的业务查询、灵活的全文搜索都很适合使用全文索引引擎。大家在学完之后可以多思考一下我们还有哪些场景可以引入全文搜索引擎。
 
 关于ElasticSearch大家可以通过官方文档了解一些相关的信息，这里贴出两个个人觉得不错的相关资料供大家参考。
 Mastering Elasticsearch
 Elasticsearch学习，请先看这一篇！

4.常见的搜索引擎

 到这里小伙伴们对ES也有了一个大概的认识，那么我们为什么要选择ES而没有选择其他的搜索引擎呢，这里我们对常见的几款搜索引擎做一个比较。

4.1 Lucene

 Lucene是Apache软件基金会的一个子项目，是一个开放源代码的全文检索引擎工具包，
不是一个完整的全文检索引擎，但是提供了完整的查询引擎和索引引擎以及有限的文本分析引擎。
 
 Lucene提供了一个简单却强大的应用程式接口，能够做全文索引和检索。在Java开发环境里Lucene是一个成熟的免费开源工具。而且Lucene是当前以及最近几年最受欢迎的免费Java信息检索程序库。
 
 我们简单地总结就是以下几点：

1. 从功能方面来讲，Lucene通过简单的API接口就能提供强大的功能。支持可扩展的高性能索引；拥有强大、准确、高效的搜索算法；提供跨平台解决方案。
2. 从背景上来讲，由于属于Apache软件基金会，所以很好的得到了Apache社区的支持。但是由于仅仅只是一个工具包，所以要想充分利用其功能首先需要熟悉Java编程。并且在程序中集成Lucene需要对其进行更深入的学习了解，才能够熟悉其特性和运行原理，所以想要熟练运用Lucene也是有一定难度的。

4.2 Solr

 Solr是一个基于Lucene的开源搜索平台，同样也是Apache下的一个顶级Java开源项目。提供了比Lucene更为丰富的搜索功能，并且实现了可配置、可拓展的特点，同时对索引、检索性能进行了优化。
 
 Solr可以独立运行在Web服务器上，并且索引的实现方式也很简单，我们只需要通过POST请求给Solr服务器发送特定描述性质的XML文档即可，Solr就会根据XML文档的内容去添加、删除、更新索引；而我们只需通过发送GET请求就可以从Solr服务器检索索引结果。
 
 Solr也提供了分布式索引、负载均衡查询以及自动故障转移和恢复等功能。如果我们对Solr熟悉并且部署管理得当，那Solr就能够成为一个高度可靠、可扩展并且容错性强的搜索引擎。

4.3 Elasticsearch

 对于ES上面我们已经介绍得非常详细啦，这里我们主要就总结一下ES的几个特点。
 
 首先ES是一个基于Lucene的实时分布式搜索分析引擎。提供了快速的分布式全文搜索、数据分析、分组以及聚合等主要功能。
 
 可支持Java，Groovy，PHP，Ruby，Perl，Python等多种语言的集成，通过简单的RESTful API来隐藏Lucene的复杂性，使得全文搜索变得十分简单。并且提供许多插件以支持分词、可视化管理等各种功能。

4.4 Elasticsearch和Solr比较

 由于我们所介绍的两款搜索引擎都是基于Lucene检索包，所以这里我们直接比较ES和Solr。老规矩，先来一张百度指数上关于ES和Solr搜索指数的比较图。

 很明显可以看到随着时间的推移，ES的增长速度十分迅速并且现在已经持续多于Slor；而Solr虽然整体没有ES热度高，但是处于一种十分平缓的状态，这完全依赖于拥有一个核心的用户群体和成熟已经成型的社会。
 
 我们根据上面的总结一下ES和Solr的区别：

1. ES开箱即用相对简单；而Solr的安装使用则稍微复杂一点。
2. ES自带分布式协调管理功能；而Solr需要配合Zookeeper进行分布式协调管理。
3. ES仅支持JSON格式索引；而Solr支持JSON、XML等更多格式的数据。
4. ES更注重核心功能，高级功能由第三方插件提供；而Solr官方提供的功能则较多。
5. ES更新索引时查询快，即实时查询快；而Solr更新索引时查询慢，不更新索引时查询快。
6. ES相对开发维护者较少、更新快、学习成本高；而Solr较为成熟，有更大、更成熟的用户、开发和维护者社区。但ES是目前的一个趋势。
    

 既然作为搜索引擎，那么我们从最核心搜索效率方面再来比较一下：

1. 当单纯的对已有数据进行搜索时，Solr更快。
2. 当实时建立索引时, Solr会产生io阻塞，查询性能较差；而ES则具有更明显的优势。
3. 随着数据量的增加，Solr的搜索效率会变得更低；而ES却没有明显的变化。
4. Solr的架构不适合实时搜索的应用。
5. Solr 在传统的搜索应用中表现好于 ES；但在处理实时搜索应用时效率明显低于 ES。