IT评测·应用市场-qidao123.com技术社区

标题: Elasticsearch——操纵文档API详解 [打印本页]
作者: 自由的羽毛    时间: 2024-9-22 16:08
标题: Elasticsearch——操纵文档API详解
作者简介：各人好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，各人一起学习，一起进步，一起对抗互联网寒冬
  学习必须往深处挖，挖的越深，基础越扎实！
阶段1、深入多线程

阶段2、深入多线程计划模式

阶段3、深入juc源码解析

阶段4、深入jdk别的源码解析

阶段5、深入jvm源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池利用的场景题】
码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】
码哥讲源码-【jvm课程前置知识及c/c++调试情况搭建】
​​​​​​码哥讲源码-原理源码篇【揭秘join方法的叫醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操纵？】
码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】
码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】
终结B站没人能讲清楚红黑树的汗青，不服等你来踢馆！
打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证效果看成最终效果的水货们请闭嘴】
操纵文档


全部CRUD API都是单索引API。index参数接受一个索引名，或 一个指向单个索引的别名(alias)。

单文档API


1、Index API

索引API在特定索引中添加或更新JSON文档，使其可搜刮。
  1.     //4种语法
  2.     PUT /<index>/_doc/<_id>
  3.     POST /<index>/_doc/
  4.     PUT /<index>/_create/<_id>
  5.     POST /<index>/_create/<_id>
复制代码
如果target是data stream，则如果指定ID则不能利用PUT /<target>/_doc/<_id>，应利用PUT /<target>/_create/<_id>
path参数：

query参数：

request body参数：
JSON
response body参数：

下面的示例将ID为1文档插入到twitter索引中:
  1.     PUT twitter/_doc/1
  2.     {
  3.       "user":"kimchy",
  4.       "post_date":"2009-11-15T14:12:12",
  5.       "message":"trying out Elasticsearch"
  6.     }
复制代码
默认情况下，当索引操纵乐成返回时，有大概一些replica 还没有开始或完成，因为只要primary乐成执行，就会返回，这种行 为可以调解。实在这样做的目的是快速相应，一样平常的场景并不需要等 待全部分片都完成索引操纵再返回，除非对数据安全要求极高的场景。

1.1、自动创建索引（action.auto_create_index）

当索引文档时，如果索引不存在，会自动创建索引。索引操纵还 将创建一个动态映射(如果尚未存在)。默认情况下，如果需要，新 字段和对象将自动添加到映射定义中。
自动创建索引由action.auto_create_index设置控制。此设置默 以为true，这意味着索引总是自动创建的。也可以设置只有匹配特定 模式的索引才允许自动创建索引，方法是将此设置的值更改为这些匹 配模式的逗号分隔列表。还可以通过在列表中的模式前面加上+或-， 明确地允许和禁止利用它。最后，通过将此设置更改为false，可以完全禁用它。可以在elasticsearch.yml中设置，也可以通过如下URL 设置。
只允许自动创建名为twitter、index10的索引，不允 许创建其他与index1*匹配的索引：
  1.     PUT _cluster/settings
  2.     {
  3.         "persistent": {
  4.             "action.auto_create_index": "twitter,index10,-index1*,+ind*"
  5.         }
  6.     }
复制代码
完全禁用索引的自动创建：
  1.     PUT _cluster/settings
  2.     {
  3.         "persistent": {
  4.             "action.auto_create_index": "false"
  5.         }
  6.     }
复制代码
允许利用任何名称自动创建索引，这是默认设置:
  1.     PUT _cluster/settings
  2.     {
  3.         "persistent": {
  4.             "action.auto_create_index": "true"
  5.         }
  6.     }
复制代码

1.2、逼迫创建（op_type）

索引操纵还接受一个op_type参数，它可以用来逼迫create操 作，允许put-if-absent的举动。利用create时，如果索引中已存在具有该ID的文档，则索引操纵将失败。
可以这样来明白，当索引文档时，如果带有&op_type=true参 数，明确指明是创建文档，如果文档存在就报错。默认情况下，当文档存在时直接覆盖。
  1.     PUT twitter/_doc/1?op_type=create
  2.     {
  3.       "user":"kimchy",
  4.       "post_date":"2009-11-15T14:12:12",
  5.       "message":"trying out Elasticsearch"
  6.     }
复制代码

1.3、ID自动生成

索引操纵可以在不指定ID的情况下执行。在这种情况下，将自动 生成一个ID。
  1.     POST twitter/_doc
  2.     {
  3.       "user":"kimchy",
  4.       "post_date":"2009-11-15T14:12:12",
  5.       "message":"trying out Elasticsearch"
  6.     }
复制代码

1.4、路由（routing）

默认情况下，数据存放到哪个分片，通过利用文档ID值的哈希值 来控制。对于更显式的控制，可以通报哈希函数的种子值。
  1.     POST twitter/_doc?routing=kimchy
  2.     {
  3.       "user":"kimchy",
  4.       "post_date":"2009-11-15T14:12:12",
  5.       "message":"trying out Elasticsearch"
  6.     }
复制代码
在设置显式mapping时，可以选择利用_routing字段从文档自己 提取路由值。如果定义了mapping的_routing值并将其设置为必须， 则如果没有提供可提取路由值，索引操纵将失败。

1.5、分发

索引操纵根据路由定向到primary，并在包含此分片的实际节点 上执行。在primary完成操纵后，如果需要，操纵将分发到需要的其他分片。

1.6、超时（time）

执行索引操纵时，分配用于执行索引操纵的主碎片大概不可用。出现这种情况的一些原因大概是主碎片当前正在从网关恢复或正在举行重新定位。默认情况下，索引操纵将在主碎片上等候长达1分钟，然后失败并返回错误。timeout参数可用于明确指定等候时间。
  1.     PUT twitter/_doc/1?timeout=5m
  2.     {
  3.         "user" : "kimchy",
  4.         "post_date" : "2009-11-15T14:12:12",
  5.         "message" : "trying out Elasticsearch"
  6.     }
复制代码

1.7、等候运动分片

为了兼顾系统写入的效率和可靠性，可以将索引操纵设置为在继 续操纵之前等候一定命量的运动分片。如果所需数目的运动分片不可 用，则写入操纵必须等候并重试，直到所需分片已启动或发生超时。 默认情况下，写入操纵仅在继续之前等候primary完成(即 wait_for_active_shards=1) 。 可 以 通 过 设 置 index.write.wait_for_active_shards 来 动 态 重 写 此 默 认 值 。 要 更 改 每个哀求操纵的此举动，可以利用wait_for_active_shards哀求参 数。
wait_for_active_shards的有效值是任何正整数，最多为分片总 数。指定负值或大于分片数的数字将引发错误。
例如，假设有一个由3个节点(A、B和C)构成的集群，而且创 建了一个索引index，其中副本数设置为3(效果是共4个分片)。如 果我们尝试索引操纵，默认情况下，该操纵将仅确保primary在继续 操纵之前可用。这意味着，纵然B和C发生故障，而且A托管了 primary ， 索 引 操 作 仍 然 继 续 进 行 。 如 果 在 请 求 中 将 wait_for_active_shards设置为3(而且全部3个节点都已启动)，那 么索引操纵将需要3个运动的shard副本才能继续。这一要求应该满 足，因为集群中有3个运动的节点，每个节点都保存一个shard副本。 但是，如果我们将wait_for_active_shards设置为all(或设置为4， 这是相同的)，则索引操纵将不会继续，因为索引中没有每个shard 的全部4个副本。除非在集群中出现新节点以承载分片的第四副本， 否则操纵将超时。

1.8、detect——noop参数

利用索引API更新文档时，纵然文档没有更改，也会始终创建文 档的新版本。如果不想这样做，可以利用detect_noop=true参数。这 个参数的作用是在更新之前与原文档对比，如果没有字段值的变化， 则不做更新操纵。

2、Get API

