前言
上一篇文章我们认识了ElasticSearch，并对ElasticSearch进行了安装以及Kibana可视化工具的安装，本篇文章我们来学习ElasticSearch的索引结构-倒排索引文档以及ES的核心概念。
ElasticSearch倒排索引文档
对于ElasticSearch而言它就支持对结构化和非结构化的数据进行检索，我对它的理解就是：把采集的数据(一般是从数据库中的数据如商品数据)转化为一种有结构的数据进行搜索，从而提高搜索效率，通常而言有结构的数据查询是比较快的。而这种结构在ES中被叫做 - 倒排索引文档,
把数据转换为倒排索引文档的整个过程叫索引创建这个过程我用一个简图来描述
原始数据经过：分词 ，词态转换，大小写转换，单词合并等流程最终形成一个倒排索引文档。
- 1.分词需要使用到分词器，对于中文的内容更要使用中文分词器，比如:IK分词器
- 2.为了方便搜索，忽略大小写敏感所以进行了词态和大小写转换
- 3.单词进行排序，有序的数据可以提高查询速度，比如二分查找
- 4.相同单词进行合并后单词只需要进行一次搜索即可。
ElasticSearch基于Lucene进行封装的，对于ElasticSearch来说他的数据是进行分片存储的，而一个分片就是一个Lucene的索引库，而Lucene的索引库分为索引区和数据区两部分。结构如下
了解过Mysql的索引结构的同学应该能理解这个图，即：这种索引表中的每一项都包括一个单词值和具有该值的各行数据的地址。当我们搜索一个Java ，ElasticSearch会带着Java在倒排索引中快速定位到Java栏目（单词有序可以二分查找），然后根据关联的地址直接或到数据区中的数据返回。
ES的核心概念
想要操作ES必须了解一个重要的概念，有关系型数据库基础的同学对这几个概念理解起来是比较轻松的。
- Index：索引库
index被叫做索引库，类似于Mysql的数据库database ; 一个index中包含一堆有相似结构的文档数据(Document)，比如说建立一个Goods index 商品索引，里面可能就存放了所有的商品数据，通常一个商品数据(一行数据)在ES中被描述为一个document。
- Type：类型
每个索引里都可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，就好比一个表中的多行数据拥有相同的列 。在ES 7.x以上的版本中取消了这个逻辑分类。
- Document&field
document是一个文档数据，也是ES中的最小数据单元，一个document 可以是一条商品数据，一个订单数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个document。一个document里面有多个field，每个field就是一个数据字段。
为了方便理解下面把ES和Mysql进行了一个对比
| ElastciSearch全文搜索 | Mysql关系型数据库 |
| ------------------------- | --------------------- |
| 索引库(index) | 数据库(database) |
| 文档类型(Type) | 数据表(Table) |
| 文档(Document) | 一行数据(Row) |
| 字段(field) | 一个列(column) |
| 文档ID | 主键ID |
| 查询(Query DSL) | 查询(SQL) |
| GET http://.. | SELECT * FROM ... |
| PUT http:// | UPDATE table set... |
ES集群理解
- Cluster集群
一个ES集群(Cluster)包含多个ES节点注册，每个节点属于哪个集群是通过一个集群名称（集群名称，默认是elasticsearch）来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常。
- Node节点
集群中的一个节点也就是一个ES，节点也有一个名称（默认是随机分配的），节点名称很重要（在执行运维管理操作的时候），默认节点会去加入一个名称为"elasticsearch"的集群，如果直接启动一堆节点，那么它们会自动组成一个elasticsearch集群，当然一个节点也可以组成一个elasticsearch集群
- shard（分片）
单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index。
- replica(备分片)
任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器。
集群的健康状况
green ：所有的primary shard和replica shard 都是active活动状态 - 集群健康
yellow ：所有的primary shard处于active活动状态，有部分的replica shard不处于active状态 - 集群能用
red ： 至少有一个primary shard不处于active活动状态就会出现red - 集群不健康
ES节点类型
默认情况下，elasticsearch集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务。在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。这些功能是由两个属性控制的。node.master 和 node.data 默认情况下这两个属性的值都是true。
| 配置 | 值 | 解释 |
|---|---|---|
| node.master | true | 是否是主节点 |
| node.data | true | 是否存储数据 |
主节点master
node.master=true,代表该节点有成为主资格，主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。一般会把主节点和数据节点分开，node.master=true , node.data=false
数据节点data
node.data=true,数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等,数据节点对CPU,IO,内存要求较高，优化节点的时候需要做状态监控，资源不够时要做节点扩充。配置：mode.master=false,mode.data=true
负载均衡节点client
当主节点和数据节点配置都设置为false的时候，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。配置：mode.master=false,mode.data=false
最佳实践
在一个生产集群中我们可以对这些节点的职责进行划分，建议集群中设置3台以上的节点作为master节点，这些节点只负责成为主节点，维护整个集群的状态。再根据数据量设置一批data节点，这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大，所以在集群中建议再设置一批client节点(node.master: false node.data: false)，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。
Shard&Replica机制
index包含多个shard，一个shard是最小工作单元，存储部分数据，完整的建立索引和处理索引的能力
primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是可以和其他primary shard的replica shard放在同一个节点上
增减节点时，shard会自动在nodes中负载均衡
primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard,当文档被添加的时候，会根据routing_id(默认是document的id)进行"hash(routing_id) % shardNumber" 运算确定文档存储的Shard。
replica shard是primary shard的副本，负责容错，以及承担读请求负载 - 读写分离
primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard
单node环境下创建index
单node环境下，创建一个index，有3个primary shard，3个replica shard
这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是无法分配的,集群status是yellow集群可以正常工作，但是一旦出现节点宕机，数据全部丢失，而且集群不可用，无法承接任何请求
两个node环境下创建index
2个node环境下，创建一个index, 3个primary shard，3个replica shard
扩容极限，提升容错
如何让性能达到更优?
- 每个Node更少的Shard,每个Shard资源跟充沛,性能更高
- 扩容极限：6个shard（3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好
- 超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
容错机制-Master选举
master node宕机，自动进行master选举， - Red
当某个PrimaryShard (主分片)宕机,这个PrimaryShard的某个ReplicShard(备分片)会通过选举成为PrimaryShard。
Replica容错：将replica提升为新的primary shard，- yellow
新的主分片选举成功后,那么保证了主分片的完整性，但是少了一个备分片,所以状态变成了黄色
重启宕机节点：会生成新的ReplicShard,如果宕机前有数据，会像恢复之前的数据，然后从PrimaryShard中拷贝新的数据，这样做的好处是：1.恢复性能好 ， 2.可以避免数据同步延迟造成的数据丢失问题(在宕机的一瞬间,有些数据还没同步到ReplicShard,可能会导致数据丢失)
