ElasticSearch新增檢索資料

程式中大多的實體或物件能夠被序列化為包含鍵值對的json物件，鍵(key)是字段(field)或屬性(property)的名字，值(value)可以是字串、數字、波爾型別、另乙個物件、值陣列或者其他特殊型別，比如表示日期的字串或者表示地理位置的物件。

文件元資料（document metadata）：

乙個文件不只有資料。它還包含了元資料(metadata)——關於文件的資訊。三個必須的元資料節點是：

節點說明

_index文件儲存的地方

_type文件代表的物件的類

_id文件的唯一標識

索引(index)類似於關係型資料庫裡的「資料庫」——它是我們儲存和索引關聯資料的地方。

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

後面會繼續**如何建立並管理索引，但現在，我們將讓elasticsearch為我們建立索引。我們唯一需要做的僅僅是選擇乙個索引名。這個名字必須是全部小寫，不能以下劃線開頭，不能包含逗號。讓我們使用website做為索引名。

在關係型資料庫中，我們經常將相同類的物件儲存在乙個表裡，因為它們有著相同的結構。同理，在elasticsearch中，我們使用相同型別(type)的文件表示相同的「事物」，因為他們的資料結構也是相同的。

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

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

ps：還有其它部分其它元資料，後續再介紹。

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

put ///

｛"key": "value"...｝

如，put /website/blog/123

elasticsearch中每個文件都有版本號，每當文件變化（包括刪除）都會使_version增加。後續我們將**如何使用_version號確保你程式的一部分不會覆蓋掉另一部分所做的更改。

如果我們的資料沒有自然id，我們可以讓elasticsearch自動為我們生成。請求結構發生了變化：put方法——「在這個url中儲存文件」變成了post方法——"在這個文件下儲存文件"。（注：原來是把文件儲存到某個id對應的空間，現在是把這個文件新增到某個_type下）。

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

post /website/blog/

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

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

put /website/blog/123

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

在後面**updateapi，這個api 似乎允許你修改文件的區域性，但事實上elasticsearch遵循與之前所說完全相同的過程，這個過程如下：

從舊文件中檢索json

修改它刪除舊文件

索引新文件

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

刪除文件的語法模式與之前基本一致，只不過要使用delete方法：

delete /website/blog/1234

如果文件被找到，elasticsearch將返回200 ok狀態碼和以下響應體。注意_version數字已經增加了。

如果文件未找到，我們將得到乙個404 not found狀態碼，響應體是這樣的：

ElasticSearch新增 檢索資料