1、資料路由
1.1 文件儲存怎麼路由到相應分片？
一個文件，最終會落在主分片的一個分片上，到底應該在哪一個分片？這就是資料路由。
1.2 路由演算法
shard = hash(routing) % number_of_primary_shards
簡單來說就是雜湊值對主分片數取模。
舉例：
對一個文件經行crud時，都會帶一個路由值 routing number。預設為文件_id（可能是手動指定，也可能是自動生成）。
儲存1號文件，經過雜湊計算，雜湊值為2,此索引有3個主分片，那麼計算2%3=2，就算出此文件在P2分片上。決定一個document在哪個shard上，最重要的一個值就是routing值，預設是_id，也可以手動指定，相同的routing值，每次過來，從hash函式中，產出的hash值一定是相同的。無論hash值是幾，無論是什麼數字，對number_of_primary_shards求餘數，結果一定是在0~number_of_primary_shards-1之間這個範圍內的。
1.3 手動指定 routing number
PUT /test_index/_doc/15?routing=num { "num": 0, "tags": [] }
場景：在程式中，架構師可以手動指定已有資料的一個屬性為路由值，好處是可以定製一類文件資料儲存到一個分片中。缺點是設計不好，會造成資料傾斜。所以，不同文件儘量放到不同的索引中。剩下的事情交給es叢集自己處理。
1.4 主分片數量不可變
涉及到以往資料的查詢搜尋，所以一旦建立索引，主分片數不可變。
2、文件(Document)的增刪改內部機制（寫資料過程）
增刪改可以看做update,都是對資料的改動。一個改動請求傳送到es叢集，經歷以下四個步驟：
（1）客戶端選擇一個node傳送請求過去，這個node就是coordinating node（協調節點）
（2）coordinating node，對document進行路由，將請求轉發給對應的node（有primary shard）
（3）實際的node上的primary shard處理請求，然後將資料同步到replica node。
（4）coordinating node，如果發現primary node和所有replica node都搞定之後，就返回響應結果給客戶端。
如上圖所示，存在一個book索引，3個主分片，一個副本分片。比如說選擇第一個節點為協調節點，在根據id進行資料路由，判斷出屬於第一個分片，找到對應的主分片完成對應的請求，在去對應的副本分片完成請求，最後在將響應結果返回給客戶端。
3、文件的查詢內部機制（讀資料過程）
1、客戶端傳送請求到任意一個node，成為coordinate node
2、coordinate node對document進行路由，將請求轉發到對應的node，此時會使用round-robin隨機輪詢演算法，在primary shard以及其所有replica中隨機選擇一個，讓讀請求負載均衡
3、接收請求的node返回document給coordinate node
4、coordinate node返回document給客戶端
5、特殊情況：document如果還在建立索引過程中，可能只有primary shard有，任何一個replica shard都沒有，此時可能會導致無法讀取到document，但是document完成索引建立之後，primary shard和replica shard就都有了。
如上圖所示，存在一個book索引，3個主分片，一個副本分片。比如說選擇第一個節點為協調節點，在根據id進行資料路由，判斷出屬於第一個分片，在primary shard以及其所有replica中隨機選擇一個，最後在將響應結果返回給客戶端。
4、文件的搜尋機制（過程）
es 最強大的是做全文檢索，就是比如你有三條資料：
java真好玩兒啊java好難學啊j2ee特別牛
你根據 java 關鍵詞來搜尋，將包含 java的 document 給搜尋出來。es 就會給你返回：java真好玩兒啊，java好難學啊。
-
客戶端傳送請求到一個
coordinate node。 -
協調節點將搜尋請求轉發到所有的 shard 對應的
primary shard或replica shard，都可以。 -
query phase：每個 shard 將自己的搜尋結果（其實就是一些
doc id）返回給協調節點，由協調節點進行資料的合併、排序、分頁等操作，產出最終結果。 -
fetch phase：接著由協調節點根據
doc id去各個節點上拉取實際的document資料，最終返回給客戶端。
5、bulk api奇特的json格式
POST /_bulk {"action": {"meta"}} {"data"} {"action": {"meta"}} {"data"} [ { "action":{ "method":"create" }, "data":{ "id":1, "field1":"java", "field1":"spring", } }, { "action":{ "method":"create" }, "data":{ "id":2, "field1":"java", "field1":"spring", } } ]
如上所示，為什麼bulk api不採用下面的那種閱讀性非常強的格式而是採用上面那種格式呢？原因有以下3點。
1、bulk中的每個操作都可能要轉發到不同的node的shard去執行
2、如果採用比較良好的json陣列格式，這種格式允許任意的換行，整個可讀性非常棒，讀起來很爽，es拿到這種標準格式的json串以後，要按照下述流程去進行處理
（1）將json陣列解析為JSONArray物件，這個時候，整個資料，就會在記憶體中出現一份一模一樣的拷貝，一份資料是json文字，一份資料是JSONArray物件
（2）解析json陣列裡的每個json，對每個請求中的document進行路由
（3）為路由到同一個shard上的多個請求，建立一個請求陣列。100請求中有10個是到P1.
（4）將這個請求陣列序列化
（5）將序列化後的請求陣列傳送到對應的節點上去
3、耗費更多記憶體，更多的jvm gc開銷。
一般來說bulk size最佳大小在幾千條左右，然後大小在10MB左右，所以說，可怕的事情來了。假設說現在100個bulk請求傳送到了一個節點上去，然後每個請求是10MB，100個請求，就是1000MB = 1GB，然後每個請求的json都copy一份為jsonarray物件，此時記憶體中的佔用就會翻倍，就會佔用2GB的記憶體，甚至還不止。因為弄成jsonarray之後，還可能會多搞一些其他的資料結構，2GB+的記憶體佔用。佔用更多的記憶體可能就會積壓其他請求的記憶體使用量，比如說最重要的搜尋請求，分析請求，等等，此時就可能會導致其他請求的效能急速下降。另外的話，佔用記憶體更多，就會導致java虛擬機器的垃圾回收次數更多，跟頻繁，每次要回收的垃圾物件更多，耗費的時間更多，導致es的java虛擬機器停止工作執行緒的時間更多。
再看看現在的奇特格式
POST /_bulk { "delete": { "_index": "test_index", "_id": "5" }} { "create": { "_index": "test_index", "_id": "14" }} { "test_field": "test14" }\n { "update": { "_index": "test_index", "_id": "2"} } { "doc" : {"test_field" : "bulk test"} }\n
（1）不用將其轉換為json物件，不會出現記憶體中的相同資料的拷貝，直接按照換行符切割json
（2）對每兩個一組的json，讀取meta，進行document路由
（3）直接將對應的json傳送到node上去
這種格式最大的優勢在於，不需要將json陣列解析為一個JSONArray物件，形成一份大資料的拷貝，不至於浪費記憶體空間，也能儘可能地保證效能。