修改数据 - shuiyuebingdian/ElasticSearch GitHub Wiki
Elasticsearch提供近乎实时的数据处理和搜索功能。默认情况下,从索引/更新/删除数据到显示在搜索结果中的时间可能会有一秒钟的延迟(刷新间隔)。这是与其他平台(如SQL)的重要区别,在其他平台上,数据在事务完成后立即可用。
前面我们已经看到了如何为单个文档建立索引。让我们再次调用该命令:
PUT /customer/external/1?pretty
{
"name": "John Doe"
}
同样,上面的代码会将指定文档索引到ID为1的外部索引客户索引中。如果我们再对另一个(或相同)文档执行上述命令,Elasticsearch将替换(即重新索引)新文档在现有的ID为1的顶部的顶部:
PUT /customer/external/1?pretty
{
"name": "Jane Doe"
}
上面将ID为1的文档的名称从“ John Doe”更改为“ Jane Doe”。另一方面,如果我们使用其他ID,则将为新文档建立索引,而索引中已经存在的现有文档保持不变。
PUT /customer/external/2?pretty
{
"name": "Jane Doe"`
}
上面的代码索引了ID为2的新文档。
编制索引时,ID部分是可选的。如果未指定,Elasticsearch将生成一个随机ID,然后将其用于索引文档。Elasticsearch生成的实际ID(或我们在先前示例中明确指定的ID)将作为索引API调用的一部分返回。
此示例显示了如何为没有显式ID的文档建立索引:
POST /customer/external?pretty
{
"name": "Jane Doe"
}
请注意,在上述情况下,由于未指定ID ,因此我们使用POST代替PUT。
更新文档
除了能够索引和替换文档之外,我们还可以更新文档。请注意,尽管Elasticsearch实际上并未在后台进行原地更新。每当我们进行更新时,Elasticsearch都会删除旧文档,然后在一个快照中将应用了更新的新文档编入索引。
本示例说明如何通过将名称字段更改为“ Jane Doe”来更新我们以前的文档(ID为1):
POST /customer/external/1/_update?pretty
{
"doc": { "name": "Jane Doe" }
}
本示例说明如何通过将名称字段更改为“ Jane Doe”并同时向其添加年龄字段来更新我们之前的文档(ID为1):
POST /customer/external/1/_update?pretty
{
"doc": { "name": "Jane Doe", "age": 20 }
}
也可以使用简单的脚本执行更新。本示例使用脚本将年龄增加5:
POST /customer/external/1/_update?pretty
{
"script" : "ctx._source.age += 5"
}
在上面的示例中,ctx._source指的是将要更新的当前源文档。
请注意,在撰写本文时,一次只能在单个文档上执行更新。将来,Elasticsearch可能会提供给定查询条件(例如一条SQL UPDATE-WHERE语句)来更新多个文档的功能。
删除文档
DELETE /customer/external/2?pretty
请参阅_delete_by_query API以删除与特定查询匹配的所有文档。值得注意的是,删除整个索引比使用Delete By Query API删除所有文档要有效得多。
批量处理
除了能够索引,更新和删除单个文档之外,Elasticsearch还提供了使用_bulkAPI批量执行上述任何操作的功能。此功能很重要,因为它提供了一种非常有效的机制,可以以尽可能少的网络往返次数来尽可能快地执行多项操作。
作为快速示例,以下调用在一个批量操作中为两个文档(ID 1-John Doe和ID 2-Jane Doe)建立了索引:
POST /customer/external/_bulk?pretty
{"index":{"_id":"1"}}
{"name": "John Doe" }
{"index":{"_id":"2"}}
{"name": "Jane Doe" }
本示例在一个批量操作中更新第一个文档(ID为1),然后删除第二个文档(ID为2):
POST /customer/external/_bulk?pretty
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}
上面请注意,对于删除操作,在其后没有相应的源文档,因为删除仅需要删除文档的ID。
批量API不会因其中一项操作失败而失败。如果单个操作由于任何原因而失败,它将继续处理其后的其余操作。批量API返回时,它将为每个操作提供状态(以发送顺序相同),以便您可以检查特定操作是否失败。