es官网翻译之Exploring Your Cluster

• Exploring Your Cluster

探索你的集群

The rest api

rest 风格的 api

Now that we have our node (and cluster) up and running, the next step is to understand how to

现在 我们已经将我们自己的节点(和集群) 启动并运行着, 下一个步骤是知道如何

communicate with it. Fortunately, Elasticsearch provides a very comprehensive and powerful

和它交流.                  幸运的是,    elatsicsearch 提供了一套非常 全面                  和   能力强大

REST API that you can use to interact with your cluster. Among the few things that can be done

的rest 风格的api   让你可以使用它用来和你的集群交互,  我们可以使用api 做一些事情 如下:

with the API are as follows:

• Check your cluster, node, and index health, status, and statistics
• 检查 你的集群 ，节点，和索引健康度，状态及统计
• Administer your cluster, node, and index data and metadata
•  管理你的集群，节点和索引数据及元数据
• Perform CRUD (Create, Read, Update, and Delete) and search operations against your indexes
• 执行 CRUD(创建，读取，更新 和 删除) 和 针对你的索引进行搜索操作
• Execute advanced search operations such as paging, sorting, filtering, scripting, aggregations, and many others
• 执行高级搜索操作比如 分页，排序，过滤， 脚本执行，聚合，及很多其他的操作

集群健康度

• Cluster Health​​​​​​​​​​​​​

Let’s start with a basic health check, which we can use to see how our cluster is doing. We’ll be

让我们从一个基本的健康检查开始，我们可以用来看下我们的集群的运行情况,      我们可以使用

using curl to do this but you can use any tool that allows you to make HTTP/REST calls. Let’s

curl 来做这个，但是你也可以使用其他任何允许你使用http/rest发起请求的工具,  让我们

assume that we are still on the same node where we started Elasticsearch on and open another

假设 我们仍然在启动es 的节点上 并打开另外一个

command shell window. 

shell命令 窗口

To check the cluster health, we will be using the _cat API. You can run the command below in 

我们将通过使用_cat api 来检查集群的健康情况 。        你可以在 kibana 的控制台通过点击 "VIEW

Kibana’s Console by clicking "VIEW IN CONSOLE" or with curl by clicking the "COPY AS CURL"

IN CONSOLE"执行以下命令， 或者 通过点击 下方的链接 "COPY AS CURL" 并复制到 控制台使

link below and pasting it into a terminal.

用 curl 进行 检查

 And the response:

然后我们可以看到响应:

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%

We can see that our cluster named "elasticsearch" is up with a green status.

我们可以看到我们名叫"elasticsearch"的集群正在以一个绿色的状态运行着

Whenever we ask for the cluster health, we either get green, yellow, or red.

无论啥时候 我们 询问集训健康度 ，我们不就是得到 绿色， 黄色 不就是 红色

• Green - everything is good (cluster is fully functional)
• 绿色，一切正常(集群提供全部功能)
• Yellow - all data is available but some replicas are not yet allocated (cluster is fully functional)
• 黄色 - 所有的数据都可用但是有一部分分片还没被分配(集群功能齐全)
• Red - some data is not available for whatever reason (cluster is partially functional)
• 红色-部分数据由于 某种原因 不可用(集群提供部分功能)

Note: When a cluster is red, it will continue to serve search requests from the available shards

注意: 当集群是红色, 他将继续 从可用的分片提供查询请求服务 ,

but you will likely need to fix it ASAP since there are unassigned shards.

但是你 可能需要尽快修复它 因为 有没有被分配的分片

Also from the above response, we can see a total of 1 node and that we have 0 shards since we

从以上响应，我们也可以看出总共有一个节点 并且我们只有0个分片 因为我们

have no data in it yet. Note that since we are using the default cluster name (elasticsearch) and

还没数据在里面,,,,,    注意因为我们使用默认的集群 名字（elasticsearch） 而且

since Elasticsearch uses unicast network discovery by default to find other nodes on the same

因为  Elasticsearch 默认使用单播 网络发现 用来 发现其他节点在同一个

machine, it is possible that you could accidentally start up more than one node on your computer

机器,       所以有可能你不小心启动了超过一个节点在你的电脑上

and have them all join a single cluster. In this scenario, you may see more than 1 node in the

并且 让他们都加入一个单一集群中。  在这种情况下， 你可以在以上响应中看到超过一个节点

above response.

We can also get a list of nodes in our cluster as follows:

我们也可以像下面一样得到我们集群中的节点列表

并且得到响应:

 Here, we can see our one node named "PB2SGZY", which is the single node that is currently in our cluster.

这里，我们可以看到我们一个名叫"PB2SGZY"的节点， 现在是我们集群中的单个节点

List All Indices

列举所有的索引

Now let’s take a peek at our indices:

现在让我们看一下我们的索引

curl -X GET "localhost:9200/_cat/indices?v&pretty"
And the response:

得到响应

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

Which simply means we have no indices yet in the cluster.

这简单的说明在集群中我们还没有索引

Create an Index

