一、Elasticsearch的數據組織架構
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中的某個字段值。 <strong>從索引到後面都是組織數據的結構概念，分片（不管主副）能夠自由分佈在集羣中的不一樣結點上，也不關係結點的主副概念（master-cluster和slave-cluster）。</strong>
1.二、建立索引時，如何分配主從分片等的配置
<strong>通常使用elasticsearch-head建立分片時，默認分片數五、副本數1（意思是每一個分片一個副本），分片數建立後不可修改，副本數可修改，數量按須要配置。注意：一個shared的主分片和副本不能放在同一個結點上，不然結點故障的容錯機制（數據冗餘備份）將失去效果。</strong> 
node
1.三、分片的路由計算
<strong>公式以下：</strong>數據庫
shared = hash(_id) %number_of_primary_shareds
通常狀況下是對_id字段進行hash處理後對主分片數目求餘獲得該條數據具體應該寫入那個分片。緩存
1.四、主副分片保障數據一致性
<strong>默認狀況下，數據寫入主分片後，會給全部副本發送方消息，當有一個副本也成功寫入數據後，及返回數據寫入成功。如須要修改能夠以下修改配置</strong>網絡
?consistency=all
1.五、分片的分配
通常是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.六、自動發現配置
- 組播方式 223.2.2.4 54328 發送clustername信息
- 單播方式
1.七、其餘配置項
?timeout=30s #默認60s，含義是Elasticsearch等待異常結點是否能夠恢復的等待時間。
二、Elasticsearch的數據寫入和檢索以及數據防丟失機制
2.一、數據寫入流程
<strong> 內存buffer->segment->磁盤 </strong> segment能夠理解爲一個倒排索引的子集，舉例以下：併發
doc1:"tom","jill" doc2:"tom"
倒排索引以下表負載均衡
| 字段/文檔 | doc1 | doc2 |
|---|---|---|
| tom | x | x |
| jill | x |
2.二、segment的機制
- 寫盤機制：一個segment刷到緩存中，Lucene能夠去檢索，等到segment真的寫到磁盤去了，commit文件更新，commit能夠理解爲segment的目錄表，刷新（refresh）時間默認是1s，基本屬於準實時檢索。
- 歸併機制：segment太多，不利於系統和性能，會歸併。
2.三、寫盤和歸併的配置
#修改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.四、translog磁盤同步
磁盤寫入等待緩存一塊兒寫，記錄數據信息，若是出現異常，會按照這個文件恢復數據，可是這個數據5s寫一次，因此仍是有可能丟失5s的數據。若是須要，能夠調小這個時間間隔：curl
index.gateway.local.sync
默認30分鐘、或者滿512M纔會清空。（或者確實寫入磁盤，commit文件確認了，translog纔會清空flush，）elasticsearch