本篇内容主要讲解“Reindex API怎么从本地重建索引”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Reindex API怎么从本地重建索引”吧!
Reindex不会尝试设置目标索引。它不会复制源索引的设置信息。您应该在运行_reindex操作之前设置目标索引，包括设置映射，分片数，副本等。
_reindex的最基本形式只是将文档从一个索引复制到另一个索引。下面将文档从twitter索引复制到new_twitter索引中：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
这将会返回类似以下的信息：
{
"took" : 147,
"timed_out": false,
"created": 120,
"updated": 0,
"deleted": 0,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"total": 120,
"failures" : [ ]
}和_update_by_query一样，_reindex获取源索引的快照，但其目标索引必须是不同的索引，因此不会发生版本冲突。 dest元素可以像索引API一样进行配置，以控制乐观并发控制。只需将version_type 空着（像上面一样）或将version_type设置为internal则Elasticsearch强制性的将文档转储到目标中，覆盖具有相同类型和ID的任何内容：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "internal"
}
}将version_type设置为external将导致Elasticsearch从源文件中保留版本，创建缺失的所有文档，并更新在目标索引中比源索引中版本更老的所有文档：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
}
}设置op_type为create将导致_reindex仅在目标索引中创建缺少的文档。所有存在的文档将导致版本冲突：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
结果：
{
"took": 2015,
"timed_out": false,
"total": 6520,
"updated": 0,
"created": 885,
"deleted": 0,
"batches": 1,
"version_conflicts": 115,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1,
"throttled_until_millis": 0,
"failures": [
{
"index": "sphinx-doctorinfo-20.11.11-162930",
"type": "_doc",
"id": "42",
"cause": {
"type": "version_conflict_engine_exception",
"reason": "[_doc][42]: version conflict, document already exists (current version [1])",
"index_uuid": "z1U5C2-TSXWQtAofQSSuHg",
"shard": "0",
"index": "sphinx-doctorinfo-20.11.11-162930"
},
"status": 409
}
}
默认情况下，版本冲突将中止_reindex进程，但您可以通过请求体设置"conflict":"proceed"来在冲突时进行计数：
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}您可以通过向source添加type或添加query来限制文档。下面会将kimchy发布的tweet复制到new_twitter中：
POST _reindex
{
"source": {
"index": "twitter",
"type": "tweet",
"query": {
"term": {
"user": "kimchy"
}
}
},
"dest": {
"index": "new_twitter"
}
}source中的index和type都可以是一个列表，允许您在一个请求中从大量的来源进行复制。下面将从twitter和blog索引中的tweet和post类型中复制文档。它也包含twitter索引中post类型以及blog索引中的tweet类型。如果你想更具体，你将需要使用query。它也没有努力处理ID冲突。目标索引将保持有效，但由于迭代顺序定义不正确，预测哪个文档可以保存下来是不容易的。
POST _reindex
{
"source": {
"index": ["twitter", "blog"],
"type": ["tweet", "post"]
},
"dest": {
"index": "all_together"
}
}还可以通过设置大小限制处理的文档的数量。下面只会将单个文档从twitter复制到new_twitter：
POST _reindex
{
"size": 1,
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}如果你想要从twitter索引获得一个特定的文档集合你需要排序。排序使滚动效率更低，但在某些情况下它是值得的。如果可能，更喜欢更多的选择性查询size和sort。这将从twitter复制10000个文档到new_twitter：
POST _reindex
{
"size": 10000,
"source": {
"index": "twitter",
"sort": { "date": "desc" }
},
"dest": {
"index": "new_twitter"
}
}
source部分支持搜索请求中支持的所有元素。例如，只使用原始文档的一部分字段，使用源过滤如下所示：
POST _reindex
{
"source": {
"index": "twitter",
"_source": ["user", "tweet"]
},
"dest": {
"index": "new_twitter"
}
}像update_by_query一样，_reindex支持修改文档的脚本。与_update_by_query不同，脚本允许修改文档的元数据。此示例修改了源文档的版本：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
},
"script": {
"inline": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
"lang": "painless"
}
}
就像在_update_by_query中一样，您可以设置ctx.op来更改在目标索引上执行的操作：
noop
如果您的脚本决定不必进行任何更改，请设置 ctx.op ="noop" 。这将导致_update_by_query 从其更新中忽略该文档。这个没有操作将被报告在响应体的 noop 计数器上。
delete
如果您的脚本决定必须删除该文档，请设置ctx.op="delete"。删除将在响应体的 deleted 计数器中报告。
将ctx.op设置为其他任何内容都是错误。在ctx中设置任何其他字段是一个错误。
想想可能性！只要小心点，有很大的力量...你可以改变：
_id
_type
_index
_version
_routing
_parent
将_version设置为null或从ctx映射清除就像在索引请求中不发送版本一样。这将导致目标索引中的文档被覆盖，无论目标版本或_reindex请求中使用的版本类型如何。默认情况下，如果_reindex看到具有路由的文档，则路由将被保留，除非脚本被更改。您可以根据dest请求设置routing来更改：
keep：将批量请求的每个匹配项的路由设置为匹配上的路由。默认值。
discard：将批量请求的每个匹配项的路由设置为null。
=<某些文本>：将批量请求的每个匹配项的路由设置为`=`之后的文本。
例如，您可以使用以下请求将source索引的所有公司名称为cat的文档复制到路由设置为cat的dest索引。
POST _reindex
{
"source": {
"index": "source",
"query": {
"match": {
"company": "cat"
}
}
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}默认情况下，_reindex批量滚动处理大小为1000.您可以在source元素中指定size字段来更改批量处理大小：
POST _reindex
{
"source": {
"index": "source",
"size": 100 #batch size 这里在机器资源允许的条件下，搞大点
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
1.ES是非实时的。Elasticsearch中，Index的实时性是由refresh控制的，默认是1s，最快可到100ms，那么也就意味着Index doc成功后，需要等待一秒钟后才可以被搜索到。
2.reindex是耗费性能的。借助：scroll+bulk实现。
优化建议：重索引下建议这个size设置大点Reindex也可以使用[Ingest Node]功能来指定pipeline, 就像这样：
POST _reindex
{
"source": {
"index": "source"
},
"dest": {
"index": "dest",
"pipeline": "some_ingest_pipeline"
}
}Reindex支持从远程Elasticsearch群集重建索引：
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200",
"username": "user",
"password": "pass"
},
"index": "source",
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}host参数必须包含scheme，host和port（例如 https：// otherhost:9200）。用户名和密码参数是可选的，当它们存在时，索引将使用基本认证连接到远程Elasticsearch节点。使用基本认证时请务必使用https，密码将以纯文本格式发送。
必须在elasticsearch.yaml中使用reindex.remote.whitelist属性将远程主机明确列入白名单。它可以设置为允许的远程host和port组合的逗号分隔列表（例如otherhost:9200,another:9200,127.0.10.*:9200,localhost:*）。白名单忽略了scheme ——仅使用主机和端口。
此功能应适用于您可能找到的任何版本的Elasticsearch的远程群集。这应该允许您从任何版本的Elasticsearch升级到当前版本，通过从旧版本的集群重新建立索引。
要启用发送到旧版本Elasticsearch的查询，query参数将直接发送到远程主机，无需验证或修改。
来自远程服务器的重新索引使用默认为最大大小为100mb的堆栈缓冲区。如果远程索引包含非常大的文档，则需要使用较小的批量大小。下面的示例设置非常非常小的批量大小10。
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200"
},
"index": "source",
"size": 10,
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}也可以使用socket_timeout字段在远程连接上设置socket的读取超时，并使用connect_timeout字段设置连接超时。两者默认为三十秒。此示例将套接字读取超时设置为一分钟，并将连接超时设置为十秒：
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200",
"socket_timeout": "1m",
"connect_timeout": "10s"
},
"index": "source",
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}除了标准参数像pretty之外，“Reindex API”还支持refresh、wait_for_completion、wait_for_active_shards、timeout以及requests_per_second。
发送refresh将在更新请求完成时更新索引中的所有分片。这不同于 Index API 的refresh参数，只会导致接收到新数据的分片被索引。
如果请求包含wait_for_completion=false，那么Elasticsearch将执行一些预检检查、启动请求、然后返回一个任务，可以与Tasks API一起使用来取消或获取任务的状态。Elasticsearch还将以.tasks/task/${taskId}作为文档创建此任务的记录。这是你可以根据是否合适来保留或删除它。当你完成它时，删除它可以让Elasticsearch回收它使用的空间。
wait_for_active_shards控制在继续请求之前必须有多少个分片必须处于活动状态，详见这里。timeout控制每个写入请求等待不可用分片变成可用的时间。两者都能正确地在Bulk API中工作。
requests_per_second可以设置为任何正数（1.4，6，1000等），来作为“delete-by-query”每秒请求数的节流阀数字，或者将其设置为-1以禁用限制。节流是在批量批次之间等待，以便它可以操纵滚动超时。等待时间是批次完成的时间与request_per_second * requests_in_the_batch的时间之间的差异。由于分批处理没有被分解成多个批量请求，所以会导致Elasticsearch创建许多请求，然后等待一段时间再开始下一组。这是“突发”而不是“平滑”。默认值为-1。
JSON响应类似如下：
{
"took" : 639,
"updated": 0,
"created": 123,
"batches": 1,
"version_conflicts": 2,
"retries": {
"bulk": 0,
"search": 0
}
"throttled_millis": 0,
"failures" : [ ]
}took：从整个操作的开始到结束的毫秒数。
updated：成功更新的文档数。
upcreateddated：成功创建的文档数。
batches：通过查询更新的滚动响应数量。
version_conflicts：根据查询更新时，版本冲突的数量。
retries：根据查询更新的重试次数。bluk 是重试的批量操作的数量，search 是重试的搜索操作的数量。
throttled_millis：请求休眠的毫秒数，与`requests_per_second`一致。
failures：失败的索引数组。如果这是非空的，那么请求因为这些失败而中止。请参阅 conflicts 来如何防止版本冲突中止操作。
您可以使用Task API获取任何正在运行的重建索引请求的状态：
GET _tasks?detailed=true&actions=*/update/byquery
响应会类似如下：
{
"nodes" : {
"r1A2WoRbTwKZ516z6NEs5A" : {
"name" : "r1A2WoR",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"attributes" : {
"testattr" : "test",
"portsfile" : "true"
},
"tasks" : {
"r1A2WoRbTwKZ516z6NEs5A:36619" : {
"node" : "r1A2WoRbTwKZ516z6NEs5A",
"id" : 36619,
"type" : "transport",
"action" : "indices:data/write/reindex",
"status" : { //①
"total" : 6154,
"updated" : 3500,
"created" : 0,
"deleted" : 0,
"batches" : 4,
"version_conflicts" : 0,
"noops" : 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0
},
"description" : ""
}
}
}
}
}① 此对象包含实际状态。它就像是响应json，重要的添加total字段。 total是重建索引希望执行的操作总数。您可以通过添加的updated、created和deleted的字段来估计进度。当它们的总和等于total字段时，请求将完成。
使用任务id可以直接查找任务：
GET /_tasks/taskId:1
这个API的优点是它与wait_for_completion=false集成，以透明地返回已完成任务的状态。如果任务完成并且wait_for_completion=false被设置，那么它将返回results或error字段。此功能的成本是wait_for_completion=false在.tasks/task/${taskId}创建的文档，由你自己删除该文件。
所有重建索引都能使用Task Cancel API取消：
POST _tasks/task_id:1/_cancel 可以使用上面的任务API找到task_id。
取消应尽快发生，但可能需要几秒钟。上面的任务状态API将继续列出任务，直到它被唤醒取消自身。
request_per_second的值可以在通过查询删除时使用_rethrottle API更改：
POST _update_by_query/task_id:1/_rethrottle?requests_per_second=-1 可以使用上面的任务API找到task_id。
就像在_update_by_query API中设置它一样，request_per_second可以是-1来禁用限制，或者任何十进制数字，如1.7或12，以节制到该级别。加速查询的会立即生效，但是在完成当前批处理之后，减慢查询的才会生效。这样可以防止滚动超时。
_reindex可用于使用重命名的字段构建索引的副本。假设您创建一个包含如下所示的文档的索引：
POST test/test/1?refresh
{
"text": "words words",
"flag": "foo"
}
但是你不喜欢这个flag名称，而是要用tag替换它。 _reindex可以为您创建其他索引：
POST _reindex
{
"source": {
"index": "test"
},
"dest": {
"index": "test2"
},
"script": {
"inline": "ctx._source.tag = ctx._source.remove(\"flag\")"
}
}
现在你可以得到新的文件：
GET test2/test/1
{
"found": true,
"_id": "1",
"_index": "test2",
"_type": "test",
"_version": 1,
"_source": {
"text": "words words",
"tag": "foo"
}
}
或者你可以通过tag进行任何你想要的搜索。重建索引支持滚动切片，您可以相对轻松地手动并行化处理：
POST _reindex
{
"source": {
"index": "twitter",
"slice": {
"id": 0,
"max": 2
}
},
"dest": {
"index": "new_twitter"
}
}
POST _reindex
{
"source": {
"index": "twitter",
"slice": {
"id": 1,
"max": 2
}
},
"dest": {
"index": "new_twitter"
}
}
您可以通过以下方式验证：
GET _refresh
POST new_twitter/_search?size=0&filter_path=hits.total
其结果一个合理的total像这样：
{
"hits": {
"total": 120
}
}你还可以让重建索引使用切片的_uid来自动并行的滚动切片。
POST _reindex?slices=5&refresh
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
您可以通过以下方式验证：
POST new_twitter/_search?size=0&filter_path=hits.total
其结果一个合理的total像这样：
{
"hits": {
"total": 120
}
}将slices添加到_reindex中可以自动执行上述部分中使用的手动过程，创建子请求，这意味着它有一些怪癖：
您可以在Task API中看到这些请求。这些子请求是具有slices请求任务的“子”任务。
获取slices请求任务的状态只包含已完成切片的状态。
这些子请求可以单独寻址，例如取消和重置节流阀。
slices的重置节流阀请求将按相应的重新计算未完成的子请求。
slices的取消请求将取消每个子请求。
由于slices的性质，每个子请求将不会获得完全均匀的文档部分。所有文件都将被处理，但有些片可能比其他片大。预期更大的切片可以有更均匀的分布。
带有slices请求的request_per_second和size的参数相应的分配给每个子请求。结合上述关于分布的不均匀性，您应该得出结论，使用切片大小可能不会导致正确的大小文档为_reindex。
每个子请求都会获得源索引的略有不同的快照，尽管这些都是大致相同的时间。
在这一点上，我们围绕要使用的slices数量提供了一些建议（比如手动并行化时，切片API中的max参数）：
不要使用大的数字，500就能造成相当大的CPU抖动。
从查询性能的角度来看，在源索引中使用分片数量的一些倍数更为有效。
在源索引中使用完全相同的分片是从查询性能的角度来看效率最高的。
索引性能应在可用资源之间以slices数量线性扩展。
索引或查询性能是否支配该流程取决于许多因素，如正在重建索引的文档和进行reindexing的集群。
您可以使用_reindex与Painless组合来重新每日编制索引，以将新模板应用于现有文档。 假设您有由以下文件组成的索引：
PUT metricbeat-2016.05.30/beat/1?refresh
{"system.cpu.idle.pct": 0.908}
PUT metricbeat-2016.05.31/beat/1?refresh
{"system.cpu.idle.pct": 0.105}metricbeat-*索引的新模板已经加载到Elaticsearch中，但它仅适用于新创建的索引。Painless可用于重新索引现有文档并应用新模板。
下面的脚本从索引名称中提取日期，并创建一个附带有-1的新索引。来自metricbeat-2016.05.31的所有数据将重新索引到metricbeat-2016.05.31-1。
POST _reindex
{
"source": {
"index": "metricbeat-*"
},
"dest": {
"index": "metricbeat"
},
"script": {
"lang": "painless",
"inline": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'"
}
}来自上一个度量索引的所有文档现在可以在*-1索引中找到。
GET metricbeat-2016.05.30-1/beat/1 GET metricbeat-2016.05.31-1/beat/1
以前的方法也可以与更改字段的名称一起使用，以便将现有数据加载到新索引中，但如果需要，还可以重命名字段。
Reindex可用于提取用于测试的索引的随机子集：
POST _reindex
{
"size": 10,
"source": {
"index": "twitter",
"query": {
"function_score" : {
"query" : { "match_all": {} },
"random_score" : {}
}
},
"sort": "_score" //①
},
"dest": {
"index": "random_twitter"
}
}Reindex默认按_doc排序，所以random_score不会有任何效果，除非您将排序重写为_score。
到此，相信大家对“Reindex API怎么从本地重建索引”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
