ElasticSearch 知识点整理（入门）
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 https://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)每次都會選擇一個不同的分片拷貝來實現負載均衡 -循環使用所有的分片拷貝。
可能存在這種情況，當一份文檔正在被索引時，該文檔在主要分片已經就緒了，但是還未被拷貝到其他副本分片上。
此時副本分片或許報告文檔不存在(譯注：此時有讀請求來獲取該文檔)，然而主要分片能夠成功返回需要的文檔 。
一旦索引請求返回給用戶的響應是成功，那么文檔在主要分片以及所有副本分片上都是可用的。
總結
以上是生活随笔為你收集整理的ElasticSearch 知识点整理（入门）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Elasticsearch中的Multi
- 下一篇： ElasticSearch 知识点整理（