elasticsearch 简介

elasticsearch 简介

简介

Elasticsearch（ES）是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。Elasticsearch还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，ES能够横向扩展至数以百计的服务器存储以及处理PB级的数据。可以在极短的时间内存储、搜索和分析大量的数据。

---

Elasticsearch基本概念

• Near Realtime(NRT) 几乎实时

Elasticsearch是一个几乎实时的搜索平台。意思是，从索引一个文档到这个文档可被搜索只需要一点点的延迟，这个时间一般为毫秒级。

• Cluster 集群

1. 群集是一个或多个节点（服务器）的集合， 这些节点共同保存整个数据，并在所有节点上提供联合索引和搜索功能。一个集群由一个唯一集群ID确定，并指定一个集群名（默认为“elasticsearch”）。该集群名非常重要，因为节点可以通过这个集群名加入群集，一个节点只能是群集的一部分。

2. 确保在不同的环境中不要使用相同的群集名称，否则可能会导致连接错误的群集节点。例如，你可以使用logging-dev、logging-stage、logging-prod分别为开发、阶段产品、生产集群做记录。

• Node节点

1. 节点是单个服务器实例，它是群集的一部分，可以存储数据，并参与群集的索引和搜索功能。就像一个集群，节点的名称默认为一个随机的通用唯一标识符（UUID），确定在启动时分配给该节点。

2. 我们可以通过群集名配置节点以连接特定的群集。默认情况下，每个节点设置加入名为“elasticSearch”的集群。这意味着如果你启动多个节点在网络上，假设他们能发现彼此都会自动形成和加入一个名为“elasticsearch”的集群。

3. 在单个群集中，你可以拥有尽可能多的节点。此外，如果“elasticsearch”在同一个网络中，没有其他节点正在运行，从单个节点的默认情况下会形成一个新的单节点名为”elasticsearch”的集群。

• Index索引

索引是具有相似特性的文档集合。例如，可以为客户数据提供索引，为产品目录建立另一个索引，以及为订单数据建立另一个索引。索引由名称（必须全部为小写）标识，该名称用于在对其中的文档执行索引、搜索、更新和删除操作时引用索引。在单个群集中，你可以定义尽可能多的索引。

• Type类型

在索引中，es6,7 已经弱化了type 的概念 _doc

• Document文档

1.文档是可以被索引的信息的基本单位。例如，你可以为单个客户提供一个文档，单个产品提供另一个文档，以及单个订单提供另一个文档。本文件的表示形式为JSON（JavaScript Object Notation）格式，这是一种非常普遍的互联网数据交换格式。

2.在索引/类型中，你可以存储尽可能多的文档。请注意，尽管文档物理驻留在索引中，文档实际上必须索引或分配到索引中的类型

• 分片 shard

Elasticsearch集群允许系统存储的数据量超过单机容量，实现这一目标引入分片策略shard。在一个索引index中，数据（document）被分片处理（sharding）到多个分片上。Elasticsearch屏蔽了管理分片的复杂性，使得多个分片呈现出一个大索引的样子。

• 路由 routing

当向Elasticsearch存放数据时，根据文档标识符_id将文档分配到多个分片上，负载均衡算法只需要实现平均即可。当取用数据时，查询所有的分片然后汇总结果，而并不必须知道数据到底存在哪个分片上。带来的问题是，在查询时，要查询所有的分片然后汇总结果，造成性能的损耗，在不乐观的情况下，有些分片的查询可能失败(failed)，造成结果不准确。为了避免这个问题，引入了路由功能（routing），在存入时通过路由键将数据存入指定分片，在查询的时候可以通过相同的路由键指明在哪个分片将数据查出来

---

elastic 原理

1. elasticsearch 写入过程

• 不断将 Document 写入到 In-memory buffer（内存缓冲区）。
• 当满足一定条件后内存缓冲区中的 Documents 刷新到高速缓存（cache）。
• 生成新的 segment，这个 segment 还在 cache 中。
• 这时候还没有commit，但是已经可以被读取了。
• 数据从 buffer 到 cache 的过程是定期每秒刷新一次。所以新写入的 Document 最慢 1 秒就可以在 cache 中被搜索到。
• 而 Document 从 buffer 到 cache的过程叫做 ?refresh。一般是1秒刷新一次，不需要进行额外修改。

2. elasticsearch Translog 事务日志

• Document 不断写入到 In-memory buffer，此时也会追加 translog。
• 当 buffer 中的数据每秒 refresh 到 cache 中时，translog 并没有进入到刷新到磁盘，是持续追加的。
• translog 每隔 5s 会 fsync 到磁盘。
• translog 会继续累加变得越来越大，当 translog 大到一定程度或者每隔一段时间，会执行 flush。
  

3. elasticsearch flash操作

• buffer 被清空。
• 记录 commit point。
• cache 内的 segment 被fsync刷新到磁盘。
• translog 被删除。
• translog 执行 flush 操作，默认 30 分钟一次，或者 translog 太大也会执行。\
• 手动执行

POST /cms_index/_flush

4. elasticsearch 删除更新

• segment 不可改变，所以 docment 并不能从之前的 segment 中移除或更新。
• 所以每次 commit， 生成 commit point 时，会有一个 .del 文件，里面会列出被删除的 document（逻辑删除）。
• 而查询时，获取到的结果在返回前会经过 .del 过滤。更新时，也会标记旧的 docment 被删除，写入到 .del 文件，同时会写入一个新的文件。
• 此时查询会查询到两个版本的数据，但在返回前会被移除掉一个。

5. elasticsearch segment 合并

• 每 1s 执行一次 refresh 都会将内存中的数据创建一个 segment。
  segment 数目太多会带来较大的麻烦。每一个 segment 都会消耗文件句柄、内存和 cpu 运行周期。
• 更重要的是，每个搜索请求都必须轮流检查每个 segment ；所以 segment 越多，搜索也就越慢。

在 ES 后台会有一个线程进行 segment 合并

1. refresh 操作会创建新的 segment并打开以供搜索使用。
2. 合并进程选择一小部分大小相似的 segment，并且在后台将它们合并到更大的 segment 中。这并不会中断索引和搜索。
3. 当合并结束，老的 segment 被删。

合并完成时的活动

1. 新的 segment 被刷新（flush）到了磁盘。 写入一个包含新 segment 且排除旧的和较小的 segment的新 commit point。
2. 新的 segment 被打开用来搜索。
3. 老的 segment 被删除。

6. 总结

Elatic 与 Mysql

• 对照关系

elasticsearch	mysql	描述
Index	Databases	Elasticsearch集群可以包含多个索引index数据库
Types	Tables	每一个索引可以包含多个类型 types表（7之后默认只能有一个 _doc）
Documents	Rows	每一个类型包含多个文档documents行
Fields	Columns	每个文档包含多个字段 Fields列

• elasticsearch为什么比mysql快

1.mysql关系型数据库索引原理

2.elasticsearch倒排索引原理

两者对比

• 对于倒排索引，要分两种情况：

1. 基于分词后的全文检索

这种情况是es的强项，而对于mysql关系型数据库而言完全是灾难,因为es分词后，每个字都可以利用FST高速找到倒排索引的位置，并迅速获取文档id列表,但是对于mysql检索中间的词只能全表扫（如果不是搜头几个字符）

2. 精确检索

这种情况我想两种相差不大，有些情况下mysql的可能会更快些,如果mysql的非聚合索引用上了覆盖索引，无需回表，则速度可能更快,es还是通过FST找到倒排索引的位置并获取文档id列表，再根据文档id获取文档并根据相关度算分进行排序，但es还有个杀手锏，即天然的分布式使得在大数据量面前可以通过分片降低每个分片的检索规模，并且可以并行检索提升效率