elasticsearch基础4——es核心名词概念、es节点自动发现机制、节点类型、数据写入流程、对比关系型数据库

一、es核心概念

• es官网名词概念解释

1.1 节点（Node）

概念：

• Node：代表节点，是组成 Elasticsearch 集群的基本服务单元，集群中的每个运行中的Elasticsearch 服务器都可称之为节点。

1.2 集群（Cluster）

概念：

• Cluster：代表集群。Elasticsearch 的集群是由具有相同 cluster.name (默认值为elasticsearch)的一个或多个 Elasticsearch 节点组成的，各个节点协同工作，共享数据。

注意事项：

1. 同一个集群内的各个节点名字不能重复，但集群名称一定要相同。
2. 在实际使用 Elasticsearch 集群时，一般需要给集群起一个合适的名字来替代 cluster.name的默认值。自定义集群名称的好处是，可以防止一个新启动的节点加入相同网络中的另一个同名的集群中。

集群节点状态判断指标（重点）：

• 在 Elasticsearch 集群中，节点的状态有 Green、Yellow 和 Red 三种：
  1. Green（绿色）：表示节点运行状态为健康状态。所有的主分片和副本分片都可以正常工作，集群 100%健康。
  2. Yellow（黄色）：表示节点的运行状态为预警状态。所有的主分片都可以正常工作，但至少有一个副本分片是不能正常工作。此时集群依然可以正常工作，但集群的高可用性在某种程度上被弱化。
  3. Red（红色）：表示集群无法正常使用。此时，集群中至少有一个分片的主分片及它的全部副本分片都不可正常工作。虽然集群的查询操作还可以进行，但是也只能返回部分数据(其他正常分片的数据可以返回)，而分配到这个有问题分片上的写入请求将会报错，最终导致数据丢失。

1.3 分片（Shards）

概念：

• Shards：代表分片。当索引的数据量太大时，受限于单个节点的内存、磁盘处理能力等节点无法足够快地响应客户端的请求，此时需要将一个索引上的数据进行水平拆分。拆分出来的每个数据部分称之为一个分片。

注意事项：

1. 实际应用中，每个分片都会放到不同的服务器上。进行分片操作之后，索引在规模上进行扩大，性能也会提升。
2. es依赖 Lucene，es中的每个分片都是 Lucene 中的一个索引文件，所以每个分片必须有一个主分片和零到多个副本分片。
3. 当设置有多分片的索引中写入数据时，是通过路由来确定具体写入哪个分片中的，因此在创建索引时需要指定分片的数量，并且分片的数量一旦确定就不能更改。
4. 当查询索引时，需要在索引对应的多个分片上进行查询。es会把查询发送给每个相关的分片，并汇总各个分片的查询结果。
5. 对上层的应用程序而言，分片是透明的，也就是说应用程序并不知道分片的存在。

1.4 备份（Replicas）

概念：

• Replicas：表示备份，也称为副本。指对主分片的备份，这种备份是精确复制模式。
• 每个主分片可以有零个或多个副本，主分片和备份分片都可以对外提供数据查询服务。当构建索引进行写入操作时，首先在主分片上完成数据的索引，然后数据会从主分片分发到备份分片上进行索引。

注意事项：

• 当主分片不可用时，Elasticsearch 会在备份分片中选举出一个分片作为主分片，从而避免数据丢失。
• 备份分片既可以提升 Elasticsearch 系统的高可用性能，又可以提升搜索时的并发性能。
• 若备份分片数量设置得太多，则在写操作时会增加数据同步的负担。

1.5 索引（Index）

概念：

• Index：表示索引。在 Elasticsearch 中，索引由一个和多个分片组成。

注意事项：

• 在使用索引时，需要通过索引名称在集群内进行唯一标识。

1.6 类别（Type）

概念：

• Type：表示类别，指索引内部的逻辑分区，通过 Type 的名字在索引内进行唯一标识。

注意事项：

• 在查询时如果没有该值，则表示需要在整个索引中查询。

