mastering elasticsearch

概念：

Term: 它是搜索的基本單位，其表現形式爲文本中的一個詞。
Token: 它是單個Term在所屬Field中文本的呈現形式，包含了Term內容、Term類型、Term在文本中的起始及偏移位置。 

 

倒排索引結構（簡單版）：

此 外，每一個詞映射着一個數值(Count)，它表明着Term在文檔集中出現的頻繁程度。 

| Term | count | Docs |

| Cookbook | 1 | <3> |

指 Cookbook在文檔3中出現一次。固然，Lucene建立的真實索引遠比上文複雜和先進 

 

每一個索引被分紅了多個段(Segment)，段具備一次寫入，屢次讀取的特色。只要造成了， 段就沒法被修改。例如:被刪除文檔的信息被存儲到一個單獨的文件，可是其它的段文件並 沒有被修改。 

 

文本分析工做由analyzer組件負責。analyzer由一個分詞器(tokenizer)和0個或者多個過 濾器(filter)組成,也可能會有0個或者多個字符映射器(character mappers)組成。

Lucene中的tokenizer用來把文本拆分紅一個個的Token。Token包含了比較多的信息， 好比Term在文本的中的位置及Term原始文本，以及Term的長度。 

 

若是用戶的Document中有title和description 兩個Field，那麼這兩個Field能夠指定不一樣的analyzer。 

 

有的Query對象會被解析(analyzed)，有的不會，好比:前綴查詢(prefix query)就不會被解析，精確匹配查詢(match query)就會被解析。對用戶來講，理解這一點至 關重要。 

 

一個Query對象中會存在多個布爾運算符，這些布爾運算符將多個Term關聯起來造成查詢子 句。 

ElasticSearch 把數據分發到多個存儲Lucene索引的物理機上。這些Lucene索引稱爲分片索引，這個分發的 過程稱爲索引分片(Sharding)。在ElasticSearch集羣中，索引分片(Sharding)是自動完成的， 並且全部分片索引(Shard)是做爲一個總體呈現給用戶的。須要注意的是，儘管索引分片這個 過程是自動的，可是在應用中須要事先調整好參數。由於集羣中分片的數量須要在索引建立 前配置好，並且服務器啓動後是沒法修改的，至少目前沒法修改。 

 

在運行的過程當中，ElasticSearch會收集集羣的狀態、索引的參數等信息。這些數據被存 儲在Gateway中。 

 

ES背後的核心理念:

自動容錯。ElasticSearch經過P2P網絡進行通訊，這種工做方式消除了單點故障。節點 自動鏈接到集羣中的其它機器，自動進行數據交換及以節點之間相互監控。索引分片 

ElasticSearch是構建在極少數的幾個概念之上的。ElasticSearch的開發團隊但願它可以 快速上手，可擴展性強。並且這些核心特性體如今ElasticSearch的各個方面。從架構的角度 來看，這些主要特性是:

開箱即用。安裝好ElasticSearch後，全部參數的默認值都自動進行了比較合理的設置， 基本不須要額外的調整。包括內置的發現機制(好比Field類型的自動匹配)和自動化參數配 置。

天生集羣。ElasticSearch默認工做在集羣模式下。節點都將視爲集羣的一部分，並且在 啓動的過程當中自動鏈接到集羣中。

自動容錯。ElasticSearch經過P2P網絡進行通訊，這種工做方式消除了單點故障。節點 自動鏈接到集羣中的其它機器，自動進行數據交換及以節點之間相互監控。索引分片

擴展性強。不管是處理能力和數據容量上均可以經過一種簡單的方式實現擴展，即增添 新的節點。

近實時搜索和版本控制。因爲ElasticSearch天生支持分佈式，因此延遲和不一樣節點上數 據的短暫性不一致無可避免。ElasticSearch經過版本控制(versioning)的機制儘可能減小問 題的出現。 

 

在集羣中，一個節點被選舉成主節點(master node)。這個節點負責管理集羣的狀態，當 羣集的拓撲結構改變時把索引分片分派到相應的節點上。 

主節點在ElasticSearch中並無佔據着重要的地位 

 