GET API允许根据其ID从索引中获取JSON文档。
  1.     //获取整个文档
  2.     GET <index>/_doc/<_id>
  3.    
  4.     //只获取_source部分
  5.     GET <index>/_source/<_id>
  6.    
  7.     //检测文档是否存在
  8.     HEAD <index>/_doc/<_id>
  9.     HEAD <index>/_source/<_id>
复制代码
path参数：

query参数：

response body参数：

  1.     GET twitter/_doc/1
  2.    
  3.     //返回
  4.     {
  5.       "_index" : "twitter",
  6.       "_type" : "_doc",
  7.       "_id" : "1",
  8.       "_version" : 2,
  9.       "_seq_no" : 1,
  10.       "_primary_term" : 1,
  11.       "found" : true,
  12.       "_source" : {
  13.         "user" : "kimchy",
  14.         "post_date" : "2009-11-15T14:12:12",
  15.         "message" : "trying out Elasticsearch"
  16.       }
  17.     }
  18.    
  19.    
  20.     GET twitter/_source/1
  21.    
  22.     //返回
  23.     {
  24.       "user" : "kimchy",
  25.       "post_date" : "2009-11-15T14:12:12",
  26.       "message" : "trying out Elasticsearch"
  27.     }
复制代码

2.1、实时性（realtime）

默认情况下，GET API是实时的，不受索引革新频率的影响。如 果文档已更新但尚未革新，则GET API将在适当时机发出革新调用， 以使文档可见。这还将使前次革新后更改的其他文档可见。如果需要 禁用此特性，可以将realtime参数设置为false。
  1.     GET twitter/_doc/1?realtime=false
复制代码

2.2、字段选择（_source）

默认情况下，GET API操纵返回_source的内容，除非利用了 stored_fields参数或禁用了_source。可以关闭_source检索，如下 所示:
  1.     GET twitter/_doc/1?_source=false
  2.     //返回
  3.     {
  4.       "_index" : "twitter",
  5.       "_type" : "_doc",
  6.       "_id" : "1",
  7.       "_version" : 2,
  8.       "_seq_no" : 1,
  9.       "_primary_term" : 1,
  10.       "found" : true
  11.     }
复制代码
如果只需要完整_source中的一个或两个字段，可以利用 _source_includes和_source_excludes参数来包含或清除字段。这 对于大型文档尤其有效，因为部分字段检索可以节省网络开销。两个 参数都采用逗号分隔的字段列表或通配符表达式。
  1.     GET twitter/_doc/0? _source_includes=*.id&_source_excludes=entities
复制代码
如果只需指定include，可以利用较短的表现法:
  1.     GET twitter/_doc/0?_source=*.id,retweeted
复制代码

2.3、存储字段（stored_fields）

GET操纵允许指定一组存储字段(store属性值为true)，这些 字段将通过通报stored_fields参数返回。如果未存储哀求的字段，则 将忽略它们。
  1.     PUT twitter
  2.     {
  3.       "mappings": {
  4.         "properties": {
  5.           "counter": {
  6.             "type": "integer",
  7.             "store": false
  8.           },
  9.           "tags": {
  10.             "type": "keyword",
  11.             "store": true
  12.           }
  13.         }
  14.       }
  15.     }
  16.    
  17.     PUT twitter/_doc/1
  18.     {
  19.       "counter":1,
  20.       "tags":["red"]
  21.     }
  22.    
  23.     GET twitter/_doc/1?stored_fields=tags,counter
  24.    
  25.     //返回
  26.     {
  27.       "_index" : "twitter",
  28.       "_type" : "_doc",
  29.       "_id" : "1",
  30.       "_version" : 1,
  31.       "_seq_no" : 0,
  32.       "_primary_term" : 1,
  33.       "found" : true,
  34.       "fields" : {
  35.         "tags" : [
  36.           "red"
  37.         ]
  38.       }
  39.     }
复制代码
此外，只有叶字段可以通过stored_field选项返回，不能返回对 象字段，这样的哀求将失败。

2.4、路由（routing）

如果在索引文档时利用了路由参数，搜刮时也应该加上该参数。 当然搜刮时不加也是可以的，这会降低性能。
  1.     GET twitter/_doc/2?routing=user1
复制代码

2.5、preference参数

preference参数的作用是控制优先从哪个shard获取数据。默认 情况下是随机选择的。一样平常情况下可以设置为_local，这可以降低网 络开销。
  1.     GET twitter/_doc/1?preference=_local
复制代码

2.6、refresh参数

可以将refresh参数设置为true，以便在GET操纵之前革新相关 的分片并使其可见。将其设置为true应慎重考虑，因为这大概导致系 统负载过重，并减慢索引速度。
  1.     GET twitter/_doc/1?refresh
复制代码

2.7、分发

GET操纵被散列到一个特定的分片ID上，然后被重定向到该分片 ID对应的一个副本，并返回效果。副本是主分片及其在该分片ID上的 副本。这意味着拥有的副本越多，将拥有更好的扩展能力。

2.8、版本支持（version）

只有当文档的当前版本即是指定版本时，才能利用version参数来 检索文档(当然不即是也不要紧，只是检索不到数据罢了)。对于所 有版本类型，此举动都相同。
在内部，Elasticsearch将旧文档标记为已删除，并添加了一个 全新的文档。旧版本的文档不会立即消失，尽管无法访问它。 Elasticsearch将采用一定的策略在后台清除被删除的文档。
  1.     GET twitter/_doc/1?version=1
复制代码

3、Delete API

删除API(DELETE)允许根据特定文档的ID从其中删除JSON 文档。
  1.     //语法
  2.     DELETE /<index>/_doc/<_id>
复制代码
path参数：

query参数：

  1.     DELETE /twitter/_doc/1
  2.    
  3.     //返回
  4.     {
  5.       "_index" : "twitter",
  6.       "_type" : "_doc",
  7.       "_id" : "1",
  8.       "_version" : 2,
  9.       "result" : "deleted",
  10.       "_shards" : {
  11.         "total" : 2,
  12.         "successful" : 1,
  13.         "failed" : 0
  14.       },
  15.       "_seq_no" : 1,
  16.       "_primary_term" : 1
  17.     }
复制代码

3.1、路由（routing）

如果在索引文档时利用了路由参数，删除时也应该加上该参数。
  1.     DELETE twitter/_doc/1?routing=user1
复制代码

4、Update API

更新API(_update)允许根据提供的脚本更新文档。该操纵从 索引中获取文档，运行脚本(利用可选的脚本语言和参数)，并对结 果举行索引(还允许删除或忽略该操纵)。它利用版本控制来确保在 Get和Reindex操纵期间没有发生任何更新。
此操纵仍然意味着文档的完全重新索引，它只是减少了一些网络 往返，并减少Get和Reindex操纵之间版本冲突的大概性。需要启用 _source才能利用此功能。
  1.     //语法
  2.     POST /<index>/_update/<_id>
复制代码
path参数：

query参数：

现在创建一个简单的索引，后续将利用此索引:
  1.     PUT test/_doc/1
  2.     {
  3.         "counter": 1,
  4.         "tags": ["red"]
  5.     }
复制代码

4.1、利用script更新

执行一个脚本来增长计数器(counter)字段的值:
  1.     POST test/_update/1
  2.     {
  3.       "script": {
  4.         "lang": "painless",
  5.         "source": "ctx._source.counter += params.count",
  6.         "params": {
  7.           "count": 4
  8.         }
  9.       }
  10.     }
复制代码
向标签列表(tags)字段中添加标签(如果标签存在，它仍 然会被添加，因为这是一个列表):
  1.     POST test/_update/1
  2.     {
  3.       "script": {
  4.         "lang": "painless",
  5.         "source": "ctx._source.tags.add(params.tag)",
  6.         "params": {
  7.           "tag": "blue"
  8.         }
  9.       }
  10.     }
