1. ElasticSearch的幾個基本概念
<1. Index
類似於mysql數據庫中的database
<2. Type
類似於mysql數據庫中的table表，es中可以在Index（database）中建立多個type（table），其中每個type結構可以使不同的，通過mapping進行映射。
<3. Document
由於es存儲的數據是文檔型的，一條數據對應一篇文檔即相當於mysql數據庫中的一行數據row，一個文檔中可以有多個字段也就是mysql數據庫一行可以有多列。
<4. Field
es中一個文檔中對應的多個列與mysql數據庫中每一列對應
<5. Mapping
可以理解為mysql或者solr中對應的schema，只不過有些時候es中的mapping增加了動態識別功能，感覺很強大的樣子，其實實際生產環境上不建議使用，最好還是開始制定好了對應的schema為主。
<6. indexed
就是名義上的建立索引。mysql中一般會對經常使用的列增加相應的索引用於提高查詢速度，而在es中默認都是會加上索引的，除非你特殊制定不建立索引只是進行存儲用於展示，這個需要看你具體的需求和業務進行設定了。
<7. Query DSL
類似於mysql的sql語句，只不過在es中是使用的json格式的查詢語句，專業術語就叫：QueryDSL
<8. GET/PUT/POST
分別類似與mysql中的select/update/delete......
2. ElasticSearch整體架構圖
從下往上逐層講解：
1. Gateway層
es用來存儲索引文件的一個文件系統且它支持很多類型，例如：本地磁盤、共享存儲（做snapshot的時候需要用到）、hadoop的hdfs分布式存儲、亞馬遜的S3。它的主要職責是用來對數據進行長持久化以及整個集群重啟之后可以通過gateway重新恢復數據。
gateway.type: local/none
gateway.recover_after_nodes: 8
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
上面這個配置是表示本地磁盤同步，目的是為了防止集群恢復時不發生意想不到的問題。
gateway.expected_nodes: 10 --> 表示預期整個集群完整恢復是10個數據節點，而
recover_after_nodes：8 --> 表示恢復的時候必須當節點恢復8個以上的時候才開始恢復同步恢復數據，但是此時不是立馬就恢復數據，需要看
gateway.recover_after_time: 5m參數，當節點恢復夠8個節點時，需要等待5分鍾，如果5分鍾之內預期的10個節點都恢復了就立馬恢復數據；如果等待超過5分鍾預期的10個節點沒有完全恢復完畢，則也進行恢復數據。后續剩余的節點再恢復起來，則集群再將剩余的節點加入到集群中重新同步。
注意：以上配置都是基於2.2.x版本，截止到2017/3/4 為止，ELK版本都為5.2.2，已經將gateway配置全局參數去掉了，但是也有相對應的參數可以進行設置，該思想需要我們注意，為后續的優化做儲備。
2. Distributed Lucene Directory
Gateway上層就是一個lucene的分布式框架，lucene是做檢索的，但是它是一個單機的搜索引擎，像這種es分布式搜索引擎系統，雖然底層用lucene，但是需要在每個節點上都運行lucene進行相應的索引、查詢以及更新，所以需要做成一個分布式的運行框架來滿足業務的需要。
3. 四大模塊組件
districted lucene directory之上就是一些es的模塊，
Index Module是索引模塊，就是對數據建立索引也就是通常所說的建立一些倒排索引等；Search Module是搜索模塊，就是對數據進行查詢搜索；Mapping模塊是數據映射與解析模塊，就是你的數據的每個字段可以根據你建立的表結構通過mapping進行映射解析，如果你沒有建立表結構，es就會根據你的數據類型推測你的數據結構之后自己生成一個mapping，然后都是根據這個mapping進行解析你的數據；River模塊在es2.0之后應該是被取消了，它的意思表示是第三方插件，例如可以通過一些自定義的腳本將傳統的數據庫（mysql）等數據源通過格式化轉換后直接同步到es集群里，這個river大部分是自己寫的，寫出來的東西質量參差不齊，將這些東西集成到es中會引發很多內部bug，嚴重影響了es的正常應用，所以在es2.0之后考慮將其去掉。
4. Discovery、Script
es4大模塊組件之上有
Discovery模塊：es是一個集群包含很多節點，很多節點需要互相發現對方，然后組成一個集群包括選主的，這些es都是用的discovery模塊，默認使用的是 Zen，也可是使用EC2；es查詢還可以支撐多種script即腳本語言，包括mvel、js、python等等。
5. Transport協議層
再上一層就是es的通訊接口Transport，支持的也比較多：Thrift、Memcached以及Http，默認的是http，JMX就是java的一個遠程監控管理框架，因為es是通過java實現的。
6. RESTful接口層
最上層就是es暴露給我們的訪問接口，官方推薦的方案就是這種RESTful接口，直接發送http請求，方便后續使用nginx做代理、分發包括可能后續會做權限的管理，通過http很容易做這方面的管理。如果使用java客戶端它是直接調用api，在做負載均衡已經權限管理還是不太好做。
3. ElasticSearch各節點的認識
masternode:true datanode:true 既可以masternode也可以datanode
masternode:true datanode:false 只可以masternode
masternode:false datanode:true 只可以datanode
masternode:false datanode:false 只可以clientnode
master node：負責整個集群的管理，包括元數據的管理、新節點的加入和退出，所以 masternode 是整個集群中最重要的，相當於人的大腦一樣，集群所有的更新管理都是由 master 來做的，而es是分布式系統，需要保證 masternode 高可用，所以需要配置多個 master 被選者即凡是你將 masternode 設置為 true 那么它們都是備選，當前的 masternode 掛掉 ElasticSearch 就會從其余備選的 node 中選出一個作為新的 masternode。
data node：
它不負責元數據的管理、新節點的加入和退出，這都是 master 通知它來干的事情，即 master 讓它干什么它就干什么，且 master 會將元數據發給 datanode 存儲一份，同樣的也會給 clientnode 發送一份元數據，由上圖也可以看出來，當請求發送給 clientnode，clientnode 直接發送給 datanode 它是不需要通過 masternode 轉發的。這里有一個好處就是可以避免單點故障的，（了解 hadoop 的就知道，namenode 也即 ElasticSearch 中的 master，它所有的原信息都存放在 namenode 上，不管是查詢還是導入數據都是通過 namenode 查詢定位才導入，這樣可想而知當你的集群規模大且數據量比較大對應的 QPS 特別高的情況下，那你的 namenode 壓力就特別大了。即使集群可以水平擴展但是 namenode 是瓶頸），而 ElasticSearch 就不需要，因為不管是 datanode 還是 clientnode 每個節點上都存有元信息，可以直接知道哪個數據在哪個分片上，這里不需要 masternode。datanode 只負責對數據的索引、查詢、存儲方面的需求。
masternode 一般 10G 就算高的了，但是 datanode 和 clientnode 需要配置高點，一般配置為 32G 左右
client node：它即不負責元數據管理、新節點加入和退出，也不負責存儲數據。一般用 clientnode 做為查詢使用，即用戶發送的請求都放到 clientnode 上，clientnode 再將不同的查詢發送到不同的 datanode 上進行查詢，查詢返回結構后再在 clientnode 做一次加工，例如再此基礎上在做一次分組、統計或者排序等等的工作，然后再返回給客戶端。clientnode 可以看做是客戶端和es之間的一個過濾器或者交互人。
4. ElasticSearch 集群健康狀態
我們可以通過命令得到集群的健康狀態：
| 顏色 | 意義 |
| green | 所有主要分片(primary shard) 和復制分片都可用 |
| yellow | 所有主要分片可用(primary shard)，但不是所有復制分片都可用 |
| red | 不是所有的主要分片都可用 |
有時候會有這種情況，當我們在自己電腦上啟動一個實例節點，之后我們創建一個索引，指定：3主1從 --> 6個節點。之后我們通過命令查看發現集群狀態是 yellow，即表示所有的主分片啟動完成且運行正常，集群可以正常處理任何請求，但是復制分片還沒有全部可用。事實上所有的3個復制分片現在都還是 unassigned 狀態，它們還未被分配給節點。因為在同一個節點上保存相同的數據副本是沒有必要的，如果這個節點故障了，那所有的數據副本也會丟失。