Elasticsearch系列---全面瞭解Document

概要

本篇主要介紹一下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手動指定與自動生成兩種方式：

1. 手動指定
   PUT命令行指定ID時，即手動方式

PUT /music/children/id

1. 自動生成
   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寫操做

1. 強制建立
   強制建立在語法上多了_create參數，或op_type=create，如

PUT /music/children/id/_create
或
PUT /music/children/id?op_type=create

強制建立與全量替換的異同點：

• 當ID不存在時，兩者的效果同樣。
• 當ID存在時，全量替換作更新操做，強制建立報錯，提示"version conflict, document already exists"錯誤。

1. 刪除document

若是對一個document執行delete操做，ES不會當即進行物理刪除，而是先標記爲deleted狀態，當文件數據變多知足必定條件後，ES再執行物理刪除，相似於JVM的垃圾清理。
這個過程叫軟刪除，也叫lazy delete。

1. 全量替換&增量更新

全量替換

全量替換命令能夠屢次執行，若是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架構社區