確定shard的公式：
shard = hash(routing) % number_of_primary_shards因此要在建立索引的時候就確定好主分片的數量，並且永遠不會改變這個數量，因為如果數量變化了，那麼所有之前路由的值都會無效。
每個節點都知道集群中任一文件位置，所以可以直接將請求發到任意節點。當然，為了擴充套件負載，更好的做法是輪詢傳送集群中所有的節點。
步驟：
戶端向 node 1 傳送新建、索引或者刪除請求。
節點使用文件的 _id 確定文件屬於shard 0 。請求會被**到 node 3（因為shard 0 被分配在 node 3 上）。
node 3 在shard 0上面執行請求。如果成功了，它將請求並行**到 node 1 和 node 2 的replica r0上。一旦所有的r0都報告成功, node 3 將向node 1報告成功，node 1向客戶端報告成功。
步驟：
客戶端向 node 1 傳送查詢請求。
node 1使用文件的 _id 來確定文件屬於shard 0 。replica 0 存在於node 1、node 2上。 這種情況下，每次請求都會輪詢路由node 1、node 2，這裡假設路由到node 2。
node 2將文件返回給node 1 ，然後node 1將文件返回給客戶端。
注意：在文件被檢索時，已經被索引的文件可能已經存在於shard上但是還沒有複製到replica。即強一致性無法保證，但最終一致性可以保證。
步驟略。
注意：
node 3 從p0檢索文件，修改 _source 欄位中的 json ，並且嘗試重新索引主分片的文件。 如果文件已經被另乙個程序修改（_version衝突），它會重試步驟 3 ，超過 retry_on_conflict 次後放棄。
如果 node 3 成功地更新文件，它將新版本的文件並行**（新建、索引或者刪除請求的步驟裡**的是請求而不是文件）到 node 1 和 node 2 上的r0，重新建立索引。一旦所有r0都返回成功，node 3 向node 1返回成功，node 1向客戶端返回成功。
為什麼要**文件而不是請求？
因為**請求是非同步的，不能保證到達replica的順序，若**更新請求，則可能以錯誤的順序應用更改，導致得到損壞的文件。而**文件，則replica可以直接根據_version來獲取最大版本號的文件。
bulk步驟：
客戶端向 node 1 傳送 bulk 請求。
node 1 為每個命中的shard建立乙個批量請求，並將這些請求並行**到每個包含該shard的節點。
shard按順序（請求報文體中的子請求順序）執行每個操作。當乙個子請求操作成功時，shard並行**新文件（或刪除）到replica，然後執行下乙個子請求。 一旦所有的子請求的replica向shard報告完成（無論執行是否成功），該shard將向node 1報告，node 1將這些響應收集整理並返回給客戶端。
乙個lucene索引在elasticsearch稱作shard。 乙個elasticsearch索引是shard的集合。
ElasticSearch 檢索文件
現在elasticsearch中已經儲存了一些資料，我們可以根據業務需求開始工作了。第乙個需求是能夠檢索單個員工的資訊。這對於elasticsearch來說非常簡單。我們只要執行http get請求並指出文件的 位址 索引 型別和id既可。根據這三部分資訊，我們就可以返回原始json文件 檢索命令如...
Elasticsearch 文件操作
1.elasticserach api 操作 elasticsearch rest api遵循的格式為 curl x 檢查es版本資訊 http ip 9200 檢視集群是否健康 http ip 9200 cat health?v 檢視節點列表 http ip 9200 cat nodes?v 列出...
Elasticsearch 管理文件
es支援近實時的索引 更新 查詢 刪除文件，近實時就意味著剛剛索引的資料需要1秒鐘後才能搜尋到，這也是與傳統的sql資料庫不同的地方。更多的es文件資料參考 elasticsearch官方文件翻譯 之前已經試過如何索引乙個文件了，這裡再複習一下 curl xput localhost 9200 cu...