什么是文檔？

程序中大多的實體或對象能夠被序列化為包含鍵值對的JSON對象，鍵(key)是字段(field)或屬性(property)的名字，值(value)可以是字符串、數字、布爾類型、另一個對象、值數組或者其他特殊類型，比如表示日期的字符串或者表示地理位置的對象。

1

{"name": "John Smith","age": 42,"confirmed": true,"join_date": "2014-06-01","home": {"lat": 51.5,"lon": 0.1},"accounts": [{"type": "facebook","id": "johnsmith"},{"type": "twitter","id": "johnsmith"}] }

通常，我們可以認為對象(object)和文檔(document)是等價相通的。不過，他們還是有所差別：對象(Object)是一個JSON結構體——類似于哈希、hashmap、字典或者關聯數組；對象(Object)中還可能包含其他對象(Object)。 在Elasticsearch中，文檔(document)這個術語有著特殊含義。它特指最頂層結構或者根對象(root object)序列化成的JSON數據（以唯一ID標識并存儲于Elasticsearch中）。

1

文檔元數據

一個文檔不只有數據。它還包含了元數據(metadata)——關于文檔的信息。三個必須的元數據節點是：

節點說明

_index	文檔存儲的地方
_type	文檔代表的對象的類
_id	文檔的唯一標識

_index

索引(index)類似于關系型數據庫里的“數據庫”——它是我們存儲和索引關聯數據的地方。

提示：

事實上，我們的數據被存儲和索引在分片(shards)中，索引只是一個把一個或多個分片分組在一起的邏輯空間。然而，這只是一些內部細節——我們的程序完全不用關心分片。對于我們的程序而言，文檔存儲在索引(index)中。剩下的細節由Elasticsearch關心既可。

1

我們將會在《索引管理》章節中探討如何創建并管理索引，但現在，我們將讓Elasticsearch為我們創建索引。我們唯一需要做的僅僅是選擇一個索引名。這個名字必須是全部小寫，不能以下劃線開頭，不能包含逗號。讓我們使用website做為索引名。

1

_type

在應用中，我們使用對象表示一些“事物”，例如一個用戶、一篇博客、一個評論，或者一封郵件。每個對象都屬于一個類(class)，這個類定義了屬性或與對象關聯的數據。user類的對象可能包含姓名、性別、年齡和Email地址。

1

在關系型數據庫中，我們經常將相同類的對象存儲在一個表里，因為它們有著相同的結構。同理，在Elasticsearch中，我們使用相同類型(type)的文檔表示相同的“事物”，因為他們的數據結構也是相同的。

每個類型(type)都有自己的映射(mapping)或者結構定義，就像傳統數據庫表中的列一樣。所有類型下的文檔被存儲在同一個索引下，但是類型的映射(mapping)會告訴Elasticsearch不同的文檔如何被索引。 我們將會在《映射》章節探討如何定義和管理映射，但是現在我們將依賴Elasticsearch去自動處理數據結構。

_type的名字可以是大寫或小寫，不能包含下劃線或逗號。我們將使用blog做為類型名。

_id

id僅僅是一個字符串，它與_index和_type組合時，就可以在Elasticsearch中唯一標識一個文檔。當創建一個文檔，你可以自定義_id，也可以讓Elasticsearch幫你自動生成。

其它元數據

還有一些其它的元數據，我們將在《映射》章節探討。使用上面提到的元素，我們已經可以在Elasticsearch中存儲文檔并通過ID檢索——換言說，把Elasticsearch做為文檔存儲器使用了。

索引一個文檔

文檔通過index?API被索引——使數據可以被存儲和搜索。但是首先我們需要決定文檔所在。正如我們討論的，文檔通過其_index、_type、_id唯一確定。們可以自己提供一個_id，或者也使用index?API 為我們生成一個。

1

使用自己的ID

如果你的文檔有自然的標識符（例如user_account字段或者其他值表示文檔），你就可以提供自己的_id，使用這種形式的index?API：

PUT /{index}/{type}/{id} {"field": "value",... }

例如我們的索引叫做“website”，類型叫做“blog”，我們選擇的ID是“123”，那么這個索引請求就像這樣：

PUT /website/blog/123 {"title": "My first blog entry","text": "Just trying this out...","date": "2014/01/01" }

Elasticsearch的響應：

{"_index": "website","_type": "blog","_id": "123","_version": 1,"created": true }

響應指出請求的索引已經被成功創建，這個索引中包含_index、_type和_id元數據，以及一個新元素：_version。

2

Elasticsearch中每個文檔都有版本號，每當文檔變化（包括刪除）都會使_version增加。在《版本控制》章節中我們將探討如何使用_version號確保你程序的一部分不會覆蓋掉另一部分所做的更改。

自增ID

如果我們的數據沒有自然ID，我們可以讓Elasticsearch自動為我們生成。請求結構發生了變化：PUT方法——“在這個URL中存儲文檔”變成了POST方法——"在這個類型下存儲文檔"。（譯者注：原來是把文檔存儲到某個ID對應的空間，現在是把這個文檔添加到某個_type下）。