复制代码
可以从标签列表中删除一个标签。删除标记的painless函数将要 移除的元素的数组索引作为其参数，因此在避免运行时错误的同时， 需要更多的逻辑来定位它。如果标记在列表中出现多次，则只会删除其中一次:
  1.     POST test/_update/1
  2.     {
  3.         "script" : {
  4.             "source": "if (ctx._source.tags.contains(params.tag)) { ctx._source.tags.remove(ctx._source.tags.indexOf(params.tag)) }",
  5.             "lang": "painless",
  6.             "params" : {
  7.                 "tag" : "blue"
  8.             }
  9.         }
  10.     }
复制代码
除了_source外，还可以通过ctx映射获得以下变量:_index、 _type、_id、_version、_routing和_now(当前时间戳)。
还可以在文档中添加一个新字段:
  1.     POST test/_update/1
  2.     {
  3.         "script" : "ctx._source.new_field = 'value_of_new_field'"
  4.     }
复制代码
或从文档中删除字段:
  1.     POST test/_update/1
  2.     {
  3.         "script" : "ctx._source.remove('new_field')"
  4.     }
复制代码
而且，乃至可以动态地执行更改操纵。如果标记字段包含 green，则此示例将删除文档，否则将不执行任何操纵(noop):
  1.     POST test/_update/1
  2.     {
  3.         "script" : {
  4.             "source": "if (ctx._source.tags.contains(params.tag)) { ctx.op = 'delete' } else { ctx.op = 'none' }",
  5.             "lang": "painless",
  6.             "params" : {
  7.                 "tag" : "green"
  8.             }
  9.         }
  10.     }
复制代码

4.2、部分字段更新

更新API还支持通报部分文档字段举行更新，在内部完成合并 (简单的递归合并、对象的内部合并、更换核心“键值”和数组)。 要完全更换现有文档，应利用索引API。
  1.     POST test/_update/1
  2.     {
  3.       "doc": {
  4.         "counter": 111
  5.       }
  6.     }
复制代码
通过部分更新机 制将现有文档添加新字段:
  1.     POST test/_update/1
  2.     {
  3.         "doc" : {
  4.             "name" : "new_name"
  5.         }
  6.     }
复制代码

4.3、避免无效更新

如果指定了doc，则其值将与现有的_source合并。默认情况下， 不更改任何内容的更新并不会真正执行并返回"result":“noop”，实 例如下:
  1.     POST test/_update/1
  2.     {
  3.         "doc" : {
  4.             "name" : "new_name"
  5.         }
  6.     }
复制代码
因为传入的name值和source中的一样，则忽略整个更新哀求。 如果哀求被忽略，相应中的result元素将返回noop。
  1.     {
  2.       "_index" : "test",
  3.       "_type" : "_doc",
  4.       "_id" : "1",
  5.       "_version" : 8,
  6.       "result" : "noop",
  7.       "_shards" : {
  8.         "total" : 0,
  9.         "successful" : 0,
  10.         "failed" : 0
  11.       },
  12.       "_seq_no" : 7,
  13.       "_primary_term" : 1
  14.     }
复制代码
可以通过设置"detect_noop":false来禁用此举动。
  1.     POST test/_update/1
  2.     {
  3.         "doc" : {
  4.             "name" : "new_name"
  5.         },
  6.         "detect_noop": false
  7.     }
复制代码

4.4、upsert元素

如果文档不存在，则upsert元素的内容将作为新文档插入。如果 文档确实存在，则将执行script:
  1.     POST test/_update/1
  2.     {
  3.         "script" : {
  4.             "source": "ctx._source.counter += params.count",
  5.             "lang": "painless",
  6.             "params" : {
  7.                 "count" : 4
  8.             }
  9.         },
  10.         "upsert" : {
  11.             "counter" : 1
  12.         }
  13.     }
复制代码

4.5、scripted_upsert参数

如果不管文档是否存在都盼望运行脚本，即脚本处理初始化文 档，而不是upsert元素，可以将脚本scripted_upsert设置为true:
  1.     POST test/_update/1
  2.     {
  3.         "scripted_upsert": true,
  4.         "script" : {
  5.             "source": "ctx._source.counter += params.count",
  6.             "lang": "painless",
  7.             "params" : {
  8.                 "count" : 4
  9.             }
  10.         },
  11.         "upsert" : {
  12.             "counter" : 1
  13.         }
  14.     }
复制代码

4.6、doc_as_upsert参数

将doc_as_upsert设为true，会利用doc的内容作为upsert值， 而不是发送部分doc加上upsert，示例如下:
  1.     POST test/_update/1
  2.     {
  3.         "doc" : {
  4.             "name" : "new_name"
  5.         },
  6.         "doc_as_upsert" : true
  7.     }
复制代码

多文档API


5、Multi Get API

MGet API(_mget)基于单个索引、类型(可选)和ID(大概 还有路由)返回多个文档。相应包括一个docs数组，其中包含与原始 _mget哀求相对应的全部已提取文档(如果特定Get失败，则在相应 中包含此错误的对象)。乐成的Get的布局与Get API提供的文档在结 构上雷同。
  1.     //语法
  2.     GET /_mget
  3.     GET /<index>/_mget
复制代码
path参数：

query参数：
-preference：(Optional, string) 指定在哪个node或shard上执行，默认随机.

request body：

response body：

示例如下:
  1.     GET /_mget
  2.     {
  3.       "docs" : [
  4.         {
  5.           "_index" : "test",
  6.           "_id" : "1"
  7.         },
  8.         {
  9.           "_index" : "test",
  10.           "_id" : "2"
  11.         }
  12.       ]
  13.     }
复制代码
_mget哀求也可以用于指定索引(在这种情况下，主体中不需要 它):
  1.     GET /test/_mget
  2.     {
  3.       "docs" : [
  4.         {
  5.           "_id" : "1"
  6.         },
  7.         {
  8.           "_id" : "2"
  9.         }
  10.       ]
  11.     }
复制代码
在这种情况下，可以直接利用ids元向来简化哀求:
  1.     GET /test/_mget
  2.     {
  3.         "ids" : ["1", "2"]
  4.     }
复制代码

5.1、_source过滤

默认情况下，将为每个文档返回_source字段(如果已存储)。 与Get API雷同，可以利用_source参数仅检索_source的部分内容 ( 或 者 根 本 不 检 索 ) ， 还 可 以 使 用 URL 参 数 _source 、 _source_includes和_source_excludes指定默认值。
  1.     GET /_mget
  2.     {
  3.         "docs" : [
  4.             {
  5.                 "_index" : "test",
  6.                 "_type" : "_doc",
  7.                 "_id" : "1",
  8.                 "_source" : false
  9.             },
  10.             {
  11.                 "_index" : "test",
  12.                 "_type" : "_doc",
  13.                 "_id" : "2",
  14.                 "_source" : ["field3", "field4"]
  15.             },
  16.             {
  17.                 "_index" : "test",
  18.                 "_type" : "_doc",
  19.                 "_id" : "3",
  20.                 "_source" : {
  21.                     "include": ["user"],
  22.                     "exclude": ["user.location"]
  23.                 }
  24.             }
  25.         ]
  26.     }
复制代码

5.2、stored_fields存储字段

可以为每个要获取的文档指定检索特定存储字段(store属性为 true)，雷同于Get API的stored_fields参数。
  1.     GET /_mget
  2.     {
  3.         "docs" : [
  4.             {
  5.                 "_index" : "test",
  6.                 "_type" : "_doc",
  7.                 "_id" : "1",
  8.                 "stored_fields" : ["field1", "field2"]
  9.             },
  10.             {
  11.                 "_index" : "test",
  12.                 "_type" : "_doc",
  13.                 "_id" : "2",
  14.                 "stored_fields" : ["field3", "field4"]
  15.             }
  16.         ]
  17.     }
