一些elasticsearch重要概念與配置參數

ES 是在 lucene 的基礎上進行研發的，隱藏了 lucene 的復雜性，提供簡單易用的 RESTful Api接口。ES 的分片相當于 lucene 的索引。

Node 節點的幾種部署實例
實例一: 只用于數據存儲和數據查詢，降低其資源消耗率

node.master: false
node.data: true

實例二: 來協調各種創建索引請求或者查詢請求，但不存儲任何索引數據

node.master: true
node.data: false

實例三: 主要用于查詢負載均衡，并請求分發到多個指定的node服務器，并對各個node服務器返回的結果進行一個匯總處理，最終返回給客戶端

node.master: false
node.data: false

實例四: 即有成為主節點的資格，又存儲數據

node.master: true
node.data: true

在只有3個節點的部署方案中，建議設置3個節點均有成為master節點的資格，且存儲索引數據。

數據目錄配置與物理磁盤的使用
一般來說，是這樣配置：

path:logs: /var/log/elasticsearchdata: /var/data/elasticsearch

數據目錄可以支持使用多個：

path:data:- /mnt/elasticsearch_1- /mnt/elasticsearch_2- /mnt/elasticsearch_3

物理磁盤的使用：

雖然es已經提供了數據副本的冗余，但實際生產中還是建議使用raid1，raid5和raid10
集群名稱配置

cluster.name: logging-prod

node節點名稱
默認為使用主機名，也可以在elasticsearch.yml中指定。在一個主機上同時跑多個es實例時，這個配置項就會很有幫助。

node.name: prod-data-2

網絡地址配置
默認將服務綁定到loopback接口，這需要按實際情況調整。

network.host: 0.0.0.0

注：變更服務綁定接口后，會被認為是作為生產環境使用，會觸發es的環境檢查操作。當有不符要求的系統或集群配置參數時，es服務會無法啟動。

節點發現和cluster初始化參數
單播主機列表通過discovery.zen.ping.unicast.hosts來配置。
這個配置在 elasticsearch.yml 文件中：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]

具體的值是一個主機數組或逗號分隔的字符串。每個值應采用host：port或host的形式（其中port默認為設置transport.profiles.default.port，如果未設置則返回transport.tcp.port）。請注意，必須將IPv6主機置于括號內。此設置的默認值為127.0.0.1，[:: 1]。

使用單播，你可以為 Elasticsearch 提供一些它應該去嘗試連接的節點列表。當一個節點聯系到單播列表中的成員時，它就會得到整個集群所有節點的狀態，然后它會聯系 master 節點，并加入集群。

discovery.seed_hosts:- 192.168.1.10:9300- 192.168.1.11- seeds.mydomain.com
cluster.initial_master_nodes:- master-node-a- master-node-b- master-node-c

提供了seed.hosts參數的三種賦值方式

initial_master_nodes參數只能使用節點的node.name參數值，一般來說是主機名
Zen Discovery 是 ES 默認內建發現機制。它提供單播和多播的發現方式，并且可以擴展為通過插件支持云環境和其他形式的發現。
Elasticsearch 官方推薦我們使用單播代替組播。而且 Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。
設置JVM heap size
通過jvm.options文件設置jvm緩存參數，過大或過小都不好，過大的緩存也會讓垃圾回收變慢。

當jvm緩存設置大于26GB時，需要評估zero-based compressed oops限制，參見下面的說明：
https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

由于ES構建基于lucene, 而lucene設計強大之處在于lucene能夠很好的利用操作系統內存來緩存索引數據，以提供快速的查詢性能。lucene的索引文件segements是存儲在單文件中的，并且不可變，對于OS來說，能夠很友好地將索引文件保持在cache中，以便快速訪問；因此，我們很有必要將一半的物理內存留給lucene ; 另一半的物理內存留給ES（JVM heap )。所以，在ES內存設置方面，可以遵循以下原則：

當機器內存小于64G時，遵循通用的原則，50%給ES，50%留給lucene。
當機器內存大于64G時，遵循以下原則：
a. 如果主要的使用場景是全文檢索, 那么建議給ES Heap分配 4~32G的內存即可；其它內存留給操作系統, 供lucene使用（segments cache), 以提供更快的查詢性能。
b. 如果主要的使用場景是聚合或排序，并且大多數是numerics, dates, geo_points 以及not_analyzed的字符類型，建議分配給ES Heap分配 4~32G的內存即可，其它內存留給操作系統，供lucene使用(doc values cache)，提供快速的基于文檔的聚類、排序性能。
c. 如果使用場景是聚合或排序，并且都是基于analyzed 字符數據，這時需要更多的 heap size, 建議機器上運行多ES實例，每個實例保持不超過50%的ES heap設置(但不超過32G，堆內存設置32G以下時，JVM使用對象指標壓縮技巧節省空間)，50%以上留給lucene。
禁止swap，一旦允許內存與磁盤的交換，會引起致命的性能問題。通過：在elasticsearch.yml 中 bootstrap.memory_lock: true，以保持JVM鎖定內存，保證ES的性能。操作系統通過交換（swap）將內存的分頁寫入磁盤，es在內存中保留了很多運行時必需的數據和緩存，所以消耗磁盤的操作將嚴重影響正在運行的集群。
關閉es交換最徹底的方法是，在elasticsearch.yml文件中將bootstrap.mlockall設置為true 。
GC設置原則：