1.7 文档（Document）

概念：

• Document：表示文档。索引中的每一条数据叫作一个文档，一条文档数据通过 id 在 Type 内进行唯一标识。

1.8 其他字段含义

概念：

• Settings：Settings是对集群中索引的定义信息，比如一个索引默认的分片数、副本数等。
• Mapping：Mapping 表示定义索引中字段(Field)的存储类型、分词方式是否存储等信息，类似于mysql数据库中的表结构信息。
  • 在es中，Mapping 可以动态识别。如果没有特殊需求，则不需要手动创建 Mapping，因为 Elasticsearch 会根据数据格式自动识别它的类型。当需要对某些字段添加特殊属性时，如定义使用其他分词器、是否分词、是否存储等，就需要手动设置 Mapping 。
  • 一个索引的 Mapping一旦创建，若已经存储了数据，就不可修改了。
• Analyzer：表示字段分词方式的定义。
  • 一个 Analyzer 通常由一个Tokenizer 和零到多个 Filter 组成。
  • 在es中，默认的标准Analyzer包含一个标准的Tokenizer 和三个 Filter，即 Standard Token Filter、 Lower Case Token Filter 和 Stop Token Filter。

二、es架构设计

• 如图所示，可以把es架构分为五层，分别是核心层、数据处理层、发现与脚本层、协议层和应用层。

es架构五层：

• 核心层：是指 Lucene框架，es是基于 Lucene框架实现的。
• 数据处理层：指在es中对数据的加工处理方式。常见的主要有Index (索引)模块、Search(搜索)模块和 Mapping(映射)模块。
• 发现与脚本层：主要是 Discovery(节点发现)模块、Script (脚本)模块和第三方插件模块。
  • Discovery 模块，是es自动发现节点的机制。
  • Script模块，支持脚本的执行。脚本的应用会让查询出来的数据加工处理更为方便。目前 Elasticsearch 支持 JavaScript、Python 等多种语言。
  • 第三方插件模块，表示es支持安装很多第三方的插件，如elasticsearch-ik 分词插件、elasticsearch-sql插件等。
• 协议层：是es中的数据交互协议。目前es支持 Thrift、Memcached 和HTTP三种协议，默认是 HTTP协议。
  • JMX 指的是在 Elasticsearch 中对 Java的管理框架，用来管理es应用。
• 应用层：指es的 API 支持模式。es的特色之一就是 RESTFul 风格的API。

2.1 es节点自动发现机制

为什么会存在es节点自动发现机制？

• 因为在es内部，我们可以通过在集群中配置一个相同的集群名称（clustername)，就能将不同的节点连接到同一个集群。而这个过程中就使用了节点自动发现机制。

四种自动发现机制：

• es内嵌自动发现功能，提供了四种发现机制。其中一种是默认实现，其他都是通过插件来实现。

1. Azure discovery 插件方式：多播模式。
2. EC2 discovery 插件方式：多播模式。
3. Google Compute Engine (GCE) discovery 插件方式：多播模式。
4. Zen Discovery，支持多播模式和单播模式。（默认机制）
   • Zen Discovery 是es内置的默认发现模块。发现模块用于发现集群中的节点及选举主节点(master 节点)。
   • Zen Discovery 提供单播模式和基于文件的发现，并且可以扩展为通过插件支持其他形式的发现机制。

2.1.1 多播模式和单播模式的配置参数

discovery.zen.ping.multicast.enabled: true
discovery.zen.fd.ping timeout: 100s
discoveryzen.ping.timeout: 100s
discovery.zen.minimum master nodes:2
discovery.zen.ping.unicast.hosts: ["172.31.X.Y"]
discovery.zen.ping.multicast.enabled

参数释义：