复制代码
大概，可以在查询字符串中指定stored_fields参数作为默认值， 应用于全部文档:
  1.     GET /test/_doc/_mget?stored_fields=field1,field2
  2.     {
  3.         "docs" : [
  4.             {
  5.                 "_id" : "1"
  6.             },
  7.             {
  8.                 "_id" : "2",
  9.                 "stored_fields" : ["field3", "field4"]
  10.             }
  11.         ]
  12.     }
复制代码

5.3、routing路由

可以将路由值作为参数:
  1.     GET /_mget?routing=key1
  2.     {
  3.         "docs" : [
  4.             {
  5.                 "_index" : "test",
  6.                 "_type" : "_doc",
  7.                 "_id" : "1",
  8.                 "routing" : "key2"
  9.             },
  10.             {
  11.                 "_index" : "test",
  12.                 "_type" : "_doc",
  13.                 "_id" : "2"
  14.             }
  15.         ]
  16.     }
复制代码
在上面的例子中，文档test/_doc/2将从路由键key1对应的分片 中获取，而文档test/_doc/1将从路由键key2对应的分片中提取，因 为test/_doc/2没有单独指定路由。

6、Bulk API

批量操纵API(_bulk)可以在单个API调用中执行多个索引和删 除操纵。这可以大大提高索引速度。
  1.     //语法
  2.     POST /_bulk
  3.     POST /<index>/_bulk
复制代码
path参数：

query参数：

request body：

response body：
bulk API的相应包含哀求中每个操纵的单独效果，并以提交的顺序返回。单个操纵的乐成或失败不会影响哀求中的其他操纵。为了确保快速相应，如果一个或多个shard失败，bulk API将相应部分效果。

REST API结点是/_bulk，它需要以下以新行分隔的 JSON(ndjson)布局:
  1.     action_and_meta_data\n
  2.     optional_source\n
  3.     action_and_meta_data\n
  4.     optional_source\n
  5.     ....
  6.     action_and_meta_data\n
  7.     optional_source\n
复制代码
  注意:最后一行数据必须以换行符(\n)结尾。每个换行符前面 都可以有一个回车符\r。向此结点发送哀求时，Content-Type应设置为application/x-ndjson。
  大概的操纵包括Index、Create、Delete和Update。Index和 Create需要下一行有一个源，而且与标准索引API的op_type参数具有相同的语义(即，如果已经存在具有相同索引的文档，则Create操纵将失败，而Index操纵将根据需要添加或更换文档)。但Delete操 作不需要在下面的行中有一个源，它与标准的Delete API具有相同的语义。Update要求在下一行指定分部文档、upsert和脚本及其选项。
如果要为Curl提供文本文件输入，则必须利用--data-binary标 志而不是-d，后者不保留换行符。如下示例:
  1.     $ cat requests
  2.     { "index" : { "_index" : "test", "_id" : "1" } }
  3.     { "field1" : "value1" }
  4.    
  5.     $ curl -s -H "Content-Type: application/x-ndjson" -XPOST localhost:9200/_bulk --data-binary "@requests"; echo
  6.     {"took":7, "errors": false, "items":[{"index":{"_index":"test","_type":"_doc","_id":"1","_version":1,"result":"created","forced_refresh":false}}]}
复制代码
以下是精确的批量下令序列示例:
  1.     POST _bulk
  2.     { "index" : { "_index" : "test", "_id" : "1" } }
  3.     { "field1" : "value1" }
  4.     { "delete" : { "_index" : "test", "_id" : "2" } }
  5.     { "create" : { "_index" : "test", "_id" : "3" } }
  6.     { "field1" : "value3" }
  7.     { "update" : {"_id" : "1", "_index" : "test"} }
  8.     { "doc" : {"field2" : "value2"} }
复制代码
节点是/_bulk，它和/{index}/_bulk的区别是，提供索引index 后，默认情况下，它将用于未显式提供索引的批量项目。
格式在这里分析，这里的想法是让处理过程尽大概快。由于某些 操纵将被重定向到其他节点上的其他分片，因此只有 action_meta_data是确定在接受节点处理的。
对批量操纵的相应是一个大型JSON布局，每个操纵的单独效果 按照与哀求中表现的操纵相同的顺序执行。单个操纵的失败不会影响 别的操纵。
在单个批量调用中没有一个绝对合适的批操纵大小数字，应该使 用不同的设置举行试验，以找到适合特定工作负载的最佳大小。
如果利用HTTP API，请确保客户端不发送HTTP块，因为这样会 减慢速度。

6.1、路由

每个批量项目都可以利用routing字段通报路由值。它会根据 _routing映射自动跟踪索引和删除操纵的举动。

6.2、更新

当利用更新操纵时，retry_on_conflict可以用作操纵自己(不在 额外的有效负载行中)中的字段，以指定在发生版本冲突时应重试更 新的次数。
Update操纵支持以下选项:doc(部分文档)、upsert、 doc_as_upsert、script、params(用于脚本)、lang(用于脚本) 和_source。更新操纵示例如下:
  1.     POST _bulk
  2.     { "update" : {"_id" : "1", "_index" : "index1", "retry_on_conflict" : 3} }
  3.     { "doc" : {"field" : "value"} }
  4.     { "update" : { "_id" : "0", "_index" : "index1", "retry_on_conflict" : 3} }
  5.     { "script" : { "source": "ctx._source.counter += params.param1", "lang" : "painless", "params" : {"param1" : 1}}, "upsert" : {"counter" : 1}}
  6.     { "update" : {"_id" : "2", "_index" : "index1", "retry_on_conflict" : 3} }
  7.     { "doc" : {"field" : "value"}, "doc_as_upsert" : true }
  8.     { "update" : {"_id" : "3", "_index" : "index1", "_source" : true} }
  9.     { "doc" : {"field" : "value"} }
  10.     { "update" : {"_id" : "4", "_index" : "index1"} }
  11.     { "doc" : {"field" : "value"}, "_source": true}
复制代码

7、Delete By Query API

查询删除API(_delete_by_query)是对每个与查询匹配的文档 执行删除操纵。
  1.     //语法
  2.     POST /<index>/_delete_by_query
复制代码
条件可以利用Search API 在query参数和body参数中。
path参数：

query参数：

request body：

response body：

示例：
  1.     POST /twitter/_delete_by_query
  2.     {
  3.       "query": {
  4.         "match": {
  5.           "message": "some message"
  6.         }
  7.       }
  8.     }
  9.    
  10.     POST /twitter,blog/_delete_by_query
  11.     {
  12.       "query": {
  13.         "match_all": {}
  14.       }
  15.     }
复制代码
_delete_by_query操纵在启动时会获取索引的一个快照，并利用 内部版本控制删除找到的内容。这意味着，如果文档在获取快照的时 间和处理删除哀求的时间之间发生更改，则会出现版本冲突，如图所示。当版本匹配时，文档将被删除。

在_delete_by_query执行期间，将按顺序执行多个搜刮哀求，以 查找全部要删除的匹配文档。每当找到一批文档时，都会执行相应的 批量哀求来删除全部这些文档。如果搜刮或批量哀求被拒绝， _delete_by_query按照默认策略重试被拒绝的哀求(最多10次，指数下降)。到达最大重试次数限定会导致_delete_by_query中止，并在 相应的failures中返回全部失败信息。已执行的删除操纵仍然保持不变。换句话说，操纵不会回滚，只会中止。当第一个失败导致中止时，由失败的批量哀求返回的全部失败信息都会在failures元素中返回，因此，大概会有相当多失败的实体。
如果不想因版本冲突而让它们中止，那么在URL上设置 conflicts=proceed或在哀求正文中设置conflicts:proceed。
  1.     POST /test/_delete_by_query?conflicts=proceed
  2.     {
  3.       "query": {
  4.         "match_all": {}
  5.       }
  6.     }
