剖析ElasticSearch核心概念，NRT，索引，分片，副本等

ElasticSearch 的核心概念

Near RealTime(NRT) 近实时

近实时有两种意思，一种是从写入数据到能够被搜索到有一个小延迟（大概一秒），还有一种就是基于ElasticSearch 进行搜索和分析能够达到秒级, 下图来讲明一下近实时的效果。

1. 首先咱们先使用Java向ElasticSearch存入一条数据，时间是 2点16分20秒
   
2. 在使用一个Java程序从ElasticSearch里面来读取数据，那么在读取数据的时候这个时间的偏差应该保持在秒级，不管是这个集群体系有多大，都应该保持这种速度，好比下面这个例子就是将时间延迟控制在了一秒。
   
3. 这里须要提到一下：实时又分为准实时和近实时，准实时是毫秒级，近实时是秒级

Cluster 集群

集群里面包含多个节点，每一个属于那个集群都是经过一个配置（集群名称，默认是elasticSearch）来决定的，对于中小型企业来讲，刚开始一个集群就一个节点很正常。

Node 节点

集群里面的一个节点，节点也有一个名称，默认是随机分配的，节点名称很重要(在运维管理操做的时候)，每一个节点默认会去加入一个名叫 elasticsearch 的集群, 若是直接启动一堆节点，那么他们会自动组成一个名为 elasticsearch 的集群, 固然一个节点也能够组成一个 elasticsearch 集群，只不过状态是yellow(警告)，正常的状态应该是green(正常)，这个在后面会详细说明为何会有yellow和green之分。

Document 文档

es中最小的数据单元，它能够是一条简单的客户数据，一条商品分类数据，一条订单数据，一般用json结构表示，每一个index下的type中，均可以存储多个document。下面就举例一个简单的商品document。

product document
{
    "product_name":"田园布艺沙发",
    "product_id":"1",
    "category_name": "沙发",
    "category_id": "2"
}

Type 类型

一个type里面能够有不少个document，就至关于一个表里面有条记录是一个意思，在ElasticSearch6.0版本以前一个索引是能够有多个type的，可是在6.0以后就只能有一个type了。在7.0事后将会彻底抛弃type，为何type会慢慢的被ElasticSearch移除呢？咱们都把type比喻成一张表，把index比喻成数据库，可是在数据库里面的表都是相互独立的，各个字段之间互不影响，可是在ElasticSerarch中，多个type里面若是有相同字段，那么多个type就会同用同一个字段，也就是说他们并不会区分开来，因此后期就慢慢的将type潜移默化了。下面的例子将会展现document在type里面是怎么存储的（这里type和document的数据关系，并非表明es里面数据结构就是这样，这里只是演示，了解就行）。

{
"type":[
    {
        "product_name":"田园布艺沙发",
        "product_id":"1",
        "category_name":"布艺沙发",
        "category_id":"2"
    },
    {
        "product_name":"田园实木沙发",
        "product_id":"2",
        "category_name":"实木沙发",
        "category_id":"3"
    }
]
}

index 索引

在6.0版本以前index里面能够存多个type，可是在6.0以后就只能存一个type了，这个type里面又有不少的document。就像是下面这样（这里只是体现一个index和type还有document的数据关系，并非表明es里面数据结构就是这样，这里只是演示，了解就行）

{
"index":{
    "type":[
        {
            "product_name":"田园布艺沙发",
            "product_id":"1",
            "category_name":"布艺沙发",
            "category_id":"2"
        },
        {
            "product_name":"田园实木沙发",
            "product_id":"2",
            "category_name":"实木沙发",
            "category_id":"3"
        }
    ]
}
}

shards 分片

ElasticSearch 中特别重要的一个，先简单介绍一下什么是shards，它是一个数据的分片，这里先大概说明一下，下面就来详细解释一下这个shards为何重要了。

1. 如今咱们有这么一个需求，要求将3T数据存储在ES集群中，可是咱们的每一个节点最大容量只有1T，这时候单台服务器就容不下咱们的数据。
   
2. 这个时候咱们就须要将这个3T的数据拆分红3份存在3个节点上面（不要说这里有6台服务器，为何不每台服务器存500G呢，我不接受抬杠😄，开玩笑的啦，后面会解释这剩余3台服务器的用处），那么就能存下此次的数据了。这个时候就引出了shards的概念了，简单来讲就是index会被拆分为多个shard（具体被拆分为几个shard是能够配置的，后面再说），每一个shard存放了这个index的部分数据，而后这些shard会散落在多台服务器上面。
   
3. shard的好处，第一点，横向扩展，好比说咱们数据量增长到了4T的时候，只须要增长一个节点，而后创建一个有4个shard的索引，在将以前的有3个shard的索引的数据倒过来就好了（倒数据很简单，后面会介绍）。
   
4. shard的第二点好处就是，数据分布在多个shard上，多台服务器上面全部的操做都会分布在多台服务器上面并行分布式执行，提神吞吐量和性能，好比说若是只有一个节点，那么全部的请求过来了事后，全部的压力都只有一台服务器来承担。举例，若是如今单台服务器承受的压力只有2000，那么4台服务器就能够承受8000的访问量了。

replica 分片副本

它的做用就是shard的备份，直接上例子，好比咱们的节点7宕机了，那么这个节点上面的数据就丢失了没法获取该节点上面的数据，这个时候估计大家也猜到，replica的用处了，它就是shard的备份，若是某个主节点宕机了，那么就会到节点的备份分片replica上面去查询数据（replica的做用不只仅只有备份，还能够提升吞吐量等等），一个replica存储的数据和shard上是同样的。

这个时候就能够解释为何只有单台服务器时集群状态的yellow的了，由于ElasticSearch不容许同一个索引额shard和replace出如今同一台机器上面，由于这样若是这台机器宕机了，那么就没法获取数据了，全部会爆出警告，最低(不发生警告)的集群配置是2台服务器，一台存全部的shard，另外一台出全部的replace，这就是replace的最重要的做用了。