• discovery.zen.ping.multicast.enabled参数：表示关闭多播模式的自动发现机制，主要是为了防止其他机器上的节点自动连入。
• discovery.zen.fd.ping timeout参数、discovery.zen.ping.timeout 参数：表示设置了节点与节点之间连接 ping命令执行的超时时长
• discovery.zenminimum master nodes参数：表示集群中选举主节点时至少需要有多少个节点参与。
• discovery.zen.ping.unicast.hosts参数：表示在单播模式下，节点应该自动发现哪些节点列表。
• action.auto create index:false参数：表示关闭自动创建索引。

2.1.2 单播模式

注意事项一：

• es支持多播模式和单播模式两种节点自动发现机制，不过多播模式已经不被大多数操作系统所支持，加之其安全性不高，所以一般我们会主动关闭多播模式。
• 在es中，发现机制默认被配置为使用单播模式，以防止节点无意中加入集群。

#配置参数，关闭多播。
discovery.zen.ping.multicast.enabled: false  

注意事项二：

• Elasticsearch 支持同一个主机启动多个节点，因此只有在同一台机器上运行的节点才会自动组成集群。
• 当集群的节点运行在不同的机器上时，在单播模式下，我们需要为es配置一些它应该去尝试连接的节点列表，配置方式如下所示:

#配置参数，填写集群中的 IP地址列表。
discovery.zen.ping.unicast.hosts: ["192.168.130.145:9300","192.168.130.146:9300"]

#示例配置，单播模式下的配置信息汇总如下。
discovery.zen.ping.multicast.enabled: false
discovery.zen.fd.ping timeout:100s
discoveryzenping.timeout: 100s
discovery.zen.minimum master nodes: 2
discovery.zen.ping.unicast,hosts: ["192.168.130.145:9300","192.168.130.146:9300"]

集群构建及主节点选举过程:

1. 节点启动后先执行 ping 命令(这里提及的 ping 命令不是 Liux 环境用的 ping 命令，而是Elasticsearch 的一个 RPC 命令)，如果 discovery.zen,ping.unicast.hosts 有设置，则 ping 设置中的 host;否则尝试ping localhost 的几个端口。
2. ping 命令的返回结果会包含该节点的基本信息及该节点认为的主节点。
3. 在选举开始时，主节点先从各节点认为的 master 中选。选举规则比较简单，即按照 ID的字典序排序，取第一个。
   • 若各节点都没有认为的 master，则从所有节点中选择，规则同上。
   • 需要注意的是，这里有个集群中节点梳理最小值限制条件，即 discovery.zen.minimummaster nodes。
   • 若节点数达不到最小值的限制，则循环上述过程，直到节点数超过最小限制值，才可以开始选举。
4. 最后选举出一个主节点，若只有一个本地节点，则主节点就是它自己。
5. 若当前节点是主节点，则开始等待节点数达到 minimum_master_nodes，再提供服务。若当前节点不是主节点，则尝试加入主节点所在集群。

2.1.3 多播模式

• 在多播模式下，只需在每个节点配置好集群名称、节点名称。
• 互相通信的节点会根据es自定义的服务发现协议，按照多播的方式寻找网络上配置在同样集群内的节点。

2.2 节点类型

重点了解：

• 在es中，每个节点可以有多个角色，节点既可以是候选主节点，也可以是数据节点。
• 节点的角色配置在配置文件 /config/elasticsearch.yml 中设置。在Elasticsearch 中，默认都为 true。

配置参数：

• node.master: true ##是否为候选主节点
• node.data: true ##是否为数据节点

2.2.1 数据节点

节点作用：

• 数据节点，负责数据的存储相关的操作，如对数据进行增、删、改、查和聚合等。

注意事项：

• 数据节点对服务器的配置要求比较高，特别是对 CPU、内存和 IO的需求很大。
• 数据节点梳理通常随着集群的扩大而弹性增加，以便保持 Elasticsearch 服务的高性能和高可用。

2.2.2 候选主节点

节点作用：

• 候选主节点是被选举为主节点的节点，在集群中，只有候选主节点才有选举权和被选举权，其他节点不参与选举工作。
• 一旦候选主节点被选举为主节点，则主节点就要负责创建索引、删除索引、追踪集群中节点的状态，以及跟踪哪些节点是群集的一部分，并决定将哪些分片分配给相关的节点等。