URL現在只包含_index和_type兩個字段：

POST /website/blog/ {"title": "My second blog entry","text": "Still trying this out...","date": "2014/01/01" }

響應內容與剛才類似，只有_id字段變成了自動生成的值：

2

{"_index": "website","_type": "blog","_id": "wM0OSFhDQXGZAWDf0-drSA","_version": 1,"created": true }

自動生成的ID有22個字符長，URL-safe, Base64-encoded string universally unique identifiers, 或者叫?UUIDs。

檢索文檔

想要從Elasticsearch中獲取文檔，我們使用同樣的_index、_type、_id，但是HTTP方法改為GET：

GET /website/blog/123?pretty

響應包含了現在熟悉的元數據節點，增加了_source字段，它包含了在創建索引時我們發送給Elasticsearch的原始文檔。

{"_index" : "website","_type" : "blog","_id" : "123","_version" : 1,"found" : true,"_source" : {"title": "My first blog entry","text": "Just trying this out...","date": "2014/01/01"} }

pretty

在任意的查詢字符串中增加pretty參數，類似于上面的例子。會讓Elasticsearch美化輸出(pretty-print)JSON響應以便更加容易閱讀。_source字段不會被美化，它的樣子與我們輸入的一致。

GET請求返回的響應內容包括{"found": true}。這意味著文檔已經找到。如果我們請求一個不存在的文檔，依舊會得到一個JSON，不過found值變成了false。

此外，HTTP響應狀態碼也會變成'404 Not Found'代替'200 OK'。我們可以在curl后加-i參數得到響應頭：

curl -i -XGET http://localhost:9200/website/blog/124?pretty

現在響應類似于這樣：

HTTP/1.1 404 Not Found Content-Type: application/json; charset=UTF-8 Content-Length: 83{"_index" : "website","_type" : "blog","_id" : "124","found" : false }

檢索文檔的一部分

通常，GET請求將返回文檔的全部，存儲在_source參數中。但是可能你感興趣的字段只是title。請求個別字段可以使用_source參數。多個字段可以使用逗號分隔：

GET /website/blog/123?_source=title,text

_source字段現在只包含我們請求的字段，而且過濾了date字段：

{"_index" : "website","_type" : "blog","_id" : "123","_version" : 1,"exists" : true,"_source" : {"title": "My first blog entry" ,"text": "Just trying this out..."} }

或者你只想得到_source字段而不要其他的元數據，你可以這樣請求：

GET /website/blog/123/_source

它僅僅返回:

{"title": "My first blog entry","text": "Just trying this out...","date": "2014/01/01" }

檢查文檔是否存在

如果你想做的只是檢查文檔是否存在——你對內容完全不感興趣——使用HEAD方法來代替GET。HEAD請求不會返回響應體，只有HTTP頭：

curl -i -XHEAD http://localhost:9200/website/blog/123

Elasticsearch將會返回200 OK狀態如果你的文檔存在：

HTTP/1.1 200 OK Content-Type: text/plain; charset=UTF-8 Content-Length: 0

如果不存在返回404 Not Found：

curl -i -XHEAD http://localhost:9200/website/blog/124 HTTP/1.1 404 Not Found Content-Type: text/plain; charset=UTF-8 Content-Length: 0

當然，這只表示你在查詢的那一刻文檔不存在，但并不表示幾毫秒后依舊不存在。另一個進程在這期間可能創建新文檔。

更新整個文檔

文檔在Elasticsearch中是不可變的——我們不能修改他們。如果需要更新已存在的文檔，我們可以使用《索引文檔》章節提到的index?API?重建索引(reindex)?或者替換掉它。

PUT /website/blog/123 {"title": "My first blog entry","text": "I am starting to get the hang of this...","date": "2014/01/02" }

在響應中，我們可以看到Elasticsearch把_version增加了。

1

{"_index" : "website","_type" : "blog","_id" : "123","_version" : 2,"created": false <1> }

• <1>?created標識為false因為同索引、同類型下已經存在同ID的文檔。

在內部，Elasticsearch已經標記舊文檔為刪除并添加了一個完整的新文檔。舊版本文檔不會立即消失，但你也不能去訪問它。Elasticsearch會在你繼續索引更多數據時清理被刪除的文檔。

在本章的后面，我們將會在《局部更新》中探討update?API。這個API?似乎?允許你修改文檔的局部，但事實上Elasticsearch遵循與之前所說完全相同的過程，這個過程如下：

從舊文檔中檢索JSON

修改它

刪除舊文檔

索引新文檔

唯一的不同是update?API完成這一過程只需要一個客戶端請求既可，不再需要get和index請求了。

from:?https://es.xiaoleilu.com/030_Data/05_Document.html

總結

以上是生活随笔為你收集整理的ElasticSearch什么是文档？索引一个文档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。