任何節點均可以併發地把查詢子句分發到其它的節點，而後合併各個節點返回的查詢結果

對於每一個丟失的主分片，新的主分片將從剩餘的分片 副本(Replica)中選舉出來 

主節點向其它的節點發送Ping命令而後等待迴應。若是沒有得 到迴應(實際上可能得不到回覆的Ping命令個數取決於用戶配置)，該節點就會被移出集羣。 

 

若是索引數據的請求發送到的節點沒有合適的分片或者分片是副本，那 麼請求會被轉發到含有主分片的節點。 

 

Lucene默認的打分機制:TF/IDF(term frequency/inverse document frequecy)算法 

 

基本上，從前面的公式中能夠提煉出如下的幾個規則:

匹配到的關鍵詞越稀有，文檔的得分就越高。

文檔的域越小(包含比較少的Term)，文檔的得分就越高。

設置的權重(索引和搜索時設置的均可以)越大，文檔得分越高。 

 

索引分片機制用來存儲超過單個節點存儲容量的數據，分片副本用來應對不斷攀升的吞 吐量以及確保數據的安全性 

 

路由功能向ElasticSearch提供一種信息來決定哪些分片用於存儲和 查詢 

 

一個重要的配置項：

cluster.routing.allocation.awareness.attributes:group 

 

決定新節點加入集羣后，如何將p/r shard從新分配。

 

在集羣中使用了shard allocation awareness功能後，ElasticSearch不會把決定allocation awareness的屬性(在本例中是 node.group值)相同的分片或者分片副本分配到同一個節點中。該功能典型的用例是把集羣拓 撲結構部署到物理機或者虛擬機時，確保你的集羣不會出現單點故障問題。 

分片分配機制不會考慮分配分片到沒有設 置node.group屬性的節點。 

 

index.routing.allocation.total\_shards\_per\_node屬性值爲1，這意味着對於每一個索引， ElasticSearch只會在單個節點上分配一個分片。這應用到咱們的4-節點集羣的例子中就是每 個節點會平均分配全部的分片。 

 

對於ElasticSearch來講，最核心的一種配置就是集羣恢復配置 

 

從新索引：

第二個想法是建立第二個索引，而且添加數據，而後把應用接口調轉到新的索 引。方案可行，可是有個小問題，建立新的索引須要額外的空間開銷。 

 

咱們已經屢次提到，ElasticSearch建立的目的就是對應集羣工做環境。這是跟與 ElasticSearch功能相似的其它開源解決方案(好比solr)主要的不一樣點。其它解決方案也許一樣 能或難或易地應用於多節點的分佈式環境，可是對對於ElasticSearch來講，工做在分佈式環 境就是它天天的生活。因爲節點發現機制，它最大程度簡化了集羣的 安裝和配置。

該發現機制主要基於如下假設: 集羣由cluster.name設置項相同的節點自動鏈接而成。 這就容許了同一個網段中存在多個獨立的集羣。自動發現機制的缺點在於:若是有人忘記改 變cluster.name的設置項，無心中鏈接到其它的某個集羣。在這種狀況下，ElasticSearch可能 出於從新平衡集羣狀態的考慮，將一些數據移動到了新加入的節點。當該節點被關閉，節點 所在的集羣中會有部分數據像出現魔法同樣憑空消失。 

 

Zen發現機制的故障檢測

ElasticSearch運行時會啓動兩個探測進程。一個進程用於從主節點向集羣中其它節點發 送ping請求來檢測節點是否正常可用。另外一個進程的工做反過來了，其它的節點向主節點發送 ping請求來驗證主節點是否正常且忠於職守。 

 

數據遷移怎麼作：

 

爲了完成上述的操做，須要執行以下的步 驟:

中止發生在ElasticSearch集羣中的數據索引操做(這可能意味着中止rivers或者任何向 ElasticSearch集羣發送數據的應用)

用Flush API刷新全部尚未提交的數據。

 

爲集羣中的每個分片至少建立一個拷貝，萬一出現問題，也能找回數據。固然，若是但願儘量簡單地解決問題，也能夠複製整個集羣中每一個節點的全部數據做爲備用集羣。