Elasticsearch 參考指南（探索你的集羣）

探索你的集羣

REST API

如今咱們已經啓動並運行了節點（和集羣），下一步是瞭解如何與它進行通訊，幸運的是，Elasticsearch提供了一個很是全面和強大的REST API，你可使用它與集羣進行交互，使用API​​能夠完成的一些事項以下：

• 檢查羣集，節點和索引運行情況，狀態和統計信息
• 管理你的羣集，節點和索引數據和元數據
• 對索引執行CRUD（建立，讀取，更新和刪除）和搜索操做
• 執行高級搜索操做，例如分頁，排序，過濾，腳本編寫，聚合等等

集羣健康

讓咱們從基本運行情況檢查開始，咱們可使用它來查看集羣的運行狀況，咱們將使用curl來執行此操做，但你可使用任何容許你進行HTTP/REST調用的工具，假設咱們仍然在咱們啓動Elasticsearch的同一節點上打開另外一個命令shell窗口。

要檢查羣集運行情況，咱們將使用_cat API，你能夠經過單擊「VIEW IN CONSOLE」在Kibana的控制檯中運行如下命令。

GET /_cat/health?v

或複製以下curl命令並將其粘貼到終端中：

curl -X GET "localhost:9200/_cat/health?v"

響應以下:

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1475247709 17:01:49  elasticsearch green           1         1      0   0    0    0        0             0                  -                100.0%

咱們能夠看到名爲「elasticsearch」的羣集處於green狀態。

每當咱們查看羣集健康時，咱們要麼得到green，yellow或red。

• Green — 一切都很好（集羣功能齊全）
• Yellow — 全部數據均可用，但還沒有分配一些副本（羣集功能齊全）
• Red — 某些數據因爲某種緣由不可用（羣集部分功能）

當羣集爲red時，它將繼續提供來自可用碎片的搜索請求，但你可能須要儘快修復它，由於存在未分配的碎片。

一樣從上面的響應中，咱們能夠看到總共1個節點，而且咱們有0個碎片，由於咱們尚未數據。請注意，因爲咱們使用的是默認羣集名稱（elasticsearch），所以默認狀況下Elasticsearch使用單播網絡發現來查找同一臺計算機上的其餘節點，你可能會意外地在計算機上啓動多個節點並讓它們所有加入單個羣集，在這種狀況下，你可能會在上面的響應中看到多個節點。

咱們還能夠得到羣集中的節點列表，以下所示：

GET /_cat/nodes?v

響應以下：

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           10           5   5    4.46                        mdi      *      PB2SGZY

在這裏，咱們能夠看到一個名爲「PB2SGZY」的節點，它是咱們集羣中當前的單個節點。

列出全部索引

如今讓咱們來看看咱們的索引：

GET /_cat/indices?v

響應以下：

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

這僅僅意味着咱們在集羣中尚未索引。

建立索引

如今讓咱們建立一個名爲「customer」的索引，而後再次列出全部索引：

PUT /customer?pretty
GET /_cat/indices?v

第一個命令使用PUT動詞建立名爲「customer」的索引，咱們只是簡單地追加pretty到結尾，告訴它漂亮地打印JSON響應（若是有的話）。

響應以下：

health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   customer 95SQ4TSUT7mWBT7VNHH67A   5   1          0            0       260b           260b

第二個命令的結果告訴咱們，咱們如今有一個名爲customer的索引，它有5個主碎片和1個副本（默認值），而且它包含0個文檔。

你可能還注意到customer索引標記了yellow運行情況，回想一下咱們以前的討論，yellow表示某些副本未（還沒有）分配。之因此會出現這種狀況，是由於Elasticsearch默認狀況下爲這個索引建立了一個副本，因爲咱們目前只有一個節點在運行，所以在另外一個節點加入集羣的稍後時間點以前，尚沒法分配一個副本（用於高可用性），將該副本分配到第二個節點後，此索引的運行情況將變爲green。

索引和查詢文檔

如今讓咱們在customer索引中加入一些內容，咱們將一個簡單的customer文檔索引到customer索引中，ID爲1，以下所示：

PUT /customer/_doc/1?pretty
{
  "name": "John Doe"
}

響應以下：

{
  "_index" : "customer",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

從上面能夠看出，在customer索引中成功建立了一個新的customer文檔，該文檔的內部標識爲1，咱們在索引時指定。

值得注意的是，Elasticsearch在你將文檔索引以前不須要先顯式建立索引，在前面的示例中，若是customer索引事先還沒有存在，則Elasticsearch將自動建立customer索引。

如今讓咱們檢索剛剛索引的文檔：

GET /customer/_doc/1?pretty

響應以下：

{
  "_index" : "customer",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "found" : true,
  "_source" : { "name": "John Doe" }
}

除了字段以外，這裏沒有什麼不尋常的，found，說明咱們找到了一個請求ID爲1的文檔，另外一個字段_source，它返回咱們從上一步索引的完整JSON文檔。

刪除索引

如今讓咱們刪除剛剛建立的索引，而後再次列出全部索引：

DELETE /customer?pretty
GET /_cat/indices?v

響應以下：

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

這意味着索引已成功刪除，咱們如今回到咱們在集羣中沒有任何內容的地方。

在咱們繼續以前，讓咱們再仔細看看到目前爲止咱們學到的一些API命令：

PUT /customer
PUT /customer/_doc/1
{
  "name": "John Doe"
}
GET /customer/_doc/1
DELETE /customer

若是咱們仔細研究上述命令，咱們實際上能夠看到咱們如何在Elasticsearch中訪問數據的模式，該模式可概括以下：

<REST Verb> /<Index>/<Type>/<ID>

這種REST訪問模式在全部API命令中都很是廣泛，若是你可以簡單地記住它，你將在掌握Elasticsearch方面有一個良好的開端。

---

上一篇：安裝

下一篇：修改你的數據