1：es介紹
Elasticsearch是一個基於Lucene的實時的分佈式搜索和分析引擎。設計用於雲計算中，
能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。基於RESTful接口。
普通請求是…get?a=1
rest請求….get/a/1
2：全文搜索的工具有哪些
Lucene Solr Elasticsearch
3：es的bulk的引用場景
1.bulk API可以幫助我們同時執行多個請求
2.create
和index的區別
如果數據存在，使用create操作失敗，會提示文檔已經存在，使用index則可以成功執行。
3.可以使用文件操作
使用文件的方式
vi requests
curl -XPOST/PUT localhost:9200/_bulk –data-binary @request;
bulk請求可以在URL中聲明/_index
或者/_index/_type
4.bulk一次最大處理多少數據量
- bulk會把將要處理的數據載入內存中，所以數據量是有限制的
- 最佳的數據量不是一個確定的數值，它取決於你的硬件，你的文檔大小以及複雜性，你的索引以及搜索的負載
- 一般建議是1000-5000個文檔，如果你的文檔很大，可以適當減少隊列,大小建議是5-15MB，默認不能超過100M，
- 可以在es的配置文件中修改這個值http.max_content_length: 100mb
5.版本控制的一個問題
- 在讀數據與寫數據之間如果有其他線程進行寫操作，就會出問題，es使用版本控制才避免這種問題。
- 在修改數據的時候指定版本號，操作一次版本號加1。
6.es的兩個web訪問工具
- BigDesk Plugin (作者 Lukáš Vlček) 簡介：監控es狀態的插件,推薦！主要提供的是節點的實時狀態監控，包括jvm的情況，linux的情況，elasticsearch的情況
- Elasticsearch Head Plugin (作者 Ben Birch) 簡介：很方便對es進行各種操作的客戶端。
4：核心概念
集羣
cluster***
代表一個集羣，集羣中有多個節點，其中有一個爲主節點，這個主節點是可以通過選舉產生的，主從節點是對於集羣內部來說的。
es的一個概念就是去中心化，字面上理解就是無中心節點，這是對於集羣外部來說的，因爲從外部來看es集羣，在邏輯上是個整體，
你與任何一個節點的通信和與整個es集羣通信是等價的。
主節點的職責是負責管理集羣狀態，包括管理分片的狀態和副本的狀態，以及節點的發現和刪除。
只需要在同一個網段之內啓動多個es節點，就可以自動組成一個集羣。
默認情況下es會自動發現同一網段內的節點，自動組成集羣。
分片
shards*
代表索引分片，es可以把一個完整的索引分成多個分片，這樣的好處是可以把一個大的索引拆分成多個，分佈到不同的節點上。構成分佈式搜索。分片的數量只能在索引創建前指定，並且索引創建後不能更改。
可以在創建索引庫的時候指定
curl -XPUT ‘localhost:9200/test1/’ -d’{“settings”:{“number_of_shards”:3}}’
默認是一個索引庫有5個分片
index.number_of_shards: 5
副本 replicas*
代表索引副本，es可以給索引設置副本，副本的作用一是提高系統的容錯性，當某個節點某個分片損壞或丟失時可以從副本中恢復。
二是提高es的查詢效率，es會自動對搜索請求進行負載均衡。
可以在創建索引庫的時候指定，副本數後期可以更改。
curl -XPUT ‘localhost:9200/test2/’ -d’{“settings”:{“number_of_replicas”:2}}’
默認是一個分片有1個副本
index.number_of_replicas: 1
數據重新分佈
recovery *
代表數據恢復或叫數據重新分佈，es在有節點加入或退出時會根據機器的負載對索引分片進行重新分配，掛掉的節點重新啓動時也會進行數據恢復。
數據的持久化操作
gateway*
代表es索引的持久化存儲方式，es默認是先把索引存放到內存中，當內存滿了時再持久化到硬盤。
當這個es集羣關閉再重新啓動時就會從gateway中讀取索引數據。es支持多
種類型的gateway，有本地文件系統（默認），分佈式文件系統，Hadoop的HDFS和amazon的s3雲存儲服務。
自動發現機制
discovery.zen*
代表es的自動發現節點機制，es是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。
集羣或節點與客戶端交互的方式
Transport*
代表es內部節點或集羣與客戶端的交互方式，默認內部是使用tcp協議進行交互，同時它支持http協議（json格式）、thrift、servlet、memcached、zeroMQ等的傳輸協議（通過插件方式集成）。
index
和rdbms中的數據庫相似
type
表
document
行
field
列
5：serachType
四種搜索類型，詳細介紹
分佈式搜索的流程
- 先把查詢請求發送給集羣的某一個節點
- 某個節點把最終的結果返回給客戶端
QUERY_AND_FETCH
1：客戶端把請求發送給集羣中的某一個節點，這個節點會把查詢請求發 送給所有分片去執行，
2：每個分片會把查詢的數據(包含數據的分值,以及數據的詳細內容)返回給某一個節點進行彙總，排序，然後把這些數據返回給客戶端
這樣客戶端可能會收到(10*分片數量)
的數據
這種方案，數據量和排名都有問題。
優點：效率高，查詢速度快
QUERY_THEN_FETCH（默認）
1：客戶端把請求發送給集羣中的某一個節點，這個節點會把查詢請求發送給所有分片去執行，
2：每個分片會把查詢的數據(包含數據的分值,以及數據ID)返回給某一個 節點進行彙總，排序，取前10名
3：根據前10名的id到對應的分片查詢數據的詳細內容，返回給客戶端
這種方案，解決了數據量的問題。
但是排名還有有問題。
(DFS：初始化散發過程)
DFS_QUERY_AND_FETCH
1：在查詢之前，會把所有分片的詞頻和文檔頻率(打分依據)彙總到一塊
2：客戶端把請求發送給集羣中的某一個節點，這個節點會把查詢請求發送給所有分片去執行，
3：每個分片會把查詢的數據(包含數據的分值,以及數據的詳細內容)返回
給某一個節點進行彙總，排序，然後把這些數據返回給客戶端
解決了排名的問題
還存在數據量的問題
DFS_QUERY_THEN_FETCH
1：在查詢之前，會把所有分片的詞頻和文檔頻率(打分依據)彙總到一塊
2：客戶端把請求發送給集羣中的某一個節點，這個節點會把查詢請求發送給所有分片去執行，
3：每個分片會把查詢的數據(包含數據的分值,以及數據ID)返回給某一個節點進行彙總，排序，取前10名
4：根據前10名的id到對應的分片查詢數據的詳細內容，返回給客戶端
既解決了排名問題，也解決了數據量的問題
但是性能最低
總結一下，從性能考慮QUERY_AND_FETCH是最快的，DFS_QUERY_THEN_FETCH是最慢的。從搜索的準確度來說，DFS要比非DFS的準確度更高。
高亮
補：高亮的注意事項：
高亮的內容和原始內容是分開返回的
高亮字段的內容必須在es中存儲(是否存儲這個屬性的值必須是true)
分組：分組統計數量或者分組統計分數
刪除索引庫：兩種方式xurl或者java api
Timeout
：
6：建立索引和查詢的流程
建立索引的流程：
首先根據空白符進行分割再切分關鍵詞，去除停用詞，如果有英文全部轉換爲小寫，對切分的關鍵詞建立索引，每個關鍵詞都有對應的id，還有一個倒排索引隊列存儲該關鍵詞出現在文檔的id，在該文檔出現的次數，在該文檔出現的位置
查詢的流程：
首先根據空白符進行分割，再切分關鍵詞，去除停用詞，如果有英文全部轉換爲小寫，將切分後的到的關鍵詞和索引庫進行匹配
中文分詞器-IK
es官方提供的分詞插件對中文分詞效果不是很好，可以集成ik分詞，對中文分詞效果比較好
如果想根據自己的規則進行分詞，可以自定義分詞庫，自定義分詞庫文件必須以.dic結尾，詞庫文件的編碼爲utf—8
without bom，一個詞語一行，將自定義的文件庫加入到ES_HOME/config/ik/
目錄下，修改ik的配置文件，重啓生效
7：爲什麼使用索引工具查詢快
(使用了倒排索引的技術，大致介紹一下倒排索引，還有索引庫中的詞都是按照順序排列
，
後期根據一個關鍵詞查詢的時候，可以利用類似折半查找的算法，查詢效率非常高)
使用了倒排索引的技術，一般我們都是這樣定義id
關鍵詞，倒排索引是關鍵詞 id正好相反，使用索引工具進行查詢時，首先得到關鍵詞，建立倒排索引表，關鍵詞—-索引列表包含該關鍵詞所在的文檔的id、在該文檔中出現的次數、在該文檔中出現的位置信息，這種由屬性值確定記錄的位置的方式成爲倒排索引。還有
索引庫中的詞都是按照順序排列
，後期根據一個關鍵詞查詢的時候，
可以利用類似折半查找的算法，查詢效率非常高
8.setting 與mapping 作用
settings修改索引庫默認配置
例如：分片數量，副本數量
查看：curl -XGET http://localhost:9200/crxy/_settings?pretty
(操作不存在索引)
curl -XPUT ‘localhost:9200/crxy/’ -d’{“settings”:”number_of_shards”:3,”number_of_replicas”:2}}’
(操作已存在索引)
curl -XPUT ‘localhost:9200/crxy/_settings’ -d’{“index”:{“number_of_replicas”:2}}’
Mapping,動態mapping機制：這個機制會自定識別參數值的類型，自動給這個參數設置屬性
好處：操作方便，不需要提前考慮這個字段是否在es中定義過。
弊端：針對一個未知的數據，本來不應該存儲的，這樣也會存儲了，對數據基本沒有什麼可控性
在實際開發中，如果數據類型已知，建議還是關閉自動mapping。
如果數據類型未知，只能使用自定mapping機制
9：分片查詢方式：
es中默認的分片查詢方式爲隨機從分片中取數據，其他的分片查詢方式還有如：
- _local:查詢操作首先在本地查找，如果本地沒有再到其他節點進行查找
- _primary:只在主分片中查詢
- _shads:按照指定的分片進行查詢，這種查詢方式實現了es的極速查詢
（在存儲數據的時候通過rooting參數可以指定將數據分配到某一個分片中，rooting參數值相同的分配到一個分片中，後期查詢時可以根據rooting參數值指定到哪個分片中查找，從而實現了極速查詢）
修改源碼自定義從多個節點進行查詢等
10：es集羣的腦裂問題
es集羣有可能會出現腦裂問題，原因主要有兩個：
1）如果集羣中節點不在同一個網段有可能是網絡延遲造成的
2）如果集羣中的節點在同一個網段，有可能是主節點負載太大造成的
解決方案主要有兩種：
1）
把主從節點的職責分離,設置三個儲備主節點， node.master=true,node.data=false
從節點只存儲數據，node.master=false,node.data=true
2)增加延遲時間
將儲備主節點數最小設爲n/2+1個
11：優化
- 適當調大系統打開的最大打開文件數，默認爲1024
- 修改配置文件調整es的jvm內存的大小，根據服務器內存的大小，一般分配60%左右，默認是256M
- 分片的數量最好設置爲5-20個（es中一個分片最多存20G的數據，分片數在創建索引庫時就指定，而且創建後不能修改，分片數最少設置爲：數據量/20G個， 如果所有分片都存滿數據，需要再重新建立索引庫）分片設置的過多過少都會導致檢索比較慢，分片數過多會導致檢索時打開比較多的文件，
- 也會導致多臺服務器之間的通信；分片數過少會導致單個分片索引過大，所以檢索速度慢。
- 副本數多可以提升搜索能力，但是如果設置的副本數過多也會對服務器造成額外的壓力，因爲需要同步數據，所以設置2-3個即可
- 定時對索引進行優化，合併索引片段，一個索引片段的最好不要超過1G，將多個索引片段合併成一個大的索引片段時，不要太大，太大打開會很慢。
- 刪除一條數據時不會立即刪除，而是產生一個.del的文件，在檢索過程中這部分數據也會參與檢索，在檢索過程中會判斷是否刪除了，如果刪除了再過濾掉，這樣會降低檢索效率，可以定時執行curl命令進行刪除或通過程序代碼進行刪除。
- 如果項目開始的時候需要批量入庫大量數據，建議將副本數設爲0，因爲副本存在，數據要同步到副本，增加es的壓力，索引完成後再將副本數修改過來，這樣可以提高索引效率。
- 去掉mapping中的_all域，這個雖然會給查詢帶來方便，但是會增加索引時間和所以尺寸
- Log輸出的水平默認爲trace，查詢超過500ms即爲慢查詢，就要打日誌，造成cpu，內存，io負載很高，把log水平調爲info或是修改配置將查詢超時時間調的長一些。
12：典型的應用場景
es+hbase
利用兩個框架的優點實現快速複雜查詢和海量數據存儲
Es+hbase：利用這兩個框架的優點實現快速複雜查詢和海量數據存儲。
Es通過建立索引實現快速查詢，它也可以存儲但是不適合海量數據的存儲，只存儲需要那些需要從索引庫中直接返回給客戶的內容
Hbase適合海量數據存儲，按rowkey查詢可以實現快速查詢，但是按列查詢效率不高，所以結合es實現按字段快速查詢
例如：針對海量的文章數據進行存儲和快速複雜查詢服務就可以通過es+hbase
比如文章數據有：（如果是面試題，需要問清楚需求，需要根據哪些字段進行查詢，哪些內容直接從索引庫中直接返回給客戶，再進行下面的設置）
Es的設計：
- Id：es內置，既建立索引也存儲
- Title：既建立索引也存儲
- Author：不建立索引，存儲
- Describe：既建立索引也存儲
- Content：建立索引不存儲
- Hbase的設計：
- Rowkey的設計：文章的id
- 一個列族：info
- 列限定符：title，author，describe，content
13.客戶端請求過程
文檔能夠通過主要分片(Primary Shard)或者任意一個副本分片(Replica Shard)獲取。
每個步驟解釋如下：
- 客戶端(Client)發送一個請求到節點1。
- 該節點利用文檔的_id字段來判斷該文檔屬於分片0。分片0的分片拷貝(主要分片或者是副本分片)存在於所有的3個節點上。這一次，它將請求轉發到了節點2。
- 節點2將文檔返回給節點1，節點1隨即將文檔返回給客戶端。 對於讀請求(Read Request)，
- 請求節點(Requesting Node)每次都會選擇一個不同的分片拷貝來實現負載均衡 -循環使用所有的分片拷貝。
- 可能存在這種情況，當一份文檔正在被索引時，該文檔在主要分片已經就緒了，但是還未被拷貝到其他副本分片上。
- 此時副本分片或許報告文檔不存在(譯註：此時有讀請求來獲取該文檔)，然而主要分片能夠成功返回需要的文檔 。
- 一旦索引請求返回給用戶的響應是成功，那麼文檔在主要分片以及所有副本分片上都是可用的。