<span>ElasticSearch简介</span>

目录

• [TOC]
• 1. 定义
• 2. 与 Lucene 的关系
• 3. 优点
• 4. 缺点
• 5. 解决的问题
• 6. 应用场景
• 7. 倒排索引(摘自Elasticsearch权威指南)

1. 定义

Elasticsearch 是一个高度可扩展的开源全文搜索和分析引擎。它允许您快速，近实时地存储，搜索和分析大量数据。它通常用作底层引擎、技术，为具有复杂搜索功能和要求的应用程序提供支持。

Elasticsearch 也使用 Java 开发并使用 Lucene 作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API 来隐藏 Lucene 的复杂性，从而让全文搜索变得简单。

ES 是基于Lucene这个非常成熟的索引方案，另加上一些分布式的实现：集群，分片，复制等。

2. 与 Lucene 的关系

Lucene 是一套用于全文检索和搜寻的开源程式库，由 Apache 软件基金会支持和提供。Lucene 提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。但是 Lucene 操作复杂，一般不直接利用 Lucene 作为搜索引擎，ElasticSearch 就是利用 Java 简化了 Lucene 的使用。

3. 优点

1. 具备横向可扩展性：只需要增加一台服务器，做些配置，启动 ES 进程就可以快速并入集群。'
2. 分片机制：同一个索引分成多个分片(sharding)，类似于 redis 中的分片，采取分而治之的思想来更好地解决问题。
3. 高可用：提供复制机制，一个分片可以设置多个复制，使得某台服务器宕机的话，集群依旧可以正常运行，并会把丢失的复制恢复到其它可用节点上'

4. 缺点

1. 节点数据的一致性问题：其默认的机制是通过多播机制，同步元数据信息，但是在比较繁忙的集群中，可能会由于网络的阻塞，或者节点处理能力达到饱和导致各节点元数据不一致——也就是所谓的脑裂问题，这样会使集群处于不一致状态。目前并没有一个彻底的解决方案来解决这个问题，但是可以通过将工作节点与元数据节点分开的部署方案来缓解这种情况。
2. 没有细粒度的权限管理，没有像MySQL那样的分各种用户，每个用户又有不同的权限。

5. 解决的问题

• 更快的在大量数据中检索相关数据，性能远优于传统数据库
• 结合分词器，根据关键词返回统计结果

6. 应用场景

• 全文检索：例如淘宝 app 搜索 17寸电脑关键词，搜索系统将依据关键词分词查询，按照指定的匹配度返回对应的商品。这是 ES 最核心也是最常用的功能。
• 记录和日志分析：围绕Elasticsearch构建的生态系统使其成为最容易实施和扩展日志记录解决方案之一。结合Logstash，ElasticSearch 和Kibana 三个组件，可以搭建一套高效的日志收集和分析系统，也就是我们常见的ELK系统。
• 数据可视化：Kibana 是一款功能强大且易于使用的可视化工具，可以结合 ES 对大量数据提供图表选项、地理数据等可视化组件。

7. 倒排索引(摘自Elasticsearch权威指南)

Elasticsearch 是通过 Lucene 的倒排索引技术实现比关系型数据库更快的过滤。特别是它对多条件的过滤支持非常好。

Elasticsearch 使用一种称为 倒排索引 的结构，它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。

例如，假设我们有两个文档，每个文档的 content 域包含如下内容：

1. The quick brown fox jumped over the lazy dog
2. Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条 或 tokens），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：

Term      Doc_1  Doc_2
-------------------------
Quick   |       |  X
The     |   X   |
brown   |   X   |  X
dog     |   X   |
dogs    |       |  X
fox     |   X   |
foxes   |       |  X
in      |       |  X
jumped  |   X   |
lazy    |   X   |  X
leap    |       |  X
over    |   X   |  X
quick   |   X   |
summer  |       |  X
the     |   X   |
------------------------

现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：

Term      Doc_1  Doc_2
-------------------------
brown   |   X   |  X
quick   |   X   |
------------------------
Total   |   2   |  1

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

• Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
• fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。
• jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。

使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。

我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。

如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：

• Quick 可以小写化为 quick 。
• foxes 可以 词干提取 --变为词根的格式-- 为 fox 。类似的， dogs 可以为提取为 dog 。
• jumped 和 leap 是同义词，可以索引为相同的单词 jump 。

现在索引看上去像这样：

Term      Doc_1  Doc_2
-------------------------
brown   |   X   |  X
dog     |   X   |  X
fox     |   X   |  X
in      |       |  X
jump    |   X   |  X
lazy    |   X   |  X
over    |   X   |  X
quick   |   X   |  X
summer  |       |  X
the     |   X   |  X
------------------------

这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox ，这样两个文档都会匹配！