?保持GC的現有設置，默認設置為：Concurrent-Mark and Sweep (CMS)，別換成G1GC，因為目前G1還有很多BUG。
?保持線程池的現有設置，目前ES的線程池較1.X有了較多優化設置，保持現狀即可；默認線程池大小等于CPU核心數。如果一定要改，按公式（（CPU核心數* 3）/ 2）+ 1 設置；不能超過CPU核心數的2倍；但是不建議修改默認配置，否則會對CPU造成硬傷。

Temp directory配置
在使用.tar.gz方式部署es服務時，建議指定一個安全的臨時文件目錄，避免因為默認使用的/tmp下的臨時目錄被操作系統定期刪除，造成服務故障。
通過環境變量 $ES_TMPDIR 來設置。

分片分配的感知
分配感知（allocation awareness）是管理在哪里放置數據的副本。
https://www.elastic.co/guide/en/elasticsearch/reference/7.2/allocation-awareness.html

1. 基于分片的分配
分配感知允許用戶使用自定義的參數來配置分片的分配。通過定義一組鍵，然后在合適的節點上設置這個鍵，就可以開啟分配感知。
elasticsearch.yml

cluster.routing.allocation.awareness.attributes: rack_id

注：支持賦多個值同時用作感知屬性，如cluster.routing.allocation.awareness.attributes: rack, group, zone

針對每個es節點，用戶可以修改elasticsearch.yml，按期待的網絡配置來設置該值。ES允許用戶在節點上設置元數據，這些元數據的鍵將成為我們要使用的分配感知參數。

node.attr.rack_id: rack_one

當有多個es節點可用時，es會盡量把分片與副本均衡到rack_id值不同的節點上去。但如果只剩一個可用的es數據節點了，es也會選擇把一個索引的分片和副本全部部署在同一個節點上面。

常見的使用場景是按照地點、機架或是虛擬機等來劃分集群的拓撲。

2. 強制性的分配感知
在用戶事先規則好分片分組信息，且希望限制每個分組的副本分片數量時，強制分配感知是適用的解決方法。
在這種情況下，即便因為部分分組的數據節點不可用，導致es服務可用性風險，es也不會把索引的分片與副本都部署在相同的分組節點上面。

例如，用戶想在區域級別使用強制分配。可以先指定一個zone的屬性，然后為該分組添加多個維度。如下所示：

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.force.zone.values: us-east, us-west

此時，我們在東部地區啟用了一批節點，這些節點的配置都是node.attr.zone: us-east ，在創建索引時由于以上限制，副本分片只會被均衡到沒有相應zone值的節點上去。

3. 動態設置分片感知
可以通過集群設置API在運行時進行修改，這個修改的效果可以自行選擇是持久的，還是臨時性的。

curl -XPUT localhost:9200/_cluster/settings -d '{"persistent": {"cluster.routing.allocation.awareness.attributes": zone"cluster.routing.allocation.force.zone.values": us-east, us-west}
}'

分片

分片數量

ES7.0版本開始，新建索引時，默認只有一個主分片。優點在于：單個分片，查詢算分和聚合不準的問題都可以得到避免；缺點在于：即便增加新的節點，也無法實現水平擴展。
如果有兩個主分片，當集群增加節點后，es會自動進行分片移動（Shard Rebalancing），將本分布在一個節點的兩個分片平衡為兩個節點，每個節點一個分片。
當分片數>節點數時：一旦集群中有新的數據節點加入，分片就可以自動分配；分片在重新分配時，系統也可以正常工作。
多分片的好處：一個索引如果分布在多個節點，查詢可以并行，寫入可以分散到多個機器。
例1：每天1GB，一個索引，一個主分片，一個副本分片。保留半年，共180*2 = 360G數據 = 360個分片。
例2：五個不同日志，每天一個日志索引，每個日志索引有10個主分片，保留半年，共180*5*10 = 9000個分片。
分片是es實現集群水平擴展的最小單位。
當分片過多時，會導致額外的性能開銷：
每次搜索，需要從每個分片獲取數據。
分片的Meta信息會變多，增加主節點的負擔。

分片建議

日志類應用，單分片不超50GB。
搜索類應用，單分片不超20GB。
為什么要控制：
- 提高更新時的性能。
- 分片合并時，減少所需資源。
- 節點丟失后，具備更快恢復速度（分片小便于在集群內移動）

副本建議

副本是主分片的拷貝，目的是提高系統可用性：可以執行查詢，并且避免數據丟失；副本分片需要占用和主分片一樣的資源。
副本分片會降低數據的索引（寫入）速度：有幾份副本就會有幾倍的CPU資源消耗。
可以減緩對主分片的查詢壓力，但是會消耗同樣的內存資源；如果機器資源充分，提高副本數可以提高整體的查詢QPS。

相關設置

Es分片策略會盡量保證節點上的分片數大致相同。可能會產生問題：擴容時，原有節點磁盤基本寫滿了，新索引會集中在新加的節點上，導致數據分布不均勻。
index.routing.allocation.total_shards_per_node設置為1，可以限制一個索引在單個節點上只能有一個分片（主分片或者副本）