2.3 分片

重点了解：

• 在es中，若要进行分片和副本配置，则需要尽早配置。因为当在一个多分片的索引中写入数据时，需要通过路由来确定具体写入哪一个分片中，所以在创建索引时需要指定分片的数量，分片的数量一旦确定就不能修改。

配置参数：

• 分片的数量和副本数量都可以通过创建索引时的 Settings 来配置，Elasticsearch 默认为一个索引创建 5个主分片，并分别为每个分片创建一个副本。

  index.number of shards: 5   ##创建5个主分片数。
  index.number of replicas: 1   ##创建副本数。
  

注意事项：

• 对文档的新建、索引和删除请求等写操作，必须在主分片上面完成之后才能被复制到相关的副本分片。
• es为了加快写入的速度，就让数据写入过程并发实施，在并发写的过程中出现的数据冲突的问题，是通过乐观锁进行控制，每个文档都有一个version (版本号)，当文档被修改时版本号递增。

分片如何使用的?

• 当写入数据时，es根据文档标识符ID将文档分配到多个分片上。
• 当查询数据时，es会查询所有的分片并汇总结果。对用户而言，这个过程是透明的，用户并不知道数据到底存在哪个分片上。

2.4 路由

为什么会有路由功能？

• 是为了避免在查询时，存在部分分片查询失败的情况，影响查询结果准确性，所以es引入了路由功能。

什么是路由功能？

• 在数据写入时，通过路由将数据写入指定分片。
• 在数据查询时，可以通过相同的路由指明在哪个分片将数据查出来。在默认情况下，索引数据的分片算法如下所示:

  shard_num= hash( routing) % num_primary_shards
  
  #routing字段的取值默认是 id 字段或者是 parent 字段。
  #routing 字段在 Hash 分片之后再与有分片的数量取模，最终得到这条数据应该被分配在哪一个分片上。
  

配置参数为什么要使用Hash？

• 通过 Hash 分片可以保证在每个分片上数据量的均匀分布，避免各个分片的存储负载不均衡。
• 在做数据检索时，es默认会搜索所有分片上的数据，最后在主节点上汇总各个分片数据并进行排序处理后，返回最终的结果数据。

三、数据写入流程

重点了解：

• 数据写入操作是在es内存中执行的，数据会被分配到特定的分片和副本上，但最终数据是需要存储到磁盘上持久化的。运维人员是需要熟悉整个过程的。
• 在es中，数据的存储路径在配置文件 ./config/elasticsearch.yml 中进行设置。

配置参数：

• 数据目录：path.data:/path/to/data
• 日志目录：path.logs:/path/to/logs

注意事项：

• 项目上需要根据数据量提前规划es集群各节点所在的服务器资源，不能直接使用默认值。

3.1 分段存储

重点了解：

• 索引数据在磁盘上的是以分段形式存储。

段的概念：

• “段”是es从 Lucene 中继承的概念。在索引中，索引文件被拆分为多个子文件，其中每个子文件就叫作“段”，每个段都是一个倒排索引的小单元。
• 段具有不变性，一旦索引的数据被写入硬盘，就不能再修改。

引入分段的原因：

1. 因为这会使数据更新时效性很差、且耗费大量资源。想象一个场景。若全部的文档集合只构建在一个倒排索引文件中，同时数据量还在不断增加。当进行修改时，我们需要全量更新当前的倒排索引文件，这个过程就非常耗资源。
2. 可以减少锁的使用，提高并发，大大提高es的读写性能。在Lucene中，分段的存储模式可以避免在读写操作时使用锁，从而大大提升es的读写性能，这有点类似于 CurrentHashMap 中“分段锁”的概念，二者有异曲同工之妙。
3. 当分段被写入磁盘后会生成一个提交点，提交点意味着一个用来记录所有段信息的文件已经生成。
   • 当一个段一旦拥有了提交点，就表示从此该段仅有读的权限，永远失去写权限。
   • 若段在内存中时，分段拥有只写的权限，数据还会不断写入，而不具备读数据的权限意味着这部分数据不能被es用户检索到。

