首先看下elasticsearch（es）的架構：
術語解釋：
es的分布式操作大多是自動完成的：
1、跨節點平衡集群中各節點的索引與搜尋負載；
2、自動複製索引資料以提供冗餘副本，防止硬體錯誤導致資料丟失；
3、自動在節點之間路由，以幫助找到檢索的資料；
4、無縫擴充套件或者恢復集群；
node（節點）是es執行中的例項，乙個或多個具有相同cluster.name的節點構成乙個cluster（集群），它們協同工作，共享資料，並共同分擔工作負載。
集群中的乙個節點會被選為master，它將負責管理集群範疇的變更，例如建立或刪除索引，在集群中新增或刪除節點，但master無需參與文件層面的變更和搜尋，這意味著僅有乙個master並不會因流量增長而成為瓶頸。
作為使用者，我們可以訪問包括master在內的集群中的任一節點，每個節點都知道各個文件的位置，並能夠將我們的請求直接**到擁有我們想要的資料的節點，無論我們訪問的是哪個節點它都會控制從擁有資料的節點收集響應的過程，並返回給客戶端最終的結果，這一切都是由es透明管理的。
在es中，分片用來分配集群中的資料。把分片想象成乙個資料的容器。資料被儲存在分片中，然後分片又被分配在集群的節點上。當你的集群擴充套件或者縮小時，elasticsearch會自動的在節點之間遷移分配分片，以便集群保持均衡。
分片分為 主分片(primary shard) 以及 從分片(replica shard) 兩種：
索引中的主分片的數量在索引建立後就固定下來了，但是從分片的數量可以隨時改變。
接下來，我們在空的單節點集群中上建立乙個叫做blogs的索引。乙個索引預設設定了5個主分片，但是為了演示，我們這裡只設定3個主分片和一組從分片（每個主分片有乙個從分片對應）：
put /blogs現在，我們的集群看起來就像下圖所示了有索引的單節點集群，這三個主分片都被分配在node 1。}
在es集群中可以監控統計很多資訊，其中最重要的就是：集群健康(cluster health)。它的 status 有 green、yellow、red 三種；
get /_cluster/health返回： 其中status可以告訴我們當前集群是否處於乙個可用的狀態。三種顏色分別代表：
狀態意義
green
所有主分片和從分片都可用
yellow
所有主分片可用，但存在不可用的從分片
red
存在不可用的主要分片
集群的健康狀況yellow意味著所有的 主分片(primary shards) 啟動並且執行了，這時集群已經可以成功的處理任意請求，但是 從分片(replica shards) 沒有完全被啟用。事實上，當前這3個從分片都處於unassigned（未分配）的狀態，它們還未被分配到節點上。在同乙個節點上儲存相同的資料副本是沒有必要的，如果這個節點故障了，就等同於所有的資料副本也丟失了。
為了提高系統的可用性，生產環境幾乎不會使用單節點es集群。
下面介紹如何使用雙節點集群(cluster-two-nodes)，只要第二個節點與第乙個節點的cluster.name相同（參見./config/elasticsearch.yml檔案中的配置），它就能自動發現並加入到第乙個節點的集群中。如果沒有，請結合日誌找出問題所在。這可能是多播（multicast）被禁用，或者防火牆阻止了節點間的通訊。
如下圖，雙節點集群——所有的主分片和從分片都被分配:
當第二個節點加入後，就產生了三個 從分片(replica shards) ，它們分別於三個主分片一一對應。也就意味著即使有乙個節點發生了損壞，我們可以保證資料的完整性。
所有被索引的新文件都會先被儲存在主分片中，之後才會被平行複製到關聯的從分片上。這樣可以確保我們的文件在主節點和從節點上都能被檢索。
隨著應用需求的增長，我們該如何擴充套件？如果我們啟動第三個節點，集群內會自動重組，這時便成為了三節點集群(cluster-three-nodes)。
分片已經被重新分配以平衡負載：
在node 1和node 2中分別會有乙個分片被移動到node 3上，這樣一來，每個節點上就都只有兩個分片了。這意味著每個節點的硬體資源（cpu、ram、i/o）被更少的分片共享，所以每個分片就會有更好的效能表現。
分片本身就是乙個非常成熟的搜尋引擎，它可以使用單個節點的所有資源。我們一共有6個節點（3個主分片和3個從分片），因此最多可以擴充套件到6個節點，每個節點上有乙個分片，這樣每個分片都可以使用到所在節點100%的資源了。
前面提到，主分片的數量在索引建立時就確定了，而從分片的數量可以隨時調整：
put /blogs/_settings將從分片的數量增加到2份：
從圖中可以看出，現在blogs的索引總共有9個分片：3個主分片和6個從分片。也就是說，現在我們就可以將總節點數擴充套件到9個，就又會變成乙個節點乙個分片的狀態了。最終我們得到了三倍搜尋效能的三節點集群。
如果上面的三節點集群中有乙個節點發生故障，例如：
被殺掉的節點是主節點。而為了集群的正常工作必須需要乙個主節點，所以首先進行的程序就是從各節點中選擇了乙個新的主節點：node 2。
主分片1和2在我們殺掉node 1後就丟失了，我們的索引在丟失主節點的時候是不能正常工作的。如果我們在這個時候檢查集群健康狀態，將會顯示red：存在不可用的主節點！
幸運的是，丟失的兩個主分片的完整拷貝在存在於其他的節點上，所以新的主節點所完成的第一件事情就是將這些在node 2和node 3上的從分片提公升為主分片，然後集群的健康狀態就變回至yellow。這個提公升的程序是瞬間完成了，就好像按了一下開關。
那麼為什麼集群健康狀態依然是是yellow而不是green呢？是因為現在我們有3個主分片，但是我們之前設定了1個主分片有2個從分片，但是現在卻只有1份從分片，所以狀態無法變為green，不過我們可以不用太擔心這裡：當我們再次殺掉node 2的時候，我們的程式依舊可以在沒有丟失任何資料的情況下執行，因為node 3中依舊擁有每個分片的備份。
如果我們重啟node 1，集群就能夠重新分配丟失的從分片，這樣結果就會與三節點兩從集群一致。如果node 1依舊還有舊節點的內容，系統會嘗試重新利用他們，並只會複製在故障期間的變更資料。
當需要新增乙個文件到索引中時，需要為這個文件找到乙個主分片進行儲存，它按照下面的公式選擇主分片：
shard = hash(文件id) % 主分片數量
其中，文件id也可以被替換成其它能唯一表示乙個文件的字串。另外，主分片數量在索引建立時就已經確定了，執行過程中不允許修改，因此，同乙個文件總是會被路由到同乙個主分片上。
es集群如果包含多個節點，每個節點都可以服務所有請求，節點可以根據上面的方法計算出當前請求的文件在哪個分片，然後**請求到該節點上。
elasticsearch學習筆記之二（CURD）
本文介紹elasticsearch的概念和curd 2.2 建立文件 表和記錄 2.3 更新文件 2.4 刪除文件 2.5 查詢文件 2.6 刪除型別 表 例如 http localhost 9200 blog user 1 關係型資料庫 elasticsearch 資料庫 blog index 表...
二 elasticsearch入門（資料）
程式中大多的實體或物件能夠被序列化為包含鍵值對的json物件，鍵 key 是字段 field 或屬性 property 的名字，值 value 可以是字串 數字 波爾型別 另乙個物件 值陣列或者其他特殊型別，比如表示日期的字串或者表示地理位置的物件。accounts 文件元資料 乙個文件不只有資料。...
ElasticSearch中文分詞（二）
1 中文分詞 中文分詞的難點在於，在漢語中沒有明顯的詞彙分界點，如在英語中，空格可以作為分隔符，如果分隔不正確就會造成歧義。常用中文分詞器，ik jieba thulac等，推薦使用ik分詞器。目錄下即可。如果使用docker執行 docker cp elasticsearch analysis i...