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