索引文件分段存储且不可修改，新增、更新和删除的处理方式：

• 新增：既然数据是新的，那么只需在当前文档新增一个段即可。
• 删除：由于分段不可修改的特性，那么es不会把文档从旧的段中移除，因而是新增一个.del 文件。
  • .del 文件中会记录这些被删除文档的段信息。
  • 被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前通过.del 文件将其从结果集中移除。
• 更新：由于分段不可修改的特性，那么es无法通过修改旧的段来反映文档的更新。所以，更新操作变成了“先操作，后新增”两个操作的结合。
  • es会将旧的文档从 .del 文件中标记删除，然后将文档的新版本索引到一个新的段中。
  • 在查询数据时，两个版本的文档都会被一个查询匹配到，但被删除的旧版本文档在结果集返回前就会被移除。

段的优缺点：

• 优点：

  1. 不需要锁，可以提升es的读写性能。

• 缺点：

  1. 存储空间占用量大。当删除旧数据时，旧数据不会被马上删除而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这就会导致存储空间的浪费。
  2. 浪费资源。若频繁删除、更新数据，则每次更新都是新增新的数据到新分段，并标记旧的分段中的数据，存储空间的浪费会更多。
  3. 存在局限性，增加检索时负担。在检索数据时，查询得到的结果集中会包含所有的结果集，因此主节点需要排除被标记删除的旧数据，随之带来的是查询的负担。

3.2 延迟写策略

使用延迟写策略的原因

• 在es中，索引写入磁盘的过程是异步的。
• 所以为了提升写的性能，es没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写策略。

延迟写策略执行过程：

1. 当新数据写入时，将其先写入 JVM 的内存中。在内存和磁盘之间是文件系统缓存，文件缓存空间使用的是操作系统的空间。
2. 当达到默认的时间，或内存的数据达到一定量时，会触发一次刷新 (Refresh) 操作。刷新操作将内存中的数据生成到一个新的分段上并缓存到文件缓存系统，稍后再被刷新到磁盘中并生成提交点。

注意事项：

• 由于新数据会持续写入内存，而内存中的数据并不是以段的形式存储，所以不能提供检索功能。
• 只有当数据经由内存刷新到文件缓存系统，并生成新的段后，新的段才能供搜索使用，而不需要等到被刷新到磁盘才可以搜索。

刷新的概念：

• 在es中，写入和打开一个新段的过程叫作刷新，刷新分为手动刷新和自动刷新。
  1. 自动刷新：在默认情况下，每个分片会每秒自动刷新一次。这就是es能做到接近实时搜索的原因，因为文档的变化并不是立即对搜索可见的，但会在一秒之内变为可见。
  2. 手动刷新：这种方式是通过开发人员写代码来实现手动触发刷新的。在创建索引时，在 Settings 中通过配置refresh_interval 值，来调整索引的刷新频率。设置值时需注意后面带上时间单位，否则默认是毫秒。当 refresh_interval=-1 时表示关闭索引的自动刷新。

引用事物日志机制的原因：

• 虽然延迟写策略可以减少数据往磁盘上写的次数，提升es的整体写入能力，但文件缓存系统的引入同时也带来了数据丢失的风险，如机房断电等。所以es引入事务日志 (Translog)机制。事务日志用于记录所有还没有持久化到磁盘的数据。

引用事务日志机制后的数据写入索引流程：

