概要
本篇主要介紹一下document的知識，對document的元數據和基本的語法進行講解。
document核心元數據
前面入門實戰一節有簡單介紹過document數據示例，這次我們來詳細瞭解一下它的核心元數據，查詢響應報文如下：
{
"_index": "music",
"_type": "children",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"name": "gymbo",
"content": "I hava a friend who loves smile, gymbo is his name",
"language": "english",
"length": "75"
}
}_index元數據
代表一個document存放在哪個index中，項目約定結構類似的數據放在一個索引，不同數據放不同索引裏，所以同一個index中document結構基本是類似的，個別document多一個或少一個field，這樣Elasticsearch對磁盤存儲的利用率最高。
每個index有自己獨立的shard存儲文件，與其他index互不影響。
命名規範：名稱小寫，不能以'_', '-', 或 '+'開頭。
_type元數據
ES 6.0.0之後一個index下面只能有一個type，最早指定是啥就是啥。
命名規範：可以用'_'開頭，由於只有一個，官方示例上直接使用'_doc'。
_id元數據
document的唯一標識，與index一起唯一標識和定位一個document，可以手動指定，也可以由ES自動創建。
_version元數據
ES內部使用樂觀鎖對document的寫操作進行控制，version版本號最初是1，更新操作成功後自動+1。
found元數據
document的搜索標誌，成功是true，未搜索到是false。
_source元數據
裏面是我們在新增時放在http request body的json串內容，是保存的業務數據，默認Get操作時，會原封不動地全部返回給客戶端。
用Get命令搜索document時，可以定製返回的結果，在請求的_source中指定想要的field即可，示例命令：
GET /music/children/_search
{
"query": {
"match_all" : {}
},
"_source": ["name","content"]
}document id
document的id手動指定與自動生成兩種方式：
- 手動指定
PUT命令行指定ID時，即手動方式
PUT /music/children/id
- 自動生成
PUT命令行沒指定ID時，此時ES會自動生成的id，長度爲20個字符，URI安全，base64編碼，GUID，保證不重複。
PUT /music/children
我們的項目中怎麼選擇ID生成方式呢？
一般來說，看Elasticsearch在系統裏承擔的角色，如果是業務系統，本身有關係型數據完成數據的落地，Elasticsearch的價值就是填補關係型數據的全文搜索的短板，Elasticsearch的數據源頭，本身在帶ID的，這種情況下應該使用手動指定ID的方式，直接用數據庫存儲數據的ID即可，後續的搜索功能，也很容易與數據庫建立對應 關係。例如訂單數據，此時的ID直接使用訂單ID即可，而訂單ID的生成方式，無論是自增ID，雪花ID，對Elasticsearch來講都不要緊，保證唯一性即可。
而自動ID生成的場景，比如有些系統，它沒有關係型數據庫，Elasticsearch可能就是它唯一的數據落地方案，這種數據結構，ID沒有太多的重要性，這時讓Elasticsearch自動生成一個，可以保存到Elasticsearch即可。
tips: GUID、UUID、COMB概念
- UUID：是128位整數(16字節)的通用唯一識別碼 (Universally Unique Identifier)，它是由開放軟件基金會（OSF）定義的一個軟件建構的標準。
- GUID：是微軟對UUID這個標準的實現。UUID還有其它各種實現，不止GUID一種。
- COMB（combine）型是數據庫特有的一種設計思想，可以理解爲一種改進的GUID，它通過組合GUID和系統時間，以使其在索引和檢索時有更優的性能。
GUID與UUID的區別，生成的格式不同。
document寫操作
- 強制創建
強制創建在語法上多了_create參數，或op_type=create，如
PUT /music/children/id/_create
或
PUT /music/children/id?op_type=create
強制創建與全量替換的異同點：
- 當ID不存在時，二者的效果一樣。
- 當ID存在時，全量替換做更新操作，強制創建報錯，提示"version conflict, document already exists"錯誤。
- 刪除document
如果對一個document執行delete操作，ES不會立即進行物理刪除，而是先標記爲deleted狀態，當文件數據變多滿足一定條件後，ES再執行物理刪除，類似於JVM的垃圾清理。
這個過程叫軟刪除，也叫lazy delete。
- 全量替換&增量更新
全量替換
全量替換命令可以多次執行，如果ID不存在，執行創建document操作，如果ID存在，執行更新，語法示例：
PUT /music/children/id
全量替換的原理：當全量替換請求發送到ES上時，會將該ID原有的document執行軟刪除，然後再新建一個document，把request body的內容存儲到新的document中，後續的GET查詢只關注非deleted狀態的document，這樣就完成了一次全量替換操作。
增量更新前必須保證該ID是存在的，存在執行更新操作，若不存在，拋出"document_missing_exception"錯誤信息。
增量更新
增量更新的原理，與全量替換基本一致，也有軟刪除過程，只是創建新的document時，需要將原有的document數據拷貝一份，再用增量的內容進行覆蓋，得到一個新的document。
增量更新比全量替換的優點
- 查詢修改寫回操作，都發生在一個shard內部，網絡帶寬更小（有2次網絡傳輸），大大提升了性能
- 減少了查詢和修改中的時間時隔，可以有效減少併發衝突的情況（毫秒級的更新）
- 減輕應用程序拼接全量數據的工作量（如果json field比較多，拼接一個完整的document是很費事的）
小結
本篇主要圍繞document的元數據進行了簡單的講解，希望可以加深對document的印象。
專注Java高併發、分佈式架構，更多技術乾貨分享與心得，請關注公衆號：Java架構社區
