本篇主要介紹一下document的知識,對document的元數據和基本的語法進行講解。java
前面入門實戰一節有簡單介紹過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" } }
表明一個document存放在哪一個index中,項目約定結構相似的數據放在一個索引,不一樣數據放不一樣索引裏,因此同一個index中document結構基本是相似的,個別document多一個或少一個field,這樣Elasticsearch對磁盤存儲的利用率最高。
每一個index有本身獨立的shard存儲文件,與其餘index互不影響。json
命名規範:名稱小寫,不能以'_', '-', 或 '+'開頭。安全
ES 6.0.0以後一個index下面只能有一個type,最先指定是啥就是啥。網絡
命名規範:能夠用'_'開頭,因爲只有一個,官方示例上直接使用'_doc'。數據結構
document的惟一標識,與index一塊兒惟一標識和定位一個document,能夠手動指定,也能夠由ES自動建立。併發
ES內部使用樂觀鎖對document的寫操做進行控制,version版本號最初是1,更新操做成功後自動+1。性能
document的搜索標誌,成功是true,未搜索到是false。編碼
裏面是咱們在新增時放在http request body的json串內容,是保存的業務數據,默認Get操做時,會原封不動地所有返回給客戶端。命令行
用Get命令搜索document時,能夠定製返回的結果,在請求的_source中指定想要的field便可,示例命令:
GET /music/children/_search { "query": { "match_all" : {} }, "_source": ["name","content"] }
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概念
GUID與UUID的區別,生成的格式不一樣。
強制建立在語法上多了_create參數,或op_type=create,如
PUT /music/children/id/_create
或PUT /music/children/id?op_type=create
強制建立與全量替換的異同點:
若是對一個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。
增量更新比全量替換的優勢
本篇主要圍繞document的元數據進行了簡單的講解,但願能夠加深對document的印象。