1. 新文档被索引之后，先被写入内存中。为了防止数据丢失，es会追加一份数据到事务日志中。
2. 新的文档持续在被写入内存时，同时也会记录到事务日志中。当然，此时的新数据还不能被检索和查询。
3. 当达到默认的刷新时间或内存中的数据达到一定量后，es会触发一次刷新，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时新段虽未被提交到磁盘，但已经可以对外提供文档的检索功能且不被修改。
4. 随着新文档索引不断被写入，当日志数据大小超过某个值(如 512MB)，或者超过一定时间(如30min)时，es会触发一次 Flush。此时，内存中的数据被写入一个新段，同时被写入文件缓存系统，文件缓存系统中的数据通过 Fsync 刷新到磁盘中，生成提交点。而日志文件被删除，创建一个空的新日志。

3.3 段合并机制

引入段合并机制的原因？

• 资源浪费。在es自动刷新流程中，每秒都会创建一个新的段。这就会导致短时间内段的数量猛增，而当段数量太多时会带来较大的资源消耗，如对文件句柄、内存和 CPU 的消耗。
• 检索效率低。在内容搜索阶段，由于搜索请求要检查到每个段，然后合并查询结果，因此段越多，搜索速度越慢。

概念：

• 段合并机制在后台定期进行，从而小的段被合并到大的段，然后这些大的段再被合并到更大的段。
• 在段合并过程中，es会将旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中，当然，在合并的过程中不会中断索引和搜索。

特性：

1. 段合并是自动进行索引和搜索的。在合并进程中，会选择一小部分大小相似的段，在后台将它们合并到更大的段中，这些段既可以是未提交的，也可以是已提交的。
2. 在合并结束后，老的段会被删除，新的段被 Flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点。打开新的段之后，可以用来搜索。

注意事项：

1. 由于段合并的计算量较大，对磁盘 I/O 的消耗也较大，因此段合并会影响正常的数据写入速率。
2. es在默认情况下会对合并流程进行资源限制，这就是搜索服务仍然有足够的资源仍然可以执行的原因。

四、知识关联

4.1 乐观锁

什么是乐观锁?

1. 乐观锁不仅是一种锁的类型，更是一种设计思想。
2. 在乐观锁的思想中，会认为数据一般不会引发冲突，因此在数据更新时，才会检测是否存在数据冲突。在检测时，如果发现数据冲突，则返回冲突结果,以便读者自主决定如何去做。

什么是悲观锁？

1. 和乐观锁对应的是悲观锁，在悲观锁的思想中，会认为数据一般会引发冲突。换句话说，在读数据时写数据操作往往也正在进行，因此在读数据前需要上锁，没有拿到锁的读者或进程只能等待锁的释放。
2. 常见的行锁、表锁、读锁、写锁等都是悲观锁。

es引入乐观锁机制的原因：

• 为了解决并发写过程中数据冲突问题，乐观锁在多个维度均有应用。
• 当用户对文档进行操作时，并不需要对文档作加锁、解锁操作，只需指定要操作的版本即可。当版本号一致时，es会允许该操作顺利进行；当版本号冲突时，es会提示冲突并抛出异常VersionConflictEngineException。在 es中，文档的版本号的取值范围为1到2的63次方减1。

应用场景：

1. 在数据库中，我们用乐观锁来控制表结构，减少长事务中数据库加锁的开销，达到数据表“读多写少”场景下的高性能。
   • 比如在关系数据库中，如果某张表对应的应用场景是读多写少的场景，则可以使用乐观锁。
   • 采用乐观锁控制数据库表后，表中会新增一列字段，一般称之为 version，version 用于记录行数据的版本。当数据初始写入时，版本默认为 1:每当对数据有修改操作时，version 都会加 1。在修改操作过程中，数据库会对比数据地区的 version 和当前数据库的 version，如果相同，则新数据方可写入。
2. 在Java 中，Java 引入了 CAS (Compare And Swap)乐观锁实现机制实现多线程同步的原子指令，如AtomicInteger。
   • 在Java 中，乐观锁思想的实现就是 CAS 技术，即Compare and Swap。在JDK 1.5 中新增的java.util.concurrent就是建立在 CAS 之上的，开发人员常用的 AtomicInteger 就是其中之一。
   • 在 Java 中，当多个线程尝试使用 CAS 同时更新同一个变量时，只有一个线程能成功更新变量的值，而其他线程都会失败。失败的线程并不会被挂起，而是被告知失败，并可再次尝试。
   • 在具体实现上，CAS 操作包含三个操作数，即内存位置 (V)、预期原值 (A) 和新值(B)如果内存位置的值与预期原值相同，则处理器会自动将该位置值更新为新值;否则，处理器不做任何操作。