复制代码
如果提供了routing，则路由将复制到滚动(scroll)查询中，并 将操纵限定在与该路由值匹配的分片上，如下示例:
  1.     POST twitter/_delete_by_query?routing=1
  2.     {
  3.       "query": {
  4.         "range" : {
  5.             "age" : {
  6.                "gte" : 10
  7.             }
  8.         }
  9.       }
  10.     }
复制代码
默认情况下，_delete_by_query查询利用的滚动批次大小为 1000。可以利用scroll_size参数更改批次大小:
  1.     POST twitter/_delete_by_query?scroll_size=5000
  2.     {
  3.       "query": {
  4.         "term": {
  5.           "user": "kimchy"
  6.         }
  7.       }
  8.     }
复制代码

7.1、URL参数

除了标准参数(如pretty)外，_delete_by_query API还支持：

发送带有refresh参数的哀求，将在哀求完成后革新涉及的全部分 片。这与DELETE API的refresh参数不同，后者只会革新接收到删 除哀求的分片。同时，它不支持wait_for参数。
如 果 请 求 包 含 wait_for_completion=false 设 置 ， 那 么 Elasticsearch将执行一些预检查。启动哀求，然后返回一个Task以 取 消 或 获 取 任 务 的 状 态 。 Elasticsearch 还 将 在.tasks/task/${taskId}索引中创建此使命的记录文档，用户可以根 据需要保留或删除创建的文档，完成后删除它。这样Elasticsearch 可以采取它利用的空间。
wait_for_active_shards参数用来控制在继续执行哀求之前必须 激活多少个分片或副本。timeout参数用来控制每个写哀求等候不可 用分片变为可用的时间。这两个参数在批量API中的工作方式完全相 同。由于_delete_by_query利用scroll搜刮，还可以指定scroll参数 来控制“搜刮上下文”保持运动的时间，例如scroll=10m。默以为5 分钟。
requests_per_second参数可以设置为任何正十进制数(1.4、 6、1000等)，并通过用等候时间填充每个批来限定通过查询发出删 除操纵批的速率。通过将requests_per_second设置为-1，可以禁用 限定。此限定是通过在批之间等候来完成的，这样就可以为 _delete_by_query内部利用的滚动指定一个超时时间。这个时间是批 处理大小除以requests_per_second与写入时间之差。默认情况下， 批处理大小为1000，因此如果requests_per_second设置为500，计 算方式如下:
  1.     target_time = 1000 / 500 per second = 2 seconds
  2.     wait_time = target_time - write_time = 2 seconds -.5 seconds = 1.5 seconds
复制代码
由于该操纵是作为单个_bulk哀求发出的，因此较大的批大小将 导致Elasticsearch创建多个哀求，并在启动下一个操纵之前等候一 段时间，这是不平稳的。默认值为-1。

7.2、返回体

  1.     {
  2.             "took":147,
  3.             "timed_out":false,
  4.             "total":119,
  5.             "deleted":119,
  6.             "batches":1,
  7.             "version_conflicts":0,
  8.             "noops":0,
  9.             "retries":{
  10.                     "bulk":0,
  11.                     "search":0
  12.             },
  13.             "throttled_millis":0,
  14.             "requests_per_second":-1.0,
  15.             "throttled_until_millis":0,
  16.             "failures":[]
  17.     }
复制代码


7.3、使命API（_tasks）

可 以 使 用 任 务 API ( _tasks ) 获 取 任 何 正 在 运 行 的 _delete_by_query的状态:
  1.     GET _tasks?detailed=true&actions=*/delete/byquery
复制代码
返回：
  1.     {
  2.       "nodes" : {
  3.         "r1A2WoRbTwKZ516z6NEs5A" : {
  4.           "name" : "r1A2WoR",
  5.           "transport_address" : "127.0.0.1:9300",
  6.           "host" : "127.0.0.1",
  7.           "ip" : "127.0.0.1:9300",
  8.           "attributes" : {
  9.             "testattr" : "test",
  10.             "portsfile" : "true"
  11.           },
  12.           "tasks" : {
  13.             "r1A2WoRbTwKZ516z6NEs5A:36619" : {
  14.               "node" : "r1A2WoRbTwKZ516z6NEs5A",
  15.               "id" : 36619,
  16.               "type" : "transport",
  17.               "action" : "indices:data/write/delete/byquery",
  18.               "status" : {   
  19.                 "total" : 6154,
  20.                 "updated" : 0,
  21.                 "created" : 0,
  22.                 "deleted" : 3500,
  23.                 "batches" : 36,
  24.                 "version_conflicts" : 0,
  25.                 "noops" : 0,
  26.                 "retries": 0,
  27.                 "throttled_millis": 0
  28.               },
  29.               "description" : ""
  30.             }
  31.           }
  32.         }
  33.       }
  34.     }
复制代码
上述返回效果中的status字段，包含使命的实际状态。total字段 是重新索引预期执行的操纵总数。可以通过updated、created和 deleted的字段的加总值来估计进度。当它们的总和即是合计字段时， 哀求将完成。
利用使命ID，可以直接查找使命:
  1.     GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619
复制代码
此API的优点是，它可以与wait_for_completion=false一起使 用，以透明地返回已完成使命的状态。如果使命已完成，而且在其上 设置了wait_for_completion=false，那么它将返回results或error字 段。此功能的成本是创建的新的文档，需要手动来删除创建的文档。

7.4、取消使命API（_cancel）

可以利用取消使命API(_cancel)取消_delete_by_query进程:
  1.     POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel
复制代码
可以利用使命API找到使命ID。
取消应该很快发生，但大概需要几秒钟。上面的使命状态API将 继续列出相应的使命，直到该使命检查它是否已被取消并自行停止。

7.5、动态调解API

requests_per_second 的 值 可 以 在 运 行 时 使 用 动 态 调 整 API(_rethrottle)举行更改:
  1.     POST _delete_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1
复制代码
就像在_delete_by_query API上设置它一样， requests_per_second可以置为-1以禁用限定，也可以是任何十进制数(如1.7或12)以限定到该级别。加快查询速度的重新标记将立即 生效，但减慢查询速度的重新标记将在完成当前批处理后生效。这样 可以防止滚动超时。

7.6、切片

_delete_by_query API支持切片滚动，使删除过程并行。这种并 行化可以提高效率，并提供一种方便的方法将哀求分解为较小的部 分。
7.6.1、人工切片

通过为每个哀求提供一个切片ID和切片总数，举行人工切片:
  1.     POST twitter/_delete_by_query
  2.     {
  3.       "slice": {
  4.         "id": 0,
  5.         "max": 2
  6.       },
  7.       "query": {
  8.         "range": {
  9.           "likes": {
  10.             "lt": 10
  11.           }
  12.         }
  13.       }
  14.     }
  15.     POST twitter/_delete_by_query
  16.     {
  17.       "slice": {
  18.         "id": 1,
  19.         "max": 2
  20.       },
  21.       "query": {
  22.         "range": {
  23.           "likes": {
  24.             "lt": 10
  25.           }
  26.         }
  27.       }
  28.     }
复制代码
可以通过如下URL验证其是否生效:
  1.     GET _refresh
  2.     POST twitter/_search?size=0&filter_path=hits.total
  3.     {
  4.       "query": {
  5.         "range": {
  6.           "likes": {
  7.             "lt": 10
  8.           }
  9.         }
  10.       }
  11.     }
  12.    
  13.     //返回
  14.     {
  15.       "hits": {
  16.         "total" : {
  17.             "value": 0,
  18.             "relation": "eq"
  19.         }
  20.       }
  21.     }
复制代码
7.6.2、自动切片

可以让_delete_by_query过程自动并行化，方法是利用“切片滚 动”机制对_id举行切片。利用slices指定要利用的切片数:
  1.     POST twitter/_delete_by_query?refresh&slices=5
  2.     {
  3.       "query": {
  4.         "range": {
  5.           "likes": {
  6.             "lt": 10
  7.           }
  8.         }
  9.       }
  10.     }