创建一个索引

Now let’s create an index named "customer" and then list all the indexes again:

现在让我们创建一个名叫 customer 的索引并再一次列举所有的索引

curl -X PUT "localhost:9200/customer?pretty&pretty"
curl -X GET "localhost:9200/_cat/indices?v&pretty"

The first command creates the index named "customer" using the PUT verb. We simply append pretty to the end of the call to tell it to pretty-print the JSON response (if any).

第一条命令使用PUT动词 创建名叫"customer"的索引 ，我们只需简单的在调用命令末尾加上"pretty" 让其对JSON响应（如果有的话）进行标准打印

And the response:

得到响应:

health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   customer NCRVamqbSJyA0wirwuomug   5   1          0            0       460b           460b

The results of the second command tells us that we now have 1 index named customer and it has 5 primary shards and 1 replica (the defaults) and it contains 0 documents in it.

第二行命令的结果告诉我们我们现在有一个名叫customer的索引,并且它有5个主分片和一个副本(默认值) 还有这里面包含了0个文档

You might also notice that the customer index has a yellow health tagged to it. Recall from our previous discussion that yellow means that some replicas are not (yet) allocated. The reason this happens for this index is because Elasticsearch by default created one replica for this index. Since we only have one node running at the moment, that one replica cannot yet be allocated (for high availability) until a later point in time when another node joins the cluster. Once that replica gets allocated onto a second node, the health status for this index will turn to green.

你可能也注意到了customer索引上标记了一个黄色的健康状况, 回顾我们之前对黄色的讨论意味着有部分副本(还)没分配,这个索引出现这个情况的原因是因为Elasticsearch默认为这个索引创建一个副本，由于我们此时仅有一个节点在运行，所以在另一个节点加入集群之前 这个副本还不能被分配(为了高可用). 一旦该副本在第二个节点上得到分配，这个索引的健康状态就会转为绿色

Index and Query a Document

索引 并 查询一个文档

Let’s now put something into our customer index. We’ll index a simple customer document into the customer index, with an ID of 1 as follows:

现在让我我们在我们的customer索引中加入一些东西, 我们将在customer索引中索引一个简单的customer文档,ID为1，如下所示

curl -X PUT "localhost:9200/customer/_doc/1?pretty&pretty" -H 'Content-Type: application/json' -d'
{
  "name": "John Doe"
}
'

And the response:

得到响应

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

From the above, we can see that a new customer document was successfully created inside the customer index. The document also has an internal id of 1 which we specified at index time.

从上面的结果，我们可以看到一个新的客户文档被成功创建进customer索引中.这个文档还有一个为1的内部id ,这是我们在创建索引的时候指定的

It is important to note that Elasticsearch does not require you to explicitly create an index first before you can index documents into it. In the previous example, Elasticsearch will automatically create the customer index if it didn’t already exist beforehand.

需要注意的是 Elasticsearch并不要要求你在索引文档进去索引 之前创建对应的索引,在之前的例子中， 如果之前没有已经存在的索引，Elasticsearch将会自动创建customer索引

Let’s now retrieve that document that we just indexed:

现在让我们检索下刚才索引的文档:

curl -X GET "localhost:9200/customer/_doc/1?pretty&pretty"

And the response:

得到响应

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

Nothing out of the ordinary here other than a field, found, stating that we found a document with the requested ID 1 and another field, _source, which returns the full JSON document that we indexed from the previous step.

这里除了一个字段"found" 标识我们找到了请求中id为1的文档 还有另外一个字段"_source"返回我们上一步索引的完整JSON文档 外，其他都没有特别的了.

Delete an Index

删除 一个索引

Now let’s delete the index that we just created and then list all the indexes again:

现在让我们删除我们刚刚创建的索引并再一次列举所有索引

curl -X DELETE "localhost:9200/customer?pretty&pretty"
curl -X GET "localhost:9200/_cat/indices?v&pretty"

And the response:

得到响应

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

Which means that the index was deleted successfully and we are now back to where we started with nothing in our cluster.

这说明索引被成功删除了 并且我们现在回到了一开始集群中没有任何东西的状态

Before we move on, let’s take a closer look again at some of the API commands that we have learned so far:

在继续之前，让我们再仔细看下我们之前已经学过的一些API命令

curl -X PUT "localhost:9200/customer?pretty"
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'
{
  "name": "John Doe"
}
'
curl -X GET "localhost:9200/customer/_doc/1?pretty"
curl -X DELETE "localhost:9200/customer?pretty"

If we study the above commands carefully, we can actually see a pattern of how we access data in Elasticsearch. That pattern can be summarized as follows:

如果我们仔细的学过了以上命令，我们可以看到我们在Elasticsearch中查找数据的一个模式,

该模式可以总结如下

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

This REST access pattern is so pervasive throughout all the API commands that if you can simply remember it, you will have a good head start at mastering Elasticsearch.

这种REST访问模式在所有的API 命令中都很普遍，如果你可以简单地记住它，你将在掌握Elasticsearch过程中有一个良好的开端