4.2 配置文件格式

YAML名称的由来：

• YML文件格式是由 Clark Evans、Ingy dot Net和OrenBen-Kiki在 2001年首次发表的。
• YAML是“YAMLAin’ta Markup Language”(YAML不是一种置标语言)的首字母缩写。在开发这种语言时，YAML 的初衷本是“Yet Another Markup Language”(仍是一种置标语言)。后来为了强调 YAML 语言以数据作为中心，而不是以置标语言为重点，因而采用返璞词来重新命名。

配置文件格式历经过程：

• 配置文件先后经历了ini格式、JSON格式、XML格式、Properties 格式和HOCON格式。
• HOCON(Human-Optimized Config Object Notation)格式由 Lightbend 公司开发，它被用于 Sponge，以及利用 SpongeAPI 的独立插件以储存重要的数据，HOCON 文件通常以.conf 作为后缀名。
  在配置文件的格式变迁中，我们能看到配置的方式都在追求语法简单、能继承、支持注释等特性。

4.3 es对比关系型数据库

• es中的索引 (Index) = mysql中的数据库(DataBase)。
• es中的类型 (Type) = 表 (Table )。一个数据库下面可以有多张表(Table)，一个索引(Index)下面有多种类型 (Type)。
• es中的文档(Document) = 行(ROW)。一个数据库表(Table)下的数据由多行(ROW)组成，一个类型 Type由多个文档(Document)组成。
• es中的字段(Field) = 列(column)。数据库表(Table)中一行数据由多列 (column)组成，一个个文档(Document)由多个字段(Field)组成。
• es中的es中的映射(Mapping) = mysql中的 schema。-在关系数据库中schema 定义了表、表中字段、表和字段之间的关系，而在es中，Mapping 定义了索引下 Type 的字段处理规则，即索引的建立、索引的类型、是否保存原始索引 JSON 文档、是否压缩原始 JSON 文档、是否需要分词处理、如何进行分词处理等。
• es中的增(Put/Post)、删(Delete)、改(Update)、查(GET) = mysql中的增 (Insert)、删(Delete)、改(Update)、查(Select)。

4.4 副本

引入副本技术的原因？

• 提高分布式系统容错率、提高可用性。

概念：

• 副本(Replica 或称 Copy)一般指在分布式系统中为数据或服务提供的冗余。

注意事项：

• 服务副本，一般指的是在不同服务器中部署同一份代码。如 Tomcat/Jetty 集群部署服务，集群中任意一台服务器都是集群中其他服务器的备份或称副本。
• 数据副本，一般指的是在不同的节点上持久化同一份数据。当某节点中存储的数据丢失时，系统就可以从副本中读到数据。数据副本是分布式系统解决数据丢失或异常的唯一手段，因此副本协议也成为贯穿整个分布式系统的理论核心。

4.4.1 副本的数据一致性

通过什么协议来实现的？

• 副本控制协议。让用户通过一定的方式即可读取分布式系统内部各个副本的数据，这些数据在一定的约束条件下是相同的，即副本数据一致性(Consistency)。

一致性的分类：

• 在分布式系统中，一致性分为强一致性 (Strong Consistency)、弱一致性 (WeekConsistency)，还有介于二者之间的会话一致性 (Session Consistency) 和最终一致性(Eventual Consistency )。
  1. 强一致性最难实现。强一致性要求任何时刻用户都可以读到最近一次成功更新的副本数据。
  2. 弱一致性与强一致性正好相反，数据更新后，用户无法在一定时间内读到最新的值，因此在实际中使用很少。
  3. 会话一致性指的是在一次会话内，用户一旦读到某个数据的某个版本的更新数据，则在这个会话中就不会再读到比当前版本更老旧的数据。
  4. 最终一致性指的是集群中各个副本的数据最终能达到完全一致的状态。