复制代码
可以通过如下URL验证是否生效:
  1.     POST twitter/_search?size=0&filter_path=hits.total
  2.     {
  3.       "query": {
  4.         "range": {
  5.           "likes": {
  6.             "lt": 10
  7.           }
  8.         }
  9.       }
  10.     }
  11.    
  12.     //返回
  13.     {
  14.       "hits": {
  15.         "total" : {
  16.             "value": 0,
  17.             "relation": "eq"
  18.         }
  19.       }
  20.     }
复制代码
把slices设置为auto将允许Elasticsearch选择要利用的切片数。 此设置将会为每个分片利用一个切片，直至到达某个限定。如果存在 多个源索引，它将根据具有最小分片数的索引选择切片数。
通过在_delete_by_query API中添加slices会自动执行切片过 程。
7.6.3、切片数目选择

如果利用自动切片机制，将为大多数索引选择一个合理的切片数 字。如果要手动切片或调解自动切片，请遵循以下准则:


8、Update By Query API

查询更新API(_update_by_query)的功能是在不更改源的情况 下对索引中的每个文档执行更新。这对于获取新属性或其他联机映射 更改很有效。
可以利用script、pipeline作为更新。
总体机制与 Delete by query相似，path、query、request body、response body（多了一个updated参数）的参数全部相同。
  1.     POST twitter/_update_by_query?conflicts=proceed
复制代码
返回：
  1.     {
  2.       "took" : 147,
  3.       "timed_out": false,
  4.       "updated": 120,
  5.       "deleted": 0,
  6.       "batches": 1,
  7.       "version_conflicts": 0,
  8.       "noops": 0,
  9.       "retries": {
  10.         "bulk": 0,
  11.         "search": 0
  12.       },
  13.       "throttled_millis": 0,
  14.       "requests_per_second": -1.0,
  15.       "throttled_until_millis": 0,
  16.       "total": 120,
  17.       "failures" : [ ]
  18.     }
复制代码
示例：更新整个文档： 你可以利用_update_by_query来更新整个文档，例如将全部包含特定条件的文档中的某个字段增长一个固定值。示例哀求如下：
  1.     PUT person/_doc/1
  2.     {
  3.       "name":"tom 1",
  4.       "age": 18
  5.     }
  6.    
  7.     PUT person/_doc/2
  8.     {
  9.       "name":"jerry",
  10.       "age": 22
  11.     }
  12.     PUT person/_doc/3
  13.     {
  14.       "name":"tom 2",
  15.       "age": 19
  16.     }
  17.    
  18.     POST person/_update_by_query
  19.     {
  20.      "query": {
  21.        "match": {
  22.          "name": "tom"
  23.        }
  24.      },
  25.      "script": {
  26.        "source": "ctx._source.age += params.increment",
  27.        "params": {
  28.          "increment": 5
  29.        }
  30.      }
  31.     }
复制代码
上述示例将满意条件 “match”:“tom” 的全部文档中的 age 字段增长了 5。
示例：更新部分字段： 除了更新整个文档外，你也可以利用 _update_by_query 来更新部分字段。示例哀求如下：
  1.     POST your_index/_update_by_query
  2.     {
  3.      "query": {
  4.        "term": {
  5.          "field": "value"
  6.        }
  7.      },
  8.      "script": {
  9.        "source": """
  10.          if (ctx._source.containsKey('new_field')) {
  11.            ctx._source.new_field = 'new_value'
  12.          } else {
  13.            ctx.op = 'noop'
  14.          }
  15.        """
  16.      }
  17.     }
复制代码
上述示例会将满意条件 “field” = “value” 的全部文档中的 new_field 字段更新为 ‘new_value’，如果文档中不存在 new_field 字段，则不执行任何操纵。
_update_by_query API在开始时获取该索引的快照，并利用内 部版本控制对找到的内容举行索引。这意味着，如果文档在获取到快照和处理索引哀求的时间之间发生更改，则会出现版本冲突。当版本 匹配时，将更新文档并增长版本号。
全部更新和查询失败都会导致_update_by_query中止，并在响 应failures元素中返回相关错误信息。已经执行的更新仍然保持不 变，即进程不会回滚，只会中止。当第一个失败导致中止时，由失败 的批量哀求返回的全部失败信息都会在failures元素中返回。因此， 大概会有相当多失败的实体。
如果只想统计版本冲突，而不想让_update_by_query操纵中 止，可以在URL上设置conflicts=proceed或在哀求正文中设 置"conflicts":“proceed”。上面的例子就是这样做的，因为它只是在 尝试获取一个在线映射更改，而版本冲突仅仅意味着冲突文档在 _update_by_query的开始和试图更新文档的时间之间被更新。这种 机制用于获取联机映射更新非常有效。
此API还可以用于DSL查询中。这将 更新用户Kimchy的twitter索引中的全部文档:
  1.     POST twitter/_update_by_query?conflicts=proceed
  2.     {      "query": {         "term": {          "user": "kimchy"        }      }    }
复制代码
到现在为止，都是只更新文档而不更改其源字段，这对获取新属 性或映射这类的信息真的很有效，但只是其中一半的功能。 _update_by_query API支持脚本更新文档。
下面的例子，将增长 kimchy全部tweet上的likes字段:
  1.     POST twitter/_update_by_query
  2.     {
  3.       "script": {
  4.         "source": "ctx._source.likes++",
  5.         "lang": "painless"
  6.       },
  7.       "query": {
  8.         "term": {
  9.           "user": "kimchy"
  10.         }
  11.       }
  12.     }
复制代码
正如在更新API中一样，可以设置ctx.op来控制执行的操纵:

在没有指定conflicts=proceed的情况下，版本冲突会中止进程， 这样可以让用户来处理失败。
这个API不允许移动文档，只须修改它们的源字段即可。这是有 意义的，我们没有能力将文件从原始位置移走(这是由Lucene的存储 布局决定的)。
也可以一次对多个索引执行整个操纵，就像搜刮API一样:
  1.     POST twitter,blog/_update_by_query
复制代码
如果提供路由routing字段，则路由将复制到滚动查询中，并将 处理过程限定为与该路由值匹配的分片，如下示例指定了路由参数:
  1.     POST twitter/_update_by_query?routing=1
复制代码
默认情况下，_update_by_query API利用1000滚动批次大小 (操纵是分批举行的，每批1000个文档)。可以利用URL参数 scroll_size更改批次大小:
  1.     POST twitter/_update_by_query?scroll_size=100
复制代码
_update_by_queryAPI还可以通过如下方式指定管道来利用“索 引预处理节点”(预处理的一个功能)功能:
  1.     PUT _ingest/pipeline/set-foo
  2.     {
  3.       "description" : "sets foo",
  4.       "processors" : [ {
  5.           "set" : {
  6.             "field": "foo",
  7.             "value": "bar"
  8.           }
  9.       } ]
  10.     }
  11.     POST twitter/_update_by_query?pipeline=set-foo
复制代码

8.1、URL参数

除了标准参数如pretty外，_update_by_query API还支持 refresh 、 wait_for_completion 、 wait_for_active_shards 、 timeout和scroll参数。
发送refresh参数将在哀求完成时革新索引中的全部分片。这与更 新API的refresh参数不同，后者只会导致接收到新数据的分片被刷 新。还有一点，它不支持wait_for参数。
如果哀求包含wait_for_completion=false，那么Elasticsearch 将执行一些预检查，启动哀求，然后返回一个Task，以取消或获取任 务的状态。Elasticsearch还将在.tasks/task/${taskId}.索引中创 建此使命的记录文档，可以根据需要保留或删除创建的文档。完成后 删除它，这样Elasticsearch可以采取它利用的空间。
wait_for_active_shards控制在继续执行哀求之前必须激活多少 个shard副本。timeout控制每个写哀求等候不可用分片变为可用分 片的时间。这两个参数在Bulk API中的工作方式完全相同。由于 _update_by_query操纵利用滚动搜刮，还可以指定scroll参数来控制 “搜刮上下文”保持运动的时间，例如scroll=10m。默以为5分钟。
requests_per_second可以设置为任何正十进制数(1.4、6、 1000等)，并通过用等候时间填充每个批来限定_update_by_query 发出索引操纵批的速率。通过将requests_per_second设置为-1，可 以禁用限定。限定是通过在批之间等候来完成的，这样就可以为 _update_by_query操纵在内部利用的滚动指定一个填充的超时。填 充时间是批处理大小除以requests_per_second与写入时间之差。默 认情况下，批处理大小为1000，因此如果requests_per_second设 置为500，计算方法如下:
  1.     target_time = 1000 / 500 per second = 2 seconds
  2.     wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds
