當出現文件寫入請求時，es 內部到底發生了哪些過程？面對大批量的寫入請求，es 如何可以做到近實時的可搜尋？為了滿足聚合分析的等功能，es 又做了哪些事情？本文試圖對這些問題進行回答，文章大綱如下所示：
文件寫入操作
es 內部文件處理過程
文件最終資料格式
建立索引
put twitter
}
put twitter/_doc/1
生成 docid
分配到指定分片
寫入記憶體 buffer 形成 segment，並記錄 translog
segment 重新整理到檔案快取
segment 落盤，提交 commit point
translog flush
生成 docid，docid 是文件在 es 集群中的唯一標識，預設的生成策略是基於時間戳uuid的 base64 編碼，核心**如下：
// org.elasticsearch.common.uuids
private static final uuidgenerator time_uuid_generator = new timebaseduuidgenerator();
time_uuid_generator.getbase64uuid();
文件分配，文件獲得 docid 之後 es 會根據設定的分片數對 docid 進行 hash 操作，確定將文件分配到哪個分片，從而保證每個分片上的文件數量均衡增長，不會使得哪個分片負載過重，並且在進行搜尋時是對每個分片並行查詢，將文件平均分配到不同的分片可以最大化的利用不同機器的效能，加快搜尋過程。文件分配策略如下：
shard_num = hash(_id) % num_primary_shards資料落盤，通常 segment 在經過預設的refresh_interval (1s)之後會同步到磁碟，同時會更新commit檔案表示資料已經持久化儲存，此時 translog 檔案會進行 flush 操作，清空 translog 檔案，如果 segment 落盤失敗，就不會發生 commit 提交操作，es 就會從 translog 的上乙個 commit 點進行恢復。
一致性保證，translog 也是記錄在記憶體中，為了保證 translog 的一致性，es 預設情況下 5s 會對 translog 進行一次刷盤操作，或者每次發生請求操作時，translog 會採用同步的方式進行落盤。由於落盤是乙個很耗時的過程，因此在資料寫入時盡可能的採用大批量寫入的方式一次傳送多條資料，減少 translog 的落盤次數，或者當某些資料對一致性的要求不高時，我們可以調整 translog 落盤的方式為非同步刷盤，這樣可以極大的提公升資料寫入的效能，但也不要過大的設定刷盤時間，在資料量較大的情況下可能會導致記憶體消耗過高。調整 translog 非同步刷盤的操作如下：
put twitter}}}
inverted index 被稱作倒排索引，主要包含兩部分：
stored fields 被稱作字段查詢，主要用於查詢包含某個特定標題內容的檔案，其本質上是乙個簡單的鍵值對key-value，但官方並不推薦使用，預設情況下會關閉此功能，推薦使用source filtering功能來代替。
document values 是 es 的列式儲存，用於分析和排序。簡單理解docvalues的話，它是乙個以docid為鍵，以value為值的map。它儲存docid到文件的正向關係，在排序或者統計計算時，通過docid可以迅速取字段的值進行二次計算。
這些資料結構對應儲存在磁碟上的檔案格式如下表所示：
**引用：ES系列 修改字段對映型別
之前在沒有建立索引模板的時候，直接通過logstash往es裡塞資料，其中一些欄位的型別並不符合我們需要，這個時候就需要去修改欄位的對映型別了。es不支援直接修改字段型別，解決思路 新建臨時索引，執行字段型別，複製資料 刪除舊索引，重建同名索引，從臨時索引複製資料 獲取舊索引的字段對映 建立臨時索引...
ES如何指定返回的字段field
在elasticsearch 2.x版本中，如果我們想指定查詢返回的字段，可以使用fields欄位設定，如下 string index string type 指定要返回的字段 string fields new string 2 fields 0 field1 欄位1名稱 fields 1 fil...
ES如何指定返回的字段field
在elasticsearch 2.x版本中，如果我們想指定查詢返回的字段，可以使用fields欄位設定，如下 string index string type 指定要返回的字段 string fields new string 2 fields 0 field1 欄位1名稱 fields 1 fil...