Elasticsearch系列---全面瞭解Document

概要

本篇主要介紹一下document的知識,對document的元數據和基本的語法進行講解。java

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互不影響。json

命名規範:名稱小寫,不能以'_', '-', 或 '+'開頭。安全

_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的印象。

相關文章
相關標籤/搜索