复制代码
由于该批是作为_bulk哀求发出的，因此大小较大的批将导致 Elasticsearch创建多个哀求，然后在启动下一个集合之前等候一段 时间，这是不平稳的。默认值为-1。

8.2、哀求体

JSON相应如下:
  1.     {
  2.       "took" : 147,
  3.       "timed_out": false,
  4.       "total": 5,
  5.       "updated": 5,
  6.       "deleted": 0,
  7.       "batches": 1,
  8.       "version_conflicts": 0,
  9.       "noops": 0,
  10.       "retries": {
  11.         "bulk": 0,
  12.         "search": 0
  13.       },
  14.       "throttled_millis": 0,
  15.       "requests_per_second": -1.0,
  16.       "throttled_until_millis": 0,
  17.       "failures" : [ ]
  18.     }
复制代码


8.3、使命API

与查询删除delete by query一致

8.4、取消使命API

与查询删除delete by query一致

8.5、动态调解API

与查询删除delete by query一致

8.6、切片

与查询删除delete by query一致

8.7、获取新属性

假设创建了一个没有动态映射的索引，用数据填充它，然后添加 了一个映射值以从数据中提取更多字段，如下示例，“dynamic”: false设置意味着新字段不会被索引，只会存储在_source中。
  1.     PUT test
  2.     {
  3.       "mappings": {
  4.         "dynamic": false,   
  5.         "properties": {
  6.           "text": {"type": "text"}
  7.         }
  8.       }
  9.     }
复制代码
现在，添加两条文档，示例如下:
  1.     POST test/_doc?refresh
  2.     {
  3.       "text": "words words",
  4.       "flag": "bar"
  5.     }
  6.     POST test/_doc?refresh
  7.     {
  8.       "text": "words words",
  9.       "flag": "foo"
  10.     }
复制代码
如下示例，更新映射以添加新flag字段。要提取新字段，必须用 它重新索引全部文档。
  1.     PUT test/_mapping   
  2.     {
  3.       "properties": {
  4.         "text": {"type": "text"},
  5.         "flag": {"type": "text", "analyzer": "keyword"}
  6.       }
  7.     }
复制代码
如下示例，搜刮数据找不到任何内容:
  1.     POST test/_search?filter_path=hits.total
  2.     {
  3.       "query": {
  4.         "match": {
  5.           "flag": "foo"
  6.         }
  7.       }
  8.     }
  9.    
  10.     //返回
  11.     {
  12.       "hits" : {
  13.         "total" : {
  14.           "value" : 0,
  15.           "relation" : "eq"
  16.         }
  17.       }
  18.     }
复制代码
但可以通过_update_by_query发出更新哀求来获取新映射:
  1.     POST test/_update_by_query?refresh&conflicts=proceed
  2.     POST test/_search?filter_path=hits.total
  3.     {
  4.       "query": {
  5.         "match": {
  6.           "flag": "foo"
  7.         }
  8.       }
  9.     }
  10.    
  11.     //返回
  12.     {
  13.       "hits" : {
  14.         "total" : {
  15.           "value" : 1,
  16.           "relation" : "eq"
  17.         }
  18.       }
  19.     }
复制代码

9、Reindex API

重修索引的最基本功能是从一个索引拷贝文档到另一个索引。
  1.     //语法
  2.     POST /_reindex
复制代码
利用reindex手动重新索引旧索引的步骤:
   Reindex要求对源索引中的全部文档启用_source。
    Reindex自动设置目标索引，但是不复制源索引的设置。您应该在运行_reindex操纵之前设置目标索引，包括设置映射、分片计数、副本等。
  reindex最基本的形式只是将文档从一个索引复制到另一个索引。这将把文档从twitter索引复制到new_twitter索引中:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "twitter"
  5.       },
  6.       "dest": {
  7.         "index": "new_twitter"
  8.       }
  9.     }
复制代码
就像update_by_query一样，reindex获取源索引的快照，但是它的目标必须是一个不同的索引，这样就不太大概出现版本冲突。可以像新建索引那样设置dest子句来控制乐观并发控制。忽略version_type或将其设置为internal会导致Elasticsearch盲目地将文档转储到目标中，覆盖任何恰巧具有相同类型和id的文档:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "twitter"
  5.       },
  6.       "dest": {
  7.         "index": "new_twitter",
  8.         "version_type": "internal"
  9.       }
  10.     }
复制代码
将version_type设置为external会导致Elasticsearch保存源文件的版本，创建任何缺失的文档，并更新目标索引中版本比源索引中版本更旧的文档:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "twitter"
  5.       },
  6.       "dest": {
  7.         "index": "new_twitter",
  8.         "version_type": "external"
  9.       }
  10.     }
复制代码
设置op_type为create将导致_reindex只在目标索引中创建缺少的文档。全部现有文档将导致版本冲突:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "twitter"
  5.       },
  6.       "dest": {
  7.         "index": "new_twitter",
  8.         "op_type": "create"
  9.       }
  10.     }
  11.    
  12.     错误示例：
  13.     "[_doc][2]: version conflict, document already exists (current version [2])"
复制代码
默认情况下，版本冲突中止reindex进程，但你可以通过设置“conflicts”:“proceed”忽略冲突继续执行:
  1.     POST _reindex
  2.     {
  3.       "conflicts": "proceed",
  4.       "source": {
  5.         "index": "twitter"
  6.       },
  7.       "dest": {
  8.         "index": "new_twitter",
  9.         "op_type": "create"
  10.       }
  11.     }
复制代码
可以通过向源添加类型或添加查询来限定文档。这将只复制匹配cat的文档到dest中:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "source",
  5.         "query": {
  6.           "match": {
  7.             "company": "cat"
  8.           }
  9.         }
  10.       },
  11.       "dest": {
  12.         "index": "dest",
  13.         "routing": "=cat"
  14.       }
  15.     }
复制代码
source中的索引和类型都可以是列表，允许您在一个哀求中从许多源举行复制。这将从twitter的_doc类型中和blog索引的post类型中复制文档。
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": ["twitter", "blog"]
  5.       },
  6.       "dest": {
  7.         "index": "all_together"
  8.       }
  9.     }
复制代码
还可以通过设置max_docs来限定已处理文档的数目。这只会将一个文档从twitter复制到new_twitter:
  1.     POST _reindex
  2.     {
  3.       "max_docs": 1,
  4.       "source": {
  5.         "index": "twitter"
  6.       },
  7.       "dest": {
  8.         "index": "new_twitter"
  9.       }
  10.     }
复制代码
如果您想要从twitter索引中获得一组特定的文档，则需要利用排序。排序会降低滚动的效率，但在某些情况下，这样做是值得的。如果大概的话，请选择更具选择性的查询而不是size和sort。这将从twitter复制10000个文档到new_twitter:
  1.     POST _reindex
  2.     {
  3.       "size": 10000,
  4.       "source": {
  5.         "index": "twitter",
  6.         "sort": { "date": "desc" }
  7.       },
  8.       "dest": {
  9.         "index": "new_twitter"
  10.       }
  11.     }
