目录
集群健康
让我们从一个基本的健康检查开始，我们可以使用它来查看集群的运行情况。我们将使用curl来完成此任务，但是您可以使用任何允许进行HTTP/REST调用的工具。假设我们仍然在启动Elasticsearch并打开另一个命令shell窗口的同一节点上。
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%
每当我们请求集群健康时，我们要么得到green，yellow， red。
- Green - 一切都很好(集群功能齐全)
- Yellow - 所有的数据都是可用的，但是有些副本还没有分配(集群功能齐全)
- Red - 由于某种原因，有些数据不可用(集群具有部分功能)
注意：当集群是红色时，它将继续为可用碎片的搜索请求提供服务，但是您可能需要尽快修复它，因为存在未分配的碎片。
同样，从上面的响应中，我们可以看到总共有1个节点，并且我们有0个碎片，因为我们还没有数据。注意,因为我们使用的是默认集群名称(elasticsearch)和由于elasticsearch使用单播网络发现默认情况下找到其他节点在同一台机器上,这是可能的,你可以不小心启动多个节点在你的电脑上,让他们加入一个集群。在这个场景中，您可能会在上面的响应中看到不止一个节点。
我们还可以得到集群中的节点列表，如下所示：
curl -X GET "localhost:9200/_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”的节点，它是当前集群中的单个节点。
现在我们来看看索引：
curl -X GET "localhost:9200/_cat/indices?v"
响应格式：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
这意味目前我们还没有任何一个索引数据。
创建索引
现在我们创建一个名为customer的索引，然后再列出所有的索引。
curl -X PUT "localhost:9200/customer?pretty"
curl -X GET "localhost:9200/_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个文档。
您可能还会注意到，客户索引有一个黄色的健康标记。回想一下我们之前的讨论，黄色表示一些副本尚未分配。之所以会出现这种情况，是因为Elasticsearch默认为索引创建了一个副本。因为我们现在只有一个节点在运行，所以在另一个节点加入集群之后，才能分配一个副本(为了高可用性)。一旦将副本分配到第二个节点上，该索引的健康状态将变为绿色。
索引并且查询一个文档
现在让我们放一些东西到我们的customer索引。我们将把一个简单的客户文档索引到客户索引中，ID为1，如下所示:
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d '{"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索引中创建。文档还有一个内部id 1，我们在索引时指定了它。
需要注意的是，Elasticsearch并不要求您首先显式地创建索引，然后才能将文档编入索引。在前面的示例中，如果事先不存在customer索引，Elasticsearch将自动创建customer索引。
现在让我们检索刚才索引的文档：
curl -X GET "localhost:9200/customer/_doc/1?pretty"
响应格式：
{
"_index" : "customer",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"found" : true,
"_source" : {
"name" : "John Doe"
}
}
这里没有什么特别的，除了一个字段，found，声明我们找到了一个包含请求ID 1和另一个字段_source的文档，该字段返回我们从上一步中索引的完整JSON文档。
删除一个索引
现在让我们删除我们刚刚创建的索引，然后再一次列出所有的索引：
curl -X DELETE "localhost:9200/customer?pretty"
curl -X GET "localhost:9200/_cat/indices?v"
响应格式：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
这意味着索引被成功删除了，现在，我们回到了我们刚启动集群，里面一无所有的地方。
在我们继续之前，让我们再仔细看看我们到目前为止学习的一些API命令:
# 创建索引
curl -X PUT "localhost:9200/customer"
# 往索引里增加一条文档
curl -X PUT "localhost:9200/customer/_doc/1" -H 'Content-Type: application/json' -d' {"name": "John Doe"}'
# 查询索引里的文档
curl -X GET "localhost:9200/customer/_doc/1"
# 删除索引
curl -X DELETE "localhost:9200/customer"
如果我们仔细研究上面的命令，我们实际上可以看到如何在Elasticsearch中访问数据的模式。这种模式可以概括如下:
///
这个REST访问模式在所有API命令中都非常普遍，如果您能够简单地记住它，那么您将在掌握Elasticsearch方面有一个很好的开端。
修改你的数据
Elasticsearch提供几乎实时的数据操作和搜索能力。默认情况下，从索引/更新/删除数据到出现在搜索结果中，您可能会得到一秒钟的延迟(刷新间隔)。这是与其他平台(如SQL)的一个重要区别，SQL在事务完成后，数据立即可用。
索引/替换文档
我们之前已经学习了如何索引一个单一文档，现在让我们复习一下这个命令：
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d '{"name": "John Doe"}'
同样，上面的代码将把指定的文档索引为customer索引，ID为1。如果我们用一个不同（或者相同）的文档再次执行上面的命令， Elasticsearch将在现有文档的基础上替换(即重新索引)一个新文档，ID为1:
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d'
{
"name": "Jane Doe"
}
'
以上将ID为1的文档名称从“John Doe”更改为“Jane Doe”。换句话说，如果我们使用一个不同的ID，一个新的文档将被索引并且在索引里已经存在的文档未被提及。
curl -X PUT "localhost:9200/customer/_doc/2?pretty" -H 'Content-Type: application/json' -d'
{
"name": "Jane Doe"
}
'
以上将索引一个ID为2的新文档。
索引时，文档ID是可选的，如果没有指定，Elasticsearch将生成一个随机ID并且使用它来索引这个文档。实际的ID Elasticsearch生成的值(或者我们在前面的示例中显式指定的值)作为索引API调用的一部分返回。
这个示例展示了如何在没有显式ID的情况下对文档进行索引：
curl -X POST "localhost:9200/customer/_doc?pretty" -H 'Content-Type: application/json' -d'
{
"name": "Jane Doe"
}
'
注意，在上面的例子中，我们使用POST谓词而不是PUT，因为我们没有指定ID。
更新文档
除了能够索引和替换文档外，我们还可以更新文档。不过请注意，Elasticsearch实际上并不会在引擎盖下进行就地更新。无论何时我们做一个更新操作，Elasticsearch将删除旧的文档然后更新后的结果对新文档进行索引。
这个例子展示了如何通过将name字段更改为“Jane Doe”来更新我们以前的文档(ID为1):
curl -X POST "localhost:9200/customer/_doc/1/_update?pretty" -H 'Content-Type: application/json' -d'
{
"doc": { "name": "Jane Doe" }
}
'
这个例子展示了如何通过将name字段更改为“Jane Doe”同时增加一个age字段来更新我们以前的文档(ID为1):
curl -X POST "localhost:9200/customer/_doc/1/_update?pretty" -H 'Content-Type: application/json' -d'
{
"doc": { "name": "Jane Doe", "age": 20 }
}
'
还可以使用简单的脚本执行更新。这个例子使用一个脚本将年龄增加5:
curl -X POST "localhost:9200/customer/_doc/1/_update?pretty" -H 'Content-Type: application/json' -d'
{
"script" : "ctx._source.age += 5"
}
'
在上面的例子中，是ctx._source是指将要更新的当前源文档。
Elasticsearch提供了在给定查询条件(如SQL update - where语句)下更新多个文档的功能。具体请看docs-update-by-query API
删除文档
删除文档相当简单。这个例子展示了如何删除我们以前的一个ID为2的客户文档:
curl -X DELETE "localhost:9200/customer/_doc/2?pretty"
查看_delete_by_query API以删除与特定查询条件相匹配的所有文档。值得注意的是，删除整个索引要比使用Query API删除所有文档高效得多。
批量处理
除了能够索引、更新和删除单个文档之外，Elasticsearch还可以使用_bulk API批量执行上述任何操作。这个功能非常重要，因为它提供了一种非常有效的机制，可以在尽可能少的网络往返的情况下尽可能快地执行多个操作。
作为一个快速示例，以下调用在一个批量操作中索引两个文档(ID 1 - John Doe和ID 2 - Jane Doe):
curl -X POST "localhost:9200/customer/_doc/_bulk?pretty" -H 'Content-Type: application/json' -d'
{"index":{"_id":"1"}}
{"name": "John Doe" }
{"index":{"_id":"2"}}
{"name": "Jane Doe" }
'
这个示例更新第一个文档(ID为1)，然后在一个批量操作中删除第二个文档(ID为2):
curl -X POST "localhost:9200/customer/_doc/_bulk?pretty" -H 'Content-Type: application/json' -d'
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}
'
注意，对于删除操作，在删除之后没有相应的源文档，因为删除只需要删除文档的ID。
批量API不会因为其中一个操作失败而失败。如果一个操作由于任何原因失败，它将继续处理它之后的其余操作。当bulk API返回时，它将为每个操作提供状态(按照发送的顺序)，以便您可以检查某个特定操作是否失败。
探索你的数据
现在我们已经了解了基础知识，让我们尝试处理一个更真实的数据集。