elasticsearch 文件資料解析（五）

2021-10-06 21:39:38 字數 3436 閱讀 5430

乙個文件不僅僅包含它的資料 ，也包含元資料——有關文件的資訊，三個必須的元資料元素如下：

_index

乙個 索引 應該是因共同的特性被分組到一起的文件集合。 例如，你可能儲存所有的產品在索引 products 中，而儲存所有銷售的交易到索引 sales 中。 雖然也允許儲存不相關的資料到乙個索引中，但這通常看作是乙個反模式的做法。

實際上，在 elasticsearch 中，我們的資料是被儲存和索引在 分片 中，而乙個索引僅僅是邏輯上的命名空間， 這個命名空間由乙個或者多個分片組合在一起。 然而，這是乙個內部細節，我們的應用程式根本不應該關心分片，對於應用程式而言，只需知道文件位於乙個 索引 內。 elasticsearch 會處理所有的細節。

我們將在 索引管理 介紹如何自行建立和管理索引，但現在我們將讓 elasticsearch 幫我們建立索引。 所有需要我們做的就是選擇乙個索引名，這個名字必須小寫，不能以下劃線開頭，不能包含逗號。我們用 website 作為索引名舉例。

_type

資料可能在索引中只是鬆散的組合在一起，但是通常明確定義一些資料中的子分割槽是很有用的。 例如，所有的產品都放在乙個索引中，但是你有許多不同的產品類別，比如 「electronics」 、 「kitchen」 和 「lawn-care」。

這些文件共享一種相同的（或非常相似）的模式：他們有乙個標題、描述、產品**和**。他們只是正好屬於「產品」下的一些子類。

elasticsearch 公開了乙個稱為 types （型別）的特性，它允許您在索引中對資料進行邏輯分割槽。不同 types 的文件可能有不同的字段，但最好能夠非常相似。 我們將在 型別和對映 中更多的討論關於 types 的一些應用和限制。

乙個 _type 命名可以是大寫或者小寫，但是不能以下劃線或者句號開頭，不應該包含逗號， 並且長度限制為256個字元. 我們使用 blog 作為型別名舉例。

_id

id 是乙個字串，當它和 _index 以及 _type 組合就可以唯一確定 elasticsearch 中的乙個文件。 當你建立乙個新的文件，要麼提供自己的 _id ，要麼讓 elasticsearch 幫你生成。

通過使用 index api ，文件可以被 索引 —— 儲存和使文件可被搜尋。 但是首先，我們要確定文件的位置。乙個文件的 _index 、 _type 和 _id 唯一標識乙個文件。 我們可以提供自定義的 _id 值，或者讓 index api 自動生成。

put ///
舉個例子，如果我們的索引稱為 website ，型別稱為 blog ，並且選擇 123 作為 id ，那麼索引請求應該是下面這樣：

put /website/blog/123
elasticsearch 響應體如下所示：

該響應表明文件已經成功建立，該索引包括 _index 、 _type 和 _id 元資料， 以及乙個新元素： _version 。

在 elasticsearch 中每個文件都有乙個版本號。當每次對文件進行修改時（包括刪除）， _version 的值會遞增。 在 處理衝突 中，我們討論了怎樣使用 _version 號碼確保你的應用程式中的一部分修改不會覆蓋另一部分所做的修改。

現在該 url 只需包含 _index 和 _type :

post /website/blog/
除了 _id 是 elasticsearch 自動生成的，響應的其他部分和前面的類似：

自動生成的 id 是 url-safe、 基於 base64 編碼且長度為20個字元的 guid 字串。 這些 guid 字串由可修改的 flakeid 模式生成，這種模式允許多個節點並行生成唯一 id ，且互相之間的衝突概率幾乎為零。

為了從 elasticsearch 中檢索出文件，我們仍然使用相同的 _index , _type , 和 _id ，但是 http 謂詞更改為 get :

get /website/blog/123?pretty
響應體包括目前已經熟悉了的元資料元素，再加上 _source 字段，這個字段包含我們索引資料時傳送給 elasticsearch 的原始 json 文件：



}
在請求的查詢串引數中加上 pretty 引數，正如前面的例子中看到的，這將會呼叫 elasticsearch 的 pretty-print 功能，該功能 使得 json 響應體更加可讀。但是， _source 字段不能被格式化列印出來。相反，我們得到的 _source 欄位中的 json 串，剛好是和我們傳給它的一樣。

get 請求的響應體包括 ，這證實了文件已經被找到。 如果我們請求乙個不存在的文件，我們仍舊會得到乙個 json 響應體，但是 found 將會是 false 。 此外， http 響應碼將會是 404 not found ，而不是 200 ok 。

我們可以通過傳遞 -i 引數給 curl 命令，該引數能夠顯示響應的頭部：

curl -i -xget http://localhost:9200/website/blog/124?pretty
顯示響應頭部的響應體現在類似這樣：

獲取文件的指定資源

預設情況下， get 請求會返回整個文件，這個文件正如儲存在 _source 欄位中的一樣。但是也許你只對其中的 title 字段感興趣。單個欄位能用 _source 引數請求得到，多個欄位也能使用逗號分隔的列表來指定。

get /website/blog/123?_source=title,text
該 _source 字段現在包含的只是我們請求的那些字段，並且已經將 date 字段過濾掉了。



}
或者，如果你只想得到 _source 字段，不需要任何元資料，你能使用 _source 字段提取：

get /website/blog/123/_source
那麼返回的的內容如下所示：

在 elasticsearch 中文件是 不可改變 的，不能修改它們。相反，如果想要更新現有的文件，需要 重建索引 或者進行替換， 我們可以使用相同的 index api 進行實現：

put /website/blog/123
在響應體中，我們能看到 elasticsearch 已經增加了 _version 字段值：

ElasticSearch 檢索文件

現在elasticsearch中已經儲存了一些資料，我們可以根據業務需求開始工作了。第乙個需求是能夠檢索單個員工的資訊。這對於elasticsearch來說非常簡單。我們只要執行http get請求並指出文件的 位址 索引 型別和id既可。根據這三部分資訊，我們就可以返回原始json文件 檢索命令如...

Elasticsearch 文件操作

1.elasticserach api 操作 elasticsearch rest api遵循的格式為 curl x 檢查es版本資訊 http ip 9200 檢視集群是否健康 http ip 9200 cat health?v 檢視節點列表 http ip 9200 cat nodes?v 列出...

ElasticSearch 文件儲存

確定shard的公式 shard hash routing number of primary shardsrouting 預設是文件的 id 也可以設定成乙個自定義的值。因此要在建立索引的時候就確定好主分片的數量，並且永遠不會改變這個數量，因為如果數量變化了，那麼所有之前路由的值都會無效。每個節點...