ES索引，分片，一致性

1，ES的索引和分片

（1）索引（index）：

       概念：至关于数据库，用于定义文档类型的存储，在同一个索引中，同一个字段只能定义一个数据类型。每一个索引均可以有一个或者多个主索引片，同时每一个索引还能够有零个或者多个副本索引片。

       建立索引：curl -XPUT http://localhost:9200/index  （localhost能够换为本身的主机IP，index是想要建立的索引的名字）           

（2）分片（shard）：

          概念：ElasticSearch集群经过把数据分发到多个存储Lucene索引的物理机上，达到可以存储超出单机容量的信息这一目的。这个分发的过程称为索引分片(Sharding)。在ElasticSearch集群中，索引分片(Sharding)是自动完成的，并且全部分片索引(Shard)是做为一个总体呈现给用户的。总体呈现能够这样理解：当你查询的索引分布在多个分片上时， Elasticsearch会把查询发送给每一个相关的分片，并将结果合并在一块儿，而应用程序并不知道分片的存在

         默认值：分片默认为5个主分片，1个分片副本，一旦建立好索引，定义的主分片数量就不能更爱

        经过集群状态API获取当前的分片和副本的设置：

 curl -XGET 'http://localhost:9200/_cluster/index?human&pretty'

        建立索引，定义分片数量：

 PUT /my_index

    {

         "settings" : {

          "number_of_shards" : 3,

          "number_of_replicas" : 1

       }

}

     查看每一个分片的状况：

GET /_cluster/health?level=indices

 

2，ES分片的一致性

       概念：简单说就是主分片写完，同步到副本分片上，等全部的分片写完才分会成功

       理解：

高可用方面：

 

ElastcSearch拥有许多高可用的特性，例如Replica，例如Data Node挂掉后的数据迁移，例如Master Node挂掉后的自动重选，但这不表明万无一失了。常见的坑是，某个Node表现糟糕可是恰恰又没挂（挂了反而更好），此时整个Cluster的性能就会被一个坑爹Node拖累，这每每就是雪崩的开始。所以，从高可用方面来考虑，应当部署多个ES Cluster（部分做为灾备）。

 

性能方面：

 

单个Cluster的搜索能力是有瓶颈的。Cluster越大，Node越多，天然Shard就越多。而Shard不是越多越好，Shard增多会致使通信成本的增长、查询收束时Re-ranking环节的负担增长。若是有100台机器，那么比起一个100 Node、300 Shards的巨型Cluster，使用十个10 Node 30 Shards的小型Cluster可能表现会更好。

     

   如何确保多个ES Cluster的更新操做的一致性：

       加入一层能够被多人重复消费的消息队列（例如Kafka），做为全部ES Cluster插入/更新的中间层。

       优势：

          1）主更新程序只有一个，提升可控性和发现问题的能力；

 

2）使用消息队列来统一发布内容，下降了对数据源的压力；

 

3）图中消费者这个角色，Elastic Stack官方提供了一个轻量级高可用解决方案，就是Beat