1、Elasticsearch的數據組織架構
1.1、Elasticsearch結構概念
- 集群（cluster）：擁有相同cluster-name的elasticsearch結點的集合（每個結點其實就是一個elasticsearch進程實例）。
- 節點（node）：集群中的一個 Elasticearch 實例。
- 索引（index）：相當於關系型數據庫中database的概念，比如2018.01.01日志的IDS日志單獨形成一個索引，IDS-2018.01.01，這是一個邏輯的概念。
- 分片（shared）：
- 主分片（primary shared）：索引的子集，索引可以切分成多個分片，分布到不同的集群節點上。
- 副本（replica shared）：一個主分片可以有一個或多個副本分片作為備份。
- 類型（type），相當於關系型數據庫中table的概念。比如IDS-2018.01.01中的warnning.log
- 文檔（document），相當於一條數據的原始數據的集合，一般就是一條JSON。
- 字段（field），JSON中的某個字段值。
從索引到后面都是組織數據的結構概念，分片（無論主副）可以自由分布在集群中的不同結點上，也不關系結點的主副概念（master-cluster和slave-cluster）。
1.2、創建索引時，如何分配主從分片等的配置
一般使用elasticsearch-head創建分片時，默認分片數5、副本數1（意思是每個分片一個副本），分片數創建后不可修改，副本數可修改，數量按需要配置。注意：一個shared的主分片和副本不能放在同一個結點上，否則結點故障的容錯機制（數據冗余備份）將失去效果。
1.3、分片的路由計算
公式如下：
shared = hash(_id) %number_of_primary_shareds
一般情況下是對_id字段進行hash處理后對主分片數目求余得到該條數據具體應該寫入那個分片。
1.4、主副分片保障數據一致性
默認情況下，數據寫入主分片后，會給所有副本發送方消息，當有一個副本也成功寫入數據后，及返回數據寫入成功。如需要修改可以如下修改配置
?consistency=all
1.5、分片的分配
一般是Elasticsearch自動進行，一些參數可以控制該過程的
cluster.routing.allocation.enable #可以分配那些分片，默認是all，none是徹底拒絕，其他選項有primaries和new_primaries。
cluster.routing.allocation.allow_rebalance #默認是indices_all_active，就是等待所有分片啟動后，開始負載均衡，不然啟動過程中浪費太多流量。
cluster.routing.allocation.cluster_concurrent_rebalance #默認是兩個，含義是並發負載均衡任務數量，當結點數目增加，且負載壓力不大的條件下，可適當增加。
cluster.routing.allocation.node_initial_primaries_recoveries #結點重啟時，允許同時恢復的主分片數，默認是4個，如果結點是多磁盤，且I/O壓力不大時，可以適當增加。
cluster.routing.allocation.node_concurrent_recoveries #除主分片重啟恢復意外的情況下，可以同時運行的數據恢復業務，默認是2個。
indices.recovery.concurrent_stream #網絡復制恢復分片時候的流數，默認是3個。
indices.recovery.max_bytes_per_sec #結點恢復時候的速率，默認40MB，建議加大。
1.6、自動發現配置
- 組播方式 223.2.2.4 54328 發送clustername信息
- 單播方式
1.7、其他配置項
?timeout=30s #默認60s，含義是Elasticsearch等待異常結點是否可以恢復的等待時間。
2、Elasticsearch的數據寫入和檢索以及數據防丟失機制
2.1、數據寫入流程
內存buffer->segment->磁盤
segment可以理解為一個倒排索引的子集，舉例如下：
doc1:"tom","jill"
doc2:"tom"
倒排索引如下表
| 字段/文檔 | doc1 | doc2 |
|---|---|---|
| tom | x | x |
| jill | x |
2.2、segment的機制
- 寫盤機制：一個segment刷到緩存中，Lucene可以去檢索，等到segment真的寫到磁盤去了，commit文件更新，commit可以理解為segment的目錄表，刷新（refresh）時間默認是1s，基本屬於准實時檢索。
- 歸並機制：segment太多，不利於系統和性能，會歸並。
2.3、寫盤和歸並的配置
#修改refresh時間 ，設置成-1，則停止refresh
curl -XPOST http://127.0.0.1:9200/IDS-2018.01.01/_settings -d '{"refreah_interval":"10s"}'
#修改歸並配置
curl -XPOST http://127.0.0.1:9200/IDS-2018.01.01/_settings -d '{"persistent":{"key-name":"value"}}'
#歸並配置選項
indices.store.throttle.max_bytes_per_sec #歸並線程限速配置，默認20M，建議遷移到100M或更高。
index.merge.policy.floor_segment #默認2M，小於這個大小的segment，優先歸並。
index.merge.policy.max_merge_at_once #默認一次最多歸並10個segment。
index.merge.policy.max_merge_at_once_explicit #默認optimize時候，一次最多歸並20個segment。
index.merge.policy.max_merge_segment #默認5GB。歸並后的segment的大最大大小。
2.4、translog磁盤同步
磁盤寫入等待緩存一起寫，記錄數據信息，如果出現異常，會按照這個文件恢復數據，但是這個數據5s寫一次，所以還是有可能丟失5s的數據。如果需要，可以調小這個時間間隔：
index.gateway.local.sync
默認30分鍾、或者滿512M才會清空。（或者確實寫入磁盤，commit文件確認了，translog才會清空flush，）