注意事项：

1. 副本数据一致性是针对分布式系统中各个节点而言的，不是针对某节点的某个副本而言的。
2. 从副本的角度而言，强一致性是最佳的，但对于分布式系统而言，还要考虑其他方面，如分布式系统的整体性能(即系统的吞吐)、系统的可用性、系统的可拓展性等。这也是系统设计要全盘考虑的原因。

4.4.2 副本数据的分布方式

数据分布方式：

• 主要有哈希方式、按数据范围分布、按数据量分布、一致性哈希方式(Consistent Hashing)，等等。
  1. 哈希方式。最简单的方式，简单是最大优势，但缺点也同样明显。一方面，可扩展性不高，一旦存储规模需要扩大，则所有数据都需要重新按哈希值分发；另一方面，哈希方式容易导致存储空间的数据分布不均匀。
  2. 按数据范围分布。该种方式也较常见，是将数据按特征值的范围划分为不同的区间，使得集群中不同的服务器处理不同区间的数据。这种方式可以避免哈希值带来的存储空间数据分布不均匀的情况。
  3. 按数据量分布、按数据范围分布。两种方式的设计核心思路较接近。一般是将数据看作一个顺序增长的，并将数据集按照某一较为固定的大小划分为若干数据块，把不同的数据块分布到不同的服务器上。
  4. 一致性哈希方式。在实践中使用较为广泛的一种，基本思路是使用一个哈希函数计算数据的哈希值，而哈希函数的输出值会作为一个封闭的环，我们会根据哈希值将节点随机分布到这个环上，每个节点负责处理从自己开始顺时针至下一个节点的全部哈希值域上的数据。

2种数据分布形态：

• 一种以服务器为核心，另一种是以数据为核心。
  1. 以机器为核心时，机器之间互为副本，副本机器之间的数据完全相同。以机器为核心的策略适用于上述各种数据分布方式，最主要的优点就是简单，容易落地；缺点也很明显，一旦数据出问题，在数据恢复时就需要恢复多台服务器中的数据，效率很低，而且增加服务器后，会带来可扩展性低的问题。一般会采用哈希方式、一致性哈希方式。
  2. 以数据为核心时，一般将数据拆分为若干个数据段，以数据段为单位去分发，每个数据段的大小尽量相等，而且限制数据量大小的上限。在不同的系统中，数据段有很多不同的称谓，如在 Lucene 和es中称之为 segment，在 Kafka 中称之为 chunk 和partition等。

注意事项：

• 将数据拆分为数据段，意味着副本的管理将以数据段为单位进行展开，因此副本与机器不再强相关，每台机器都可以负责一定数据段的副本。这带来的好处是当某台服务器中的数据有问题时，我们可以从集群中的任何其他服务器恢复数据，因此数据的恢复效率很高。

4.4.3 副本分发策略

概念：

• 指主节点和副本节点之间副本数据同步的方法。

2大类分发策略：

1. 中心化方式：
   • 设计思路：由一个中心节点协调副本数据的更新、维护副本之间的一致性。数据的更新可以是主节点主动向副本节点推送，也可以是副本节点向主节点推送。
   • 优缺点：设计思路简单，缺点明显，数据的同步及系统的可用性都有“单点依赖”的风险，即依赖于中心化节点。一旦中心化节点发生异常，则数据同步和系统的可用性都会受到影响。
2. 去中心化方式：
   • 设计思路：就是没有中心节点，所有的节点都是 P2P 形式，地位对等，节点之间通过平等协商达到一致。
   • 优缺点：不会因为某个节点的异常而导致系统的可用性受到影响。但各个节点达成共识的过程较长，需要反复进行消息通信来确认内容，实现较为复杂。