ElasticSearch进阶：

核心概念：

索引index：

类型type：

文档document：

字段field：

映射mapping：

分片shards：相当于分表

​ 允许水平切割，扩展容量

​ 允许在分片上进行分布式得、并行的操作，进而提高性能/吞吐量

副本replicas：备份

​ 在分片/节点失败的情况下，提供了高可用。

​ 扩展搜索量/吞吐量，因为搜索可以在所有的副本上并行运行

分配allocation：

​ 将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由master节点完成的。

系统架构：

master节点负责管理集群

分片和分片副本不在同一个节点上

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同
cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者
从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、
删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操
作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节
点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道
任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论
我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将
最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

分布式集群： 单节点集群：

​ 我们在包含一个空节点的集群内创建名为users的索引，为了演示目的，我们将分配3个主分片和一个副本（每个主分片拥有一个副本分片）

http://127.0.0.1:1001/users
{    
    "settings" : {       
        "number_of_shards" : 3,       
        "number_of_replicas" : 1    
    }
}

表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态，硬件故障时有丢失数据的风险

三个主分片正常

3个副本分片都是Unassigned – 它们都没有被分配到任何节点。在同一节点上即保存原始数据又保存副本是没有意义的。因为一旦失去了那个节点，我们也将丢失节点上的所有副本数据。

故障转移：

​ 当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
​ 如果启动了第二个节点，我们的集群将会拥有两个节点的集群 : 所有主分片和副本分片都已被分配

表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

粗线：3 个主分片正常

细线:当第二个节点加入到集群后，3 个副本分片将会分配到这个节点上——每
个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。所
有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们 既可以从主分片又可以从副本分片上获得文档。

水平扩容：

怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将
会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配

表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，
而不是之前的 3 个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片
的性能将会得到提升。
分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有 6 个分
片（3 个主分片和 3 个副本分片）的索引可以最大扩容到 6 个节点，每个节点上存在一个分片，并且每个
分片拥有所在节点的全部资源。

{    
    "number_of_replicas" : 2    
}

每个分片增加一个副本

应对故障：

挂掉1001节点

重启1001节点：

master节点变化

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生
的第一件事情就是选举一个新的主节点： Node 3 。在我们关闭 Node 1 的同时也失去了主
分片 0 和 2 ，如果此时来检查集群的状况，我们看到的状态将会为 yellow。

路由计算：

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个
文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片
1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道
从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

计算公式:hash（id）% 主分片数量 = 【0，1，2】

shard = hash(routing) % number_of_primary_shards

分片控制：

用户可以访问任何一个节点获取数据，这个节点称之为协调节点

写流程：

新建、索引和删除 请求都是 写 操作， 必须在主分片上面完成之后才能被复制到相关
的副本分片

新建，索引和删除文档所需要的步骤顺序：

1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的
   主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2
   的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调
   节点向客户端报告成功。
   在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。

有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很
少使用。

读流程：

我们可以从主分片或者从其它任意副本分片检索文档

从主分片或者副本分片检索文档的步骤顺序：

1. 客户端向 Node 1 发送获取请求。
2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个
   节点上。 在这种情况下，它将请求转发到 Node 2 。
3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。
   在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均
   衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分
   片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一
   旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

更新流程:

部分更新一个文档结合了先前说明的读取和写入流程

部分更新一个文档的步骤如下：

1. 客户端向 Node 1 发送更新请求。
2. 它将请求转发到主分片所在的 Node 3 。
3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片
   的文档。 如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次
   后放弃。
4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的
   副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回
   成功，协调节点向客户端返回成功

多文档操作流程：

mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于
哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求，并且将这些请求并行转
发到每个参与节点。
协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返
回给客户端

用单个 mget 请求取回多个文档所需的步骤顺序:

1. 客户端向 Node 1 发送 mget 请求。
2. Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的
   主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客
   户端。
   可以对 docs 数组中每个文档设置 routing 参数。
   bulk API， 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

bulk API 按如下步骤顺序执行：

1. 客户端向 Node 1 发送 bulk 请求。
2. Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节
   点主机。
3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或
   删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，
   该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。

分片原理：

分片是 Elasticsearch 最小的工作单元。但是究竟什么是一个分片，它是如何工作的？
传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需
要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值
需求的数据结构是倒排索引。

倒排索引：

Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。
见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），
反向索引（inverted index）更熟悉的名字是倒排索引。
所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个
ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数

词条：索引中最小的存储和查询单元

词典：字典，词条的集合，B+ tree，HashMap

倒排表：

文档搜索：

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦
新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。
倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
不变性有重要的价值：

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够
  的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为
  数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。
  当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如
  果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的
  数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。