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方面有一个良好的开端。

---

上一篇：安装

下一篇：修改你的数据