概要
本篇主要介紹一下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架構社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/2111.html
標籤：其他