Elasticsearch由淺入深（三）document的核心元數據、Id、_source元數據、全量替換、強制建立以及刪除機制

document的核心元數據

document的核心元數據有三個：_index、_type、_id

初始化數據：

PUT test_index/test_type/1
{
  "test_content":"test test"
}

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

View Code

查詢數據：

GET test_index/test_type/1

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_content": "test test"
  }
}

View Code

_index元數據

• 表明一個document存放在哪一個index中
• 相似的數據放在一個索引中，非相似的數據放在不一樣的索引中：product index(包含了全部的商品)、sales index(包含了全部的商品銷售數據)、inventory index(包含了全部庫存的相關數據)
• index中包含了不少相似的document： 相似是什麼意思呢，其實指的就是說，這些document的fields很大一部分是相同的，你說你放了3個document，每一個document的fields都徹底不同，這就不是相似了，就不太適合放到一個index裏面去了
• 索引名稱必須是小寫，不能用下劃線開頭，不包含逗號

_type元數據

• 表明document屬於index的哪一個類別
• 一個索引一般會劃分爲多個type，邏輯上對index有些許不一樣的幾類數據進行分類
• type名稱能夠是大寫或者小寫，可是同時不能用下劃線開頭，不能包含逗號

_id元數據

• 表明document的惟一標識，與_index和_type一塊兒能夠起惟一標識和定位一個document
• 咱們能夠手動指定document的id,也能夠不指定，由es自動爲咱們建立一個id

Id手動與自動生成

手動指定document id

根據應用狀況來講，是否知足手動指定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
{
  「json」
}

示例：

PUT /test_index/test_type/2
{
  "test_content": "my test"
}

自動生成document id

語法：

post /index/type
{
  "json"
}

示例：

POST /test_index/test_type
{
  "test_content": "my test"
}

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "AWypxxLYFCl_S-ox4wvd",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

自動生成的id，長度爲20個字符，URL安全、base64編碼、GUID、分佈式系統並行生成時不可能發生衝突。

_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"
  }
}

View Code

_source元數據，就是說，咱們在建立一個document的時候，使用的那個放在request body中的json串，默認狀況下，在get的時候會原封不動的給咱們返回。

定製返回結果

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

GET /test_index/test_type/1?_source=test_field1,test_field2

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

全量替換、強制建立以及刪除

document的全量替換

數據準備：

PUT test_index/test_type/4
{
  "test_field":"test test"
}

1. 語法與建立文檔是同樣的，若是document id不存在，那麼就是建立；若是document id已經存在，那麼就是全量替換操做，替換document的json串內容
2. document是不可變的，若是要修改document的內容，第一種方式就是全量替換，直接對document從新創建索引，替換裏面全部的內容
3. es會將老的document標記爲deleted，而後新增咱們給定的一個document，當咱們建立愈來愈多的document的時候，es會在適當的時機在後臺自動刪除標記爲deleted的document

document的強制建立

建立文檔與全量替換的語法是同樣的，有時咱們只是想新建文檔，不想替換文檔，若是強制進行建立呢？

語法：

PUT /index/type/id?op_type=create
或者
PUT /index/type/id/_create

document的刪除

語法：

DELETE /index/type/id

不會理解物理刪除，只會將其標記爲deleted，當數據愈來愈多的時候，在後臺自動刪除