复制代码
与update_by_query一样，reindex支持修改文档的脚本。与_update_by_query不同，允许脚本修改文档的元数据。这个例子与源文档的版本冲突:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "twitter"
  5.       },
  6.       "dest": {
  7.         "index": "new_twitter",
  8.         "version_type": "external"
  9.       },
  10.       "script": {
  11.         "source": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
  12.         "lang": "painless"
  13.       }
  14.     }
复制代码
您可以利用以下哀求将公司名称为cat的源索引中的全部文档复制到路由设置为cat的dest索引中
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "source",
  5.         "query": {
  6.           "match": {
  7.             "company": "cat"
  8.           }
  9.         }
  10.       },
  11.       "dest": {
  12.         "index": "dest",
  13.         "routing": "=cat"
  14.       }
  15.     }
复制代码
默认情况下，reindex利用1000的滚动批。您可以更改size批大小字段在源元素:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "source",
  5.         "size": 100
  6.       },
  7.       "dest": {
  8.         "index": "dest",
  9.         "routing": "=cat"
  10.       }
  11.     }
复制代码
Reindex还可以通过这样指定pipeline来利用Ingest节点特性:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "source"
  5.       },
  6.       "dest": {
  7.         "index": "dest",
  8.         "pipeline": "some_ingest_pipeline"
  9.       }
  10.     }
复制代码

9.1、远端集群

Reindex支持从一个远程Elasticsearch集群重修索引:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "remote": {
  5.           "host": "http://otherhost:9200",
  6.           "username": "user",
  7.           "password": "pass"
  8.         },
  9.         "index": "source",
  10.         "query": {
  11.           "match": {
  12.             "test": "data"
  13.           }
  14.         }
  15.       },
  16.       "dest": {
  17.         "index": "dest"
  18.       }
  19.     }
复制代码
host参数必须包含一个连接方式，主机，端口(例如https://otherhost:9200)和可选路径(例如:https://otherhost:9200/proxy)。username,和password参数是可选的，当它们出现时，reindex将利用基自己份验证连接到远程Elasticsearch节点。在利用基自己份验证时，请确保利用https，否则暗码将以纯文本形式发送。
远程主机必须利用reindex.remote.whitelist在elasticsearch.yaml中显式白名单。可以将其设置为允许的远程主机和端口组合(例如otherhost:9200, another:9200, 127.0.10.:9200, localhost:)的逗号分隔列表。只需设置主机和端口即可，例如:
  1.     reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*"
复制代码
必须在和谐重修索引的每一个节点上设置白名单。
这个特性应该适用于您大概找到的任何版本的Elasticsearch的远程集群。这将允许您从任何版本的Elasticsearch升级到当前版本，方法是对旧版本的集群举行索引重修。
为了使查询可以或许发送到旧版本的Elasticsearch，查询参数将直接发送到远程主机，而不需要举行验证或修改。
   从远程集群重新索引不支持手动或自动切片。
  从远程服务器重新索引利用堆上缓冲区，默认最大为100mb。如果远程索引包含非常大的文档，则需要利用较小的批处理大小。下面的示例将批处理大小设置为10，这非常非常小。
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "remote": {
  5.           "host": "http://otherhost:9200"
  6.         },
  7.         "index": "source",
  8.         "size": 10,
  9.         "query": {
  10.           "match": {
  11.             "test": "data"
  12.           }
  13.         }
  14.       },
  15.       "dest": {
  16.         "index": "dest"
  17.       }
  18.     }
复制代码
还可以利用socket_timeout字段在远程连接上设置套接字读取超时，利用connect_timeout字段设置连接超时。两者都默以为30秒。这个例子将套接字读取超时设置为1分钟，连接超时设置为10秒:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "remote": {
  5.           "host": "http://otherhost:9200",
  6.           "socket_timeout": "1m",
  7.           "connect_timeout": "10s"
  8.         },
  9.         "index": "source",
  10.         "query": {
  11.           "match": {
  12.             "test": "data"
  13.           }
  14.         }
  15.       },
  16.       "dest": {
  17.         "index": "dest"
  18.       }
  19.     }
复制代码

9.2、URL参数

除了像pretty这样的标准参数外，Reindex还支持refresh、wait_for_completion、wait_for_active_shards、timeout、scroll和requests_per_second。
发送refresh参数将导致革新全部索引的写哀求。这与Index的refresh参数不同，后者只会革新接收到新数据的分片。另外，与Index不同，它不支持wait_for。
如果哀求包含wait_for_completion=false，那么Elasticsearch将举行一些执行前检查，启动哀求，然后返回一个使命，该使命可用于task来取消或获得该使命的状态。Elasticsearch还将在.tasks/task/${taskId}处创建该使命的记录作为文档。你可以自主决定保留或删除。当你完成或删除它时，利用的空间将被采取。
wait_for_active_shards控制在继续举行重修索引之前必须激活一个分片的多少个副本。timeout控制每个写哀求等候不可用分片变为可用的时间。两者的工作方式与它们在Bulk中的工作方式完全相同。由于_reindex利用scroll搜刮，你也可以指定滚动参数来控制它保持“搜刮上下文”存活的时间(例如?scroll=10m)。默认值是5分钟。
可以将requests_per_second设置为任何正的十进制数(1.4、6、1000等)，并通过填充每个批处理的等候时间来调节_reindex发出批索引操纵的速度。可以通过将requests_per_second设置为-1来禁用限流。
限流是通过在批之间等候来完成的，这样_reindex在内部利用的scroll就可以获得一个数据索引的时间。该时间是批处理大小除以requests_per_second与花费在写索引上的时间的差。默认情况下批大小为1000，因此如果将requests_per_second设置为500:
  1.     target_time = 1000 / 500 per second = 2 seconds
  2.     wait_time = target_time - write_time = 2 seconds - 0.5 seconds = 1.5 seconds
复制代码
由于批处理是作为单个_bulk哀求发出的，因此较大的批处理将导致Elasticsearch创建多个哀求，然后在开始下一组哀求之前等候一段时间。默认值是-1。

9.3、使命API

与查询删除delete by query一致

9.4、取消使命API

与查询删除delete by query一致

9.5、动态调解API

与查询删除delete by query一致

9.6、切片

与查询删除delete by query一致

9.7、字段重定名

_reindex可用于构建具有重定名字段的索引副本。假设你创建了一个包含如下文档的索引:
  1.     POST test/_doc/1?refresh
  2.     {
  3.       "text": "words words",
  4.       "flag": "foo"
  5.     }
复制代码
但是您不喜欢flag这个名字，想用tag更换它。reindex可以为您创建另一个索引:
  1.     POST _reindex
  2.     {
  3.       "source": {
  4.         "index": "test"
  5.       },
  6.       "dest": {
  7.         "index": "test2"
  8.       },
  9.       "script": {
  10.         "source": "ctx._source.tag = ctx._source.remove("flag")"
  11.       }
  12.     }
复制代码
新文档：
  1.     {
  2.       "_index" : "test2",
  3.       "_type" : "_doc",
  4.       "_id" : "1",
  5.       "_score" : 1.0,
  6.       "_source" : {
  7.         "text" : "words words",
  8.         "tag" : "foo"
  9.       }
  10.     }
复制代码

9.8、重修多个索引

如果您有许多索引要重修，通常最好一次一个，而不是利用一个全局模式来重修许多索引。这样，如果有任何错误，您可以通过删除部分完成的索引并在该索引处重新开始来恢复该过程。它还使得并行化过程相当简单:分割索引列表以重新索引并并行地运行每个列表。
bash脚本：
  1.     for index in i1 i2 i3 i4 i5; do
  2.       curl -HContent-Type:application/json -XPOST localhost:9200/_reindex?pretty -d'{
  3.         "source": {
  4.           "index": "'$index'"
  5.         },
  6.         "dest": {
  7.           "index": "'$index'-reindexed"
  8.         }
  9.       }'
  10.     done
复制代码
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/) Powered by Discuz! X3.4