解析ES的document核心元資料：_index，_type，_id，_source

 WinnXUDONG 關注

2018.04.05 20:24 字數 1099 閱讀 324評論 0喜歡 3

進入Kibana的DevTools執行下面操作：

#新增一條document
PUT /test_index/test_type/1
{
  "test_content":"test test"
}

#查詢
GET /test_index/test_type/1
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_content": "test test"
  }
}
 

1、 _index元資料解析

• 代表這個document存放在哪個index中
• 類似的資料放在一個索引，非類似的資料放不同索引。例如：product index（包含了所有的商品），sales index（包含了所有的商品銷售資料），inventory index（包含了所有庫存相關的資料）。如果你把比如product，sales，human resource（employee），全都放在一個大的index裡面，比如說company index，不合適的。
• index中包含了很多類似的document：類似是什麼意思，其實指的就是說，這些document的fields很大一部分是相同的，你說你放了3個document，每個document的fields都完全不一樣，這就不是類似了，就不太適合放到一個index裡面去了。

• 索引名稱必須是小寫的，不能用下劃線開頭，不能包含逗號：product，website，blog

   

  

  為什麼類似的資料放在一個索引，非類似的資料放不同索引

2、 _type元資料解析

• 代表document屬於index中的哪個類別（type）
• 一個索引通常會劃分為多個type，邏輯上對index中有些許不同的幾類資料進行分類：因為一批相同的資料，可能有很多相同的fields，但是還是可能會有一些輕微的不同，可能會有少數fields是不一樣的，舉個例子，就比如說，商品，可能劃分為電子商品，生鮮商品，日化商品，等等。
• type名稱可以是大寫或者小寫，但是同時不能用下劃線開頭，不能包含逗號

3、 _id元資料解析

• 代表document的唯一標識，id與index和type一起，可以唯一標識和定位一個document
• 我們可以手動指定document的id（put /index/type/id），也可以不指定，由es自動為我們建立一個id

4、document id的手動指定與自動生成兩種方式解析

1. 手動指定document id
（1）根據應用情況來說，是否滿足手動指定document id的前提：

• 一般來說，是從某些其他的系統中，匯入一些資料到es時，會採取這種方式，就是使用系統中已有資料的唯一標識，作為es中document的id。

舉個例子，比如說，我們現在在開發一個電商網站，做搜尋功能，或者是OA系統，做員工檢索功能。這個時候，資料首先會在網站系統或者IT系統內部的資料庫中，會先有一份，此時就肯定會有一個數據庫的primary key（自增長，UUID，或者是業務編號）。如果將資料匯入到es中，此時就比較適合採用資料在資料庫中已有的primary key。

• 如果說，我們是在做一個系統，這個系統主要的資料儲存就是es一種，也就是說，資料產生出來以後，可能就沒有id，直接就放es一個儲存，那麼這個時候，可能就不太適合說手動指定document id的形式了，因為你也不知道id應該是什麼，此時可以採取下面要講解的讓es自動生成id的方式。

#語法：
put /index/type/id
#手動生成id
PUT /test_index/test_type/2
{
  "test_content": "my test"
}

2. 自動生成document id

#語法：
post /index/type
#自動生成id
POST /test_index/test_type
{
  "test_content": "my test"
}
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "AWKVr3MWWhuqAs-7Mpj5",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

自動生成的id，長度為20個字元，URL安全，base64編碼，GUID，分散式系統並行生成時不可能會發生衝突

GUID：GUID演算法，可保證在分散式的環境下，不同節點同一時間建立的 _id 一定是不衝突的。

GUID不衝突解釋

4、_source元資料以及定製返回結果解析

1. _source元資料

#新增資料
put /test_index/test_type/1
{
  "test_field1": "test field1",
  "test_field2": "test field2"
}

#獲取
get /test_index/test_type/1
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

_source元資料：就是說，我們在建立一個document的時候，使用的那個放在request body中的json串（所有的field），預設情況下，在get的時候，會原封不動的給我們返回回來。

1. 定製返回結果

定製返回的結果，指定_source中，返回哪些field

#語法：
GET /test_index/test_type/1?_source=test_field2
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field2": "test field2"
  }
}

#也可返回多個field使用都好分割
GET /test_index/test_type/1?_source=test_field2,test_field1