为什么要用ES集群？

Elasticsearch（ES）是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。Elasticsearch还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，可以在极短的时间内存储、搜索和分析大量的数据。
用户对数据进行新建或编辑的操作，这些数据都会被存在ES中，当用户使用搜索功能对想要的目标数据进行搜索时，逻辑流程如下：
客户端传入搜索的参数 - 调用服务端搜索接口 - 服务端通过接口实现去ES中查询已储存的现成的数据 - 将查询结果返回给客户端。
对比如果不用ES，调用服务端接口时会通过sql语句去数据库查询然后给客户端返回查询结果，这样是相当慢的。
大家都很熟悉数据库，为了简单理解，搞清里面的结构，先来一个ES与数据库的类比关系:

ES数据架构的主要概念（与关系数据库Mysql对比）

关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)
（1）关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）
（2）一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type）
（3）一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。
（4）在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。
（5）在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET.

ES核心概念

1）Cluster：集群。

ES可以作为一个独立的单个搜索服务器。不过，为了处理大型数据集，实现容错和高可用性，ES可以运行在许多互相合作的服务器上。这些服务器的集合称为集群。

2）Node：节点。

形成集群的每个服务器称为节点。

3）Index：索引。

在 ES 中, 索引是一组文档的集合。索引的作用相当于图书的目录，可以根据目录中的页码快速找到所需的内容。当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索，是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘I/O操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID（相当于页码）快速找到表中对应的记录。

4）Shard：分片。

当有大量的文档时，由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等，一个节点可能不够。这种情况下，数据可以分为较小的分片。每个分片放到不同的服务器上。
当你查询的索引分布在多个分片上时，ES会把查询发送给每个相关的分片，并将结果组合在一起，而应用程序并不知道分片的存在。即：这个过程对用户来说是透明的。
需要注意：在创建索引的时候就确定好主分片的数量，并且永远不能改变这个数量。

 

分片.jpg

 

比如上图所示，开始设置为5个分片，在单个节点上，后来扩容到5个节点，每个节点有一个分片。如果继续扩容，是不能自动切分进行数据迁移的。官方文档的说法是分片切分成本和重新索引的成本差不多，所以建议干脆通过接口重新索引。

路由一个文档到一个分片

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，唯一不可重复，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档 API( get 、 index 、 delete 、 bulk 、 update 以及 mget )都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。

5）Replia：副本。

为提高查询吞吐量或实现高可用性，可以使用分片副本。
副本是一个分片的精确复制，每个分片可以有零个或多个副本。ES中可以有许多相同的分片，其中之一被选择更改索引操作，这种特殊的分片称为主分片。
当主分片丢失时，如：该分片所在的数据不可用时，集群将副本提升为新的主分片。
Elasticsearch 禁止同一个分片的主分片和副本分片在同一个节点上，所以如果是一个节点的集群是不能有副本的。

 

它在节点失败的情况下提供高可用性。由于这个原因，需要注意的是，副本分片永远不会分配到与主分片相同的节点上。

ES集群简图

详解

1.我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点
2.新建索引和删除请求都是写操作，它们必须在主分片上成功完成才能赋值到相关的复制分片上
3.在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：
(1) 客户端给Node1 发送新建、索引或删除请求。
(2) 节点使用文档的_id确定文档属于分片0.转发请求到Node3，分片0位于这个节点上。
(3) Node3在主分片上执行请求，如果成功，它转发请求到相应的位于Node1和Node2的复制节点上。当所有的复制节点报告成功，Node3报告成功到请求的节点，请求的节点再报告给客户端。
(4)客户端接收到成功响应的时候，文档的修改已经被用于主分片和所有的复制分片，修改生效了。

ES分片复制

复制默认的值是sync。这将导致主分片得到复制分片的成功响应后才返回。
如果你设置replication为async,请求在主分片上被执行后就会返回给客户端。它依旧会转发给复制节点，单你将不知道复制节点成功与否。
上面的这个选项不建议使用。默认的sync复制允许ES强制反馈传输。async复制可能会因为在不等待其他分片就绪的情况下发送过多的请求而使ES过载。

6）全文检索。

全文检索就是对一篇文章进行索引，可以根据关键字搜索，类似于mysql里的like语句。
全文索引就是把内容根据词的意义进行分词，然后分别创建索引，例如”你们的激情是因为什么事情来的” 可能会被分词成：“你们“，”激情“，“什么事情“，”来“ 等token，这样当你搜索“你们” 或者 “激情” 都会把这句搜出来。

Elasticsearch是如何做到快速索引的

Elasticsearch的索引思路:
将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数。
Elasticsearch是通过Lucene的倒排索引技术实现比关系型数据库更快的过滤。倒排索引很多地方都有介绍，但是其比关系型数据库的b-tree索引快在哪里？到底为什么快呢？
这里有好几个概念。我们来看一个实际的例子，假设有如下的数据：
docid 年龄 性别
1 18 女
2 20 女
3 18 男
这里每一行是一个document。每个document都有一个docid。那么给这些document建立的倒排索引就是：
年龄
18 [1,3]
20 [2]
性别
女 [1,2]
男 [3]
可以看到，倒排索引是per field的，一个字段有一个自己的倒排索引。18,20这些叫做 term，而[1,3]就是posting list。Posting list就是一个int的数组，存储了所有符合某个term的文档id。那么什么是term dictionary 和 term index？
假设我们有很多个term，比如：
姓名：Carla,Sara,Elin,Ada,Patty,Kate,Selena
如果按照这样的顺序排列，找出某个特定的term一定很慢，因为term没有排序，需要全部过滤一遍才能找出特定的term。排序之后就变成了：
Ada,Carla,Elin,Kate,Patty,Sara,Selena
这样我们可以用二分查找的方式，比全遍历更快地找出目标的term。这个就是 term dictionary。有了term dictionary之后，可以用 logN 次磁盘查找得到目标。但是磁盘的随机读操作仍然是非常昂贵的（一次random access大概需要10ms的时间）。所以尽量少的读磁盘，有必要把一些数据缓存到内存里。但是整个term dictionary本身又太大了，无法完整地放到内存里。于是就有了term index。term index有点像一本字典的大的章节表。比如：
A开头的term ……………. Xxx页
C开头的term ……………. Xxx页
E开头的term ……………. Xxx页

 

如果所有的term都是英文字符的话，可能这个term index就真的是26个英文字符表构成的了。但是实际的情况是，term未必都是英文字符，term可以是任意的byte数组。而且26个英文字符也未必是每一个字符都有均等的term，比如x字符开头的term可能一个都没有，而s开头的term又特别多。实际的term index是一棵trie 树：

Alt text

例子是一个包含 "A", "to", "tea", "ted", "ten", "i", "in", 和 "inn" 的 trie 树。这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。再加上一些压缩技术（搜索 Lucene Finite State Transducers） term index 的尺寸可以只有所有term的尺寸的几十分之一，使得用内存缓存整个term index变成可能。整体上来说就是这样的效果。

Alt text

现在我们可以回答“为什么Elasticsearch/Lucene检索可以比mysql快了。Mysql只有term dictionary这一层，是以b-tree排序的方式存储在磁盘上的。检索一个term需要若干次的random access的磁盘操作。而Lucene在term dictionary的基础上添加了term index来加速检索，term index以树的形式缓存在内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘的random access次数。
额外值得一提的两点是：term index在内存中是以FST（finite state transducers）的形式保存的，其特点是非常节省内存。Term dictionary在磁盘上是以分block的方式保存的，一个block内部利用公共前缀压缩，比如都是Ab开头的单词就可以把Ab省去。这样term dictionary可以比b-tree更节约磁盘空间。