文档 API

如果请求的目标不存在且匹配一个带有data_stream定义的索引模板，索引操作将自动创建数据流。请参阅设置数据流。

如果目标不存在且不匹配数据流模板，操作将自动创建索引并应用任何匹配的索引模板。

如果不存在映射，索引操作会创建一个动态映射。默认情况下，如果需要，新字段和对象会自动添加到映射中。有关字段映射的更多信息，请参阅映射和更新映射 API。

自动索引创建由action.auto_create_index设置控制。此设置默认为true，允许自动创建任何索引。您可以修改此设置以明确允许或阻止与指定模式匹配的索引的自动创建，或将其设置为false以完全禁用自动索引创建。指定一个逗号分隔的模式列表，您希望允许的模式，或使用+或-作为前缀来指示是否应允许或阻止该模式。当指定列表时，默认行为是禁止。

PUT _cluster/settings
{
  "persistent": {
    "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*" 
  }
}

PUT _cluster/settings
{
  "persistent": {
    "action.auto_create_index": "false" 
  }
}

PUT _cluster/settings
{
  "persistent": {
    "action.auto_create_index": "true" 
  }
}

您可以通过使用_create资源或设置op_type参数为create来强制执行创建操作。在这种情况下，如果索引中已经存在具有指定ID的文档，则索引操作将失败。

当使用 POST //_doc/ 请求格式时，op_type 会自动设置为 create，并且索引操作会为文档生成一个唯一的ID。

POST my-index-000001/_doc/
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {
    "id": "kimchy"
  }
}

API返回以下结果：

{
  "_shards": {
    "total": 2,
    "failed": 0,
    "successful": 2
  },
  "_index": "my-index-000001",
  "_id": "W0tpsmIBdwcYyG50zbta",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "result": "created"
}

索引操作可以是有条件的，并且只有在文档的最后一次修改被分配了由if_seq_no和if_primary_term参数指定的序列号和主项时才会执行。如果检测到不匹配，操作将导致VersionConflictException并返回409状态码。有关更多详细信息，请参阅乐观并发控制。

默认情况下，分片分配——或路由——是通过使用文档id值的哈希值来控制的。为了更明确地控制，可以在每次操作的基础上直接指定路由器使用的哈希函数的值，使用路由参数。例如：

POST my-index-000001/_doc?routing=kimchy
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {
    "id": "kimchy"
  }
}

在这个例子中，文档根据提供的routing参数："kimchy"被路由到一个分片。

在设置显式映射时，您还可以使用 _routing 字段 来指示索引操作从文档本身提取路由值。这确实会带来（非常小的）额外文档解析开销。如果定义了 _routing 映射 并设置为 required，则在未提供或提取路由值的情况下，索引操作将失败。

索引操作根据其路由定向到主分片（参见上面的路由部分），并在包含该分片的实际节点上执行。主分片完成操作后，如果需要，更新将分发到适用的副本。

为了提高系统写入的弹性，可以配置索引操作在继续操作之前等待一定数量的活动分片副本。如果所需数量的活动分片副本不可用，则写操作必须等待并重试，直到所需的分片副本启动或发生超时。默认情况下，写操作仅等待主分片处于活动状态后再继续（即 wait_for_active_shards=1）。可以通过动态设置索引设置中的 index.write.wait_for_active_shards 来覆盖此默认值。要按操作更改此行为，可以使用 wait_for_active_shards 请求参数。

有效值为 all 或任何正整数，最大不超过索引中每个分片配置的副本总数（即 number_of_replicas+1）。指定负值或大于分片副本数的数字将抛出错误。

例如，假设我们有一个由三个节点组成的集群，A、B 和 C， 我们创建了一个索引 index，并将副本数量设置为 3（结果是 4 个分片副本，比节点数量多一个副本）。如果我们 尝试进行索引操作，默认情况下，操作只会在确保 每个分片的主副本可用后继续进行。这意味着 即使 B 和 C 宕机，而 A 托管了主分片副本， 索引操作仍然会继续进行，只使用一个数据副本。 如果 wait_for_active_shards 在请求中设置为 3（并且所有 3 个节点 都正常运行），那么索引操作将需要 3 个活跃的分片副本 才能继续进行，这个要求应该会满足，因为集群中有 3 个 活跃的节点，每个节点都持有一个分片副本。然而， 如果我们设置 wait_for_active_shards 为 all（或者设置为 4，这是相同的）， 索引操作将不会继续进行，因为我们没有在索引中激活所有 4 个副本。 操作将会超时， 除非在集群中启动了一个新节点来托管分片的第四个副本。

需要注意的是，此设置大大减少了写操作未写入所需数量的分片副本的可能性，但它并不能完全消除这种可能性，因为此检查是在写操作开始之前进行的。一旦写操作开始，仍然有可能在任意数量的分片副本上复制失败，但在主分片上成功。写操作响应中的_shards部分揭示了复制成功/失败的分片副本数量。

{
  "_shards": {
    "total": 2,
    "failed": 0,
    "successful": 2
  }
}

控制此请求所做的更改何时对搜索可见。请参阅 refresh。

当使用索引 API 更新文档时，即使文档没有变化，也会创建文档的新版本。如果不接受这种情况，请使用 _update API 并将 detect_noop 设置为 true。此选项在索引 API 中不可用，因为索引 API 不会获取旧的源数据，也无法将其与新的源数据进行比较。

关于何时noop更新不可接受，并没有严格的规定。这涉及到许多因素，比如数据源发送实际noop更新的频率，以及Elasticsearch在接收更新的分片上每秒运行的查询数量。

执行索引操作时，分配来执行该操作的主分片可能不可用。造成这种情况的一些原因可能是主分片当前正在从网关恢复或正在进行重新定位。默认情况下，索引操作将等待主分片变为可用状态，最多等待1分钟，然后失败并返回错误。可以使用timeout参数显式指定等待时间。以下是将等待时间设置为5分钟的示例：

PUT my-index-000001/_doc/1?timeout=5m
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {
    "id": "kimchy"
  }
}

每个索引文档都被赋予一个版本号。默认情况下，使用内部版本控制，从1开始，每次更新（包括删除）时递增。可选地，版本号可以设置为外部值（例如，如果维护在数据库中）。要启用此功能，version_type 应设置为 external。提供的值必须是一个大于或等于0的数值，长整型值，并且小于大约9.2e+18。

当使用外部版本类型时，系统会检查传递给索引请求的版本号是否大于当前存储文档的版本号。如果为真，文档将被索引并使用新的版本号。如果提供的值小于或等于存储文档的版本号，将发生版本冲突，索引操作将失败。例如：

PUT my-index-000001/_doc/1?version=2&version_type=external
{
  "user": {
    "id": "elkbee"
  }
}

在之前的示例中，操作将会成功，因为提供的版本2高于当前文档版本1。如果文档已经更新并且其版本被设置为2或更高，索引命令将会失败并导致冲突（409 http状态码）。

一个很好的副作用是，只要使用源数据库的版本号，就不需要严格维护异步索引操作的顺序，这些操作是由于源数据库的更改而执行的。即使是从数据库更新Elasticsearch索引的简单情况，如果使用外部版本控制，也会简化，因为无论出于何种原因，如果索引操作的顺序不正确，只会使用最新版本。

除了external版本类型外，Elasticsearch还支持其他类型用于特定用例：

指定refresh参数会在请求完成后刷新所有参与删除查询的分片。这与删除API的refresh参数不同，后者只会刷新接收到删除请求的分片。与删除API不同，它不支持wait_for。

如果请求包含 wait_for_completion=false，Elasticsearch 会执行一些预检操作，启动请求，并返回一个 任务，您可以使用它来取消或获取任务的状态。Elasticsearch 会创建一个 记录此任务的文档，路径为 .tasks/task/${taskId}。当您完成任务后，应删除任务文档，以便 Elasticsearch 可以回收空间。

wait_for_active_shards 控制在进行请求之前必须处于活动状态的分片副本数量。详情请参阅 活动分片。timeout 控制每个写请求等待不可用分片变为可用的时间。两者的作用方式与 批量 API 中的工作方式完全相同。按查询删除使用滚动搜索，因此您还可以指定 scroll 参数来控制它保持搜索上下文活动的时间，例如 ?scroll=10m。默认值为 5 分钟。

要控制按查询删除发出批量删除操作的速率，您可以将requests_per_second设置为任何正的小数。这会在每个批次中加入等待时间以限制速率。将requests_per_second设置为-1以禁用限制。

节流使用批处理之间的等待时间，以便内部滚动请求可以有一个超时时间，该超时时间考虑了请求填充。填充时间是批处理大小除以requests_per_second与写入时间之差。默认情况下，批处理大小为1000，因此如果requests_per_second设置为500：

target_time = 1000 / 500 per second = 2 seconds
wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

由于批处理是以单个 _bulk 请求发出的，较大的批处理大小会导致 Elasticsearch 创建许多请求并在开始下一组之前等待。 这种方式是“突发性”的，而不是“平滑”的。

通过查询删除支持分片滚动以并行化删除过程。这可以提高效率，并提供一种方便的方式将请求分解为更小的部分。

将 slices 设置为 auto 会为大多数数据流和索引选择一个合理的数量。 如果你手动切片或调整自动切片，请记住：

查询或删除性能是否主导运行时间取决于正在重新索引的文档和集群资源。

使用任务管理 API来获取按查询删除操作的状态：

GET _tasks?detailed=true&actions=*/delete/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/delete/byquery",
          "status" : {    
            "total" : 6154,
            "updated" : 0,
            "created" : 0,
            "deleted" : 3500,
            "batches" : 36,
            "version_conflicts" : 0,
            "noops" : 0,
            "retries": 0,
            "throttled_millis": 0
          },
          "description" : ""
        }
      }
    }
  }
}

通过任务ID，您可以直接查找任务：

GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619

这个API的优点是它与wait_for_completion=false集成，可以透明地返回已完成任务的状态。如果任务已完成并且在该任务上设置了wait_for_completion=false，那么它将返回results或error字段。这个功能的代价是wait_for_completion=false在.tasks/task/${taskId}处创建的文档。是否删除该文档由您决定。

任何通过查询进行的删除操作都可以使用任务取消 API来取消：

POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel

任务ID可以通过任务管理API找到。

取消操作应快速进行，但可能需要几秒钟。上述任务状态API将继续列出删除查询任务，直到该任务检查到它已被取消并终止自身。

指定refresh参数会在请求完成后刷新所有分片。 这与更新API的refresh参数不同，后者仅导致接收请求的分片被刷新。与更新API不同，它不支持 wait_for。

如果请求包含 wait_for_completion=false，Elasticsearch 会执行一些预检操作，启动请求，并返回一个 任务，您可以使用它来取消或获取任务的状态。 Elasticsearch 会在 .tasks/task/${taskId} 处为此任务创建一个文档记录。

wait_for_active_shards 控制在进行请求之前必须有多少个分片的副本处于活动状态。详情请参阅 活动分片。timeout 控制每个写请求等待不可用分片变为可用的时间。两者的作用方式与 批量 API 中的工作方式完全相同。按查询更新使用滚动搜索，因此您还可以指定 scroll 参数来控制它保持搜索上下文活动的时间，例如 ?scroll=10m。默认值为 5 分钟。

要控制通过查询更新发出批量更新操作的速率，您可以将requests_per_second设置为任何正的小数。这会在每个批次中添加等待时间以限制速率。将requests_per_second设置为-1以禁用限制。

节流使用批处理之间的等待时间，以便内部滚动请求可以有一个超时时间，该超时时间考虑了请求填充。填充时间是批处理大小除以requests_per_second与写入时间之差。默认情况下，批处理大小为1000，因此如果requests_per_second设置为500：

target_time = 1000 / 500 per second = 2 seconds
wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

由于批处理是以单个 _bulk 请求发出的，较大的批处理大小会导致 Elasticsearch 创建许多请求并在开始下一组之前等待。 这种方式是“突发性”的，而不是“平滑”的。

通过查询更新支持分片滚动以并行化更新过程。这可以提高效率，并提供一种方便的方式将请求分解为更小的部分。

将 slices 设置为 auto 会为大多数数据流和索引选择一个合理的数量。 如果你手动切片或调整自动切片，请记住：

查询或更新性能主导运行时间取决于被重新索引的文档和集群资源。

通过查询更新支持使用脚本来更新文档源。 例如，以下请求将my-index-000001中所有user.id为kimchy的文档的count字段增加：

POST my-index-000001/_update_by_query
{
  "script": {
    "source": "ctx._source.count++",
    "lang": "painless"
  },
  "query": {
    "term": {
      "user.id": "kimchy"
    }
  }
}

请注意，此示例中未指定 conflicts=proceed。在这种情况下，版本冲突应停止进程，以便您可以处理失败。

与Update API一样，您可以设置ctx.op来更改执行的操作：

按查询更新仅支持 index、noop 和 delete。 将 ctx.op 设置为其他任何值都是错误。将任何其他字段设置在 ctx 中都是错误。 此 API 仅允许您修改匹配文档的源，您无法移动它们。

通过查询更新可以使用Ingest pipelines功能，通过指定pipeline：

PUT _ingest/pipeline/set-foo
{
  "description" : "sets foo",
  "processors" : [ {
      "set" : {
        "field": "foo",
        "value": "bar"
      }
  } ]
}
POST my-index-000001/_update_by_query?pipeline=set-foo

您可以通过任务 API获取所有正在运行的更新查询请求的状态：

GET _tasks?detailed=true&actions=*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/update/byquery",
          "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" : ""
        }
      }
    }
  }
}

通过任务ID，您可以直接查找任务。以下示例检索有关任务 r1A2WoRbTwKZ516z6NEs5A:36619 的信息：

GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619

这个API的优势在于它与wait_for_completion=false集成，能够透明地返回已完成任务的状态。如果任务已完成并且设置了wait_for_completion=false，那么它将返回一个results或一个error字段。这个功能的代价是wait_for_completion=false在.tasks/task/${taskId}处创建的文档。是否删除该文档由您决定。

任何通过查询进行的更新都可以使用任务取消 API来取消：

POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel

任务ID可以通过任务管理API找到。

取消操作应快速进行，但可能需要几秒钟。上述任务状态API将继续列出查询更新任务，直到该任务检查到已被取消并终止自身。

可以通过使用 _rethrottle API 在运行的更新查询中更改 requests_per_second 的值：

POST _update_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1

任务ID可以通过任务管理API找到。

就像在 _update_by_query API 上设置它一样，requests_per_second 可以是 -1 以禁用限流，或者是任何小数，如 1.7 或 12 以限制到该水平。加快查询速度的重新限流会立即生效，但减慢查询速度的重新限流将在完成当前批次后生效。这可以防止滚动超时。

通过为每个请求提供切片ID和切片总数，手动按查询进行切片更新：

POST my-index-000001/_update_by_query
{
  "slice": {
    "id": 0,
    "max": 2
  },
  "script": {
    "source": "ctx._source['extra'] = 'test'"
  }
}
POST my-index-000001/_update_by_query
{
  "slice": {
    "id": 1,
    "max": 2
  },
  "script": {
    "source": "ctx._source['extra'] = 'test'"
  }
}

你可以通过以下方式验证其有效性：

GET _refresh
POST my-index-000001/_search?size=0&q=extra:test&filter_path=hits.total

这会得到一个合理的总计，如下所示：

{
  "hits": {
    "total": {
        "value": 120,
        "relation": "eq"
    }
  }
}

您还可以通过使用切片滚动在_id上进行切片，让查询更新自动并行化。使用slices来指定要使用的切片数量：

POST my-index-000001/_update_by_query?refresh&slices=5
{
  "script": {
    "source": "ctx._source['extra'] = 'test'"
  }
}

你也可以验证以下内容是否有效：

POST my-index-000001/_search?size=0&q=extra:test&filter_path=hits.total

这会得到一个合理的总计，如下所示：

{
  "hits": {
    "total": {
        "value": 120,
        "relation": "eq"
    }
  }
}

将 slices 设置为 auto 将让 Elasticsearch 选择要使用的切片数量。此设置将每个分片使用一个切片，直到达到某个限制。如果有多个源数据流或索引，它将根据分片数量最少的索引或后备索引选择切片数量。

将slices添加到_update_by_query只是自动化了上述部分中使用的手动过程，创建了子请求，这意味着它有一些特殊之处：

假设你创建了一个没有动态映射的索引，填充了数据，然后添加了一个映射值以从数据中提取更多字段：

PUT test
{
  "mappings": {
    "dynamic": false,   
    "properties": {
      "text": {"type": "text"}
    }
  }
}

POST test/_doc?refresh
{
  "text": "words words",
  "flag": "bar"
}
POST test/_doc?refresh
{
  "text": "words words",
  "flag": "foo"
}
PUT test/_mapping   
{
  "properties": {
    "text": {"type": "text"},
    "flag": {"type": "text", "analyzer": "keyword"}
  }
}

搜索数据将不会找到任何内容：

POST test/_search?filter_path=hits.total
{
  "query": {
    "match": {
      "flag": "foo"
    }
  }
}

{
  "hits" : {
    "total": {
        "value": 0,
        "relation": "eq"
    }
  }
}

但您可以发出一个_update_by_query请求来获取新的映射：

POST test/_update_by_query?refresh&conflicts=proceed
POST test/_search?filter_path=hits.total
{
  "query": {
    "match": {
      "flag": "foo"
    }
  }
}

{
  "hits" : {
    "total": {
        "value": 1,
        "relation": "eq"
    }
  }
}

在向多字段添加字段时，您可以执行完全相同的操作。

请参阅基于URL的访问控制。

为了确保快速响应，如果一个或多个分片失败，多获取API会返回部分结果。更多信息请参见分片失败。

如果在请求URI中指定了一个索引，则请求体中只需要文档ID：

GET /my-index-000001/_mget
{
  "docs": [
    {
      "_id": "1"
    },
    {
      "_id": "2"
    }
  ]
}

您可以使用ids元素来简化请求：

GET /my-index-000001/_mget
{
  "ids" : ["1", "2"]
}

默认情况下，每个文档都会返回_source字段（如果已存储）。 使用_source、_source_include或source_exclude属性来 过滤为特定文档返回的字段。 您可以在请求URI中包含_source、_source_includes和_source_excludes查询参数，以指定在没有每个文档指令时使用的默认值。

例如，以下请求将文档1的_source设置为false以完全排除源，检索文档2的field3和field4，并检索文档3的user字段但过滤掉user.location字段。

GET /_mget
{
  "docs": [
    {
      "_index": "test",
      "_id": "1",
      "_source": false
    },
    {
      "_index": "test",
      "_id": "2",
      "_source": [ "field3", "field4" ]
    },
    {
      "_index": "test",
      "_id": "3",
      "_source": {
        "include": [ "user" ],
        "exclude": [ "user.location" ]
      }
    }
  ]
}

使用 stored_fields 属性来指定您想要检索的存储字段集。任何请求的未存储字段都将被忽略。 您可以在请求 URI 中包含 stored_fields 查询参数，以指定在没有每文档指令时使用的默认值。

例如，以下请求从文档1中检索field1和field2，并从文档2中检索field3和field4：

GET /_mget
{
  "docs": [
    {
      "_index": "test",
      "_id": "1",
      "stored_fields": [ "field1", "field2" ]
    },
    {
      "_index": "test",
      "_id": "2",
      "stored_fields": [ "field3", "field4" ]
    }
  ]
}

以下请求默认从所有文档中检索field1和field2。 这些默认字段会返回给文档1，但对于文档2，它们被覆盖以返回field3和field4。

GET /test/_mget?stored_fields=field1,field2
{
  "docs": [
    {
      "_id": "1"
    },
    {
      "_id": "2",
      "stored_fields": [ "field3", "field4" ]
    }
  ]
}

如果在索引期间使用了路由，您需要指定路由值来检索文档。 例如，以下请求从对应于路由键 key1 的分片中获取 test/_doc/2， 并从对应于路由键 key2 的分片中获取 test/_doc/1。

GET /_mget?routing=key1
{
  "docs": [
    {
      "_index": "test",
      "_id": "1",
      "routing": "key2"
    },
    {
      "_index": "test",
      "_id": "2"
    }
  ]
}

如果请求包含 wait_for_completion=false，Elasticsearch 会执行一些预检操作，启动请求，并返回一个 任务，您可以使用它来取消或获取任务的状态。 Elasticsearch 会在 _tasks/ 处创建此任务的记录文档。

如果你有许多源需要重新索引，通常更好的做法是逐个重新索引，而不是使用通配符模式来选取多个源。这样，如果出现任何错误，你可以通过移除部分完成的源并重新开始来恢复进程。这也使得并行化处理变得相当简单：将需要重新索引的源列表拆分，并在每个列表上并行运行。

一次性bash脚本似乎非常适合这种情况：

for index in i1 i2 i3 i4 i5; do
  curl -HContent-Type:application/json -XPOST localhost:9200/_reindex?pretty -d'{
    "source": {
      "index": "'$index'"
    },
    "dest": {
      "index": "'$index'-reindexed"
    }
  }'
done

将 requests_per_second 设置为任何正的小数（1.4、6、1000 等）以限制 _reindex 发出索引操作批次的速率。请求通过在每个批次中添加等待时间来限制。要禁用限制，请将 requests_per_second 设置为 -1。

节流是通过在批次之间等待来实现的，这样 _reindex 内部使用的 scroll 可以被赋予一个考虑到填充的超时时间。填充时间是批次大小除以 requests_per_second 与写入时间之间的差值。默认情况下，批次大小为 1000，因此如果 requests_per_second 设置为 500：

target_time = 1000 / 500 per second = 2 seconds
wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

由于批处理是以单个 _bulk 请求发出的，较大的批处理大小会导致 Elasticsearch 创建许多请求，然后在开始下一组之前等待一段时间。这种方式是“突发性”的，而不是“平滑”的。

可以使用 _rethrottle API 在正在运行的重新索引过程中更改 requests_per_second 的值：

POST _reindex/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1

任务ID可以通过任务管理API找到。

就像在Reindex API上设置它一样，requests_per_second 可以是-1来禁用限流，或者是任何小数， 比如1.7或12来限制到该水平。加快查询速度的重新限流会立即生效，但减慢查询速度的重新限流会在完成当前批次后生效。这可以防止滚动超时。

重新索引支持切片滚动以并行化重新索引过程。 这种并行化可以提高效率，并提供一种方便的方式将请求分解为更小的部分。

POST _reindex
{
  "source": {
    "index": "my-index-000001",
    "slice": {
      "id": 0,
      "max": 2
    }
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}
POST _reindex
{
  "source": {
    "index": "my-index-000001",
    "slice": {
      "id": 1,
      "max": 2
    }
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

GET _refresh
POST my-new-index-000001/_search?size=0&filter_path=hits.total

{
  "hits": {
    "total" : {
        "value": 120,
        "relation": "eq"
    }
  }
}

POST _reindex?slices=5&refresh
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

POST my-new-index-000001/_search?size=0&filter_path=hits.total

{
  "hits": {
    "total" : {
        "value": 120,
        "relation": "eq"
    }
  }
}

默认情况下，如果 _reindex 看到带有路由的文档，则除非被脚本更改，否则路由将被保留。您可以在 dest 请求上设置 routing 来更改此行为：

例如，您可以使用以下请求将公司名称为cat的所有文档从source复制到dest，并将路由设置为cat。

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
  },
  "dest": {
    "index": "dest",
    "routing": "=cat"
  }
}

重新索引也可以通过指定一个pipeline来使用Ingest pipelines功能，如下所示：

POST _reindex
{
  "source": {
    "index": "source"
  },
  "dest": {
    "index": "dest",
    "pipeline": "some_ingest_pipeline"
  }
}

您可以通过向source添加查询来限制文档。例如，以下请求仅将user.id为kimchy的文档复制到my-new-index-000001中：

POST _reindex
{
  "source": {
    "index": "my-index-000001",
    "query": {
      "term": {
        "user.id": "kimchy"
      }
    }
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

您可以通过设置max_docs来限制处理的文档数量。 例如，此请求将单个文档从my-index-000001复制到 my-new-index-000001：

POST _reindex
{
  "max_docs": 1,
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

在 source 中的 index 属性可以是一个列表，允许您在一个请求中从多个源复制数据。这将复制来自 my-index-000001 和 my-index-000002 索引的文档：

POST _reindex
{
  "source": {
    "index": ["my-index-000001", "my-index-000002"]
  },
  "dest": {
    "index": "my-new-index-000002"
  }
}

您可以使用源过滤来重新索引原始文档中的字段子集。 例如，以下请求仅重新索引每个文档的 user.id 和 _doc 字段：

POST _reindex
{
  "source": {
    "index": "my-index-000001",
    "_source": ["user.id", "_doc"]
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

_reindex 可以用于构建一个带有重命名字段的索引副本。假设你创建了一个包含如下文档的索引：

POST my-index-000001/_doc/1?refresh
{
  "text": "words words",
  "flag": "foo"
}

但您不喜欢名称 flag，并希望将其替换为 tag。 _reindex 可以为您创建另一个索引：

POST _reindex
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "my-new-index-000001"
  },
  "script": {
    "source": "ctx._source.tag = ctx._source.remove(\"flag\")"
  }
}

现在你可以获取新文档：

GET my-new-index-000001/_doc/1

这将返回：

{
  "found": true,
  "_id": "1",
  "_index": "my-new-index-000001",
  "_version": 1,
  "_seq_no": 44,
  "_primary_term": 1,
  "_source": {
    "text": "words words",
    "tag": "foo"
  }
}

您可以使用 _reindex 结合 Painless 来重新索引每日索引，以将新模板应用于现有文档。

假设你有包含以下文档的索引：

PUT metricbeat-2016.05.30/_doc/1?refresh
{"system.cpu.idle.pct": 0.908}
PUT metricbeat-2016.05.31/_doc/1?refresh
{"system.cpu.idle.pct": 0.105}

新的 metricbeat-* 索引模板已经加载到 Elasticsearch 中，但它仅适用于新创建的索引。可以使用 Painless 重新索引现有文档并应用新模板。

下面的脚本从索引名称中提取日期，并创建一个附加了-1的新索引。所有来自metricbeat-2016.05.31的数据将被重新索引到metricbeat-2016.05.31-1。

POST _reindex
{
  "source": {
    "index": "metricbeat-*"
  },
  "dest": {
    "index": "metricbeat"
  },
  "script": {
    "lang": "painless",
    "source": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'"
  }
}

所有来自之前metricbeat索引的文档现在都可以在*-1索引中找到。

GET metricbeat-2016.05.30-1/_doc/1
GET metricbeat-2016.05.31-1/_doc/1

之前的方法也可以与更改字段名称结合使用，以仅将现有数据加载到新索引中，并在需要时重命名字段。

_reindex 可以用于提取源数据的随机子集以进行测试：

POST _reindex
{
  "max_docs": 10,
  "source": {
    "index": "my-index-000001",
    "query": {
      "function_score" : {
        "random_score" : {},
        "min_score" : 0.9    
      }
    }
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

与 _update_by_query 类似，_reindex 支持一个可以修改文档的脚本。与 _update_by_query 不同，该脚本允许修改文档的元数据。这个示例增加了源文档的版本号：

POST _reindex
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "my-new-index-000001",
    "version_type": "external"
  },
  "script": {
    "source": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
    "lang": "painless"
  }
}

正如在 _update_by_query 中一样，您可以设置 ctx.op 来更改在目标上执行的操作：

将 ctx.op 设置为其他任何值将返回错误，同样，设置 ctx 中的任何其他字段也会返回错误。

想象一下可能性！但要小心；你可以改变：

将 _version 设置为 null 或从 ctx 映射中清除它，就像在索引请求中不发送版本一样；它将导致文档在目标中被覆盖，无论目标上的版本或您在 _reindex 请求中使用的版本类型如何。

从远程重新索引支持可配置的SSL设置。这些必须在elasticsearch.yml文件中指定，除了安全设置，这些设置需要在Elasticsearch密钥库中添加。 无法在_reindex请求的主体中配置SSL。

支持以下设置：

如果请求的信息未存储在索引中，如果可能的话，它将会被实时计算。此外，术语向量可以为甚至不存在于索引中的文档计算，而是由用户提供的。

将 term_statistics 设置为 true（默认值为 false）将返回

默认情况下，这些值不会返回，因为词项统计可能会对性能产生严重影响。

将 field_statistics 设置为 false（默认值为 true）将省略：

通过参数 filter，返回的术语也可以根据其 tf-idf 分数进行过滤。这对于找到文档的良好特征向量非常有用。此功能的工作方式与 第二阶段 的 更多类似此查询 类似。请参阅 示例 5 以了解用法。

支持以下子参数：

首先，我们创建一个存储术语向量、有效载荷等的索引：

PUT /my-index-000001
{ "mappings": {
    "properties": {
      "text": {
        "type": "text",
        "term_vector": "with_positions_offsets_payloads",
        "store" : true,
        "analyzer" : "fulltext_analyzer"
       },
       "fullname": {
        "type": "text",
        "term_vector": "with_positions_offsets_payloads",
        "analyzer" : "fulltext_analyzer"
      }
    }
  },
  "settings" : {
    "index" : {
      "number_of_shards" : 1,
      "number_of_replicas" : 0
    },
    "analysis": {
      "analyzer": {
        "fulltext_analyzer": {
          "type": "custom",
          "tokenizer": "whitespace",
          "filter": [
            "lowercase",
            "type_as_payload"
          ]
        }
      }
    }
  }
}

其次，我们添加一些文档：

PUT /my-index-000001/_doc/1
{
  "fullname" : "John Doe",
  "text" : "test test test "
}

PUT /my-index-000001/_doc/2?refresh=wait_for
{
  "fullname" : "Jane Doe",
  "text" : "Another test ..."
}

以下请求返回文档1（John Doe）中字段text的所有信息和统计数据：

GET /my-index-000001/_termvectors/1
{
  "fields" : ["text"],
  "offsets" : true,
  "payloads" : true,
  "positions" : true,
  "term_statistics" : true,
  "field_statistics" : true
}

响应:

{
  "_index": "my-index-000001",
  "_id": "1",
  "_version": 1,
  "found": true,
  "took": 6,
  "term_vectors": {
    "text": {
      "field_statistics": {
        "sum_doc_freq": 4,
        "doc_count": 2,
        "sum_ttf": 6
      },
      "terms": {
        "test": {
          "doc_freq": 2,
          "ttf": 4,
          "term_freq": 3,
          "tokens": [
            {
              "position": 0,
              "start_offset": 0,
              "end_offset": 4,
              "payload": "d29yZA=="
            },
            {
              "position": 1,
              "start_offset": 5,
              "end_offset": 9,
              "payload": "d29yZA=="
            },
            {
              "position": 2,
              "start_offset": 10,
              "end_offset": 14,
              "payload": "d29yZA=="
            }
          ]
        }
      }
    }
  }
}

未显式存储在索引中的词向量会自动即时计算。以下请求返回文档 1 中所有字段的信息和统计数据，即使这些词未在索引中显式存储。请注意，对于字段 text，不会重新生成词。

GET /my-index-000001/_termvectors/1
{
  "fields" : ["text", "some_field_without_term_vectors"],
  "offsets" : true,
  "positions" : true,
  "term_statistics" : true,
  "field_statistics" : true
}

术语向量也可以为人工文档生成，即不为索引中存在的文档生成。例如，以下请求将返回与示例1相同的结果。使用的映射由index决定。

如果动态映射已开启（默认），文档中不在原始映射中的字段将被动态创建。

GET /my-index-000001/_termvectors
{
  "doc" : {
    "fullname" : "John Doe",
    "text" : "test test test"
  }
}

GET /my-index-000001/_termvectors
{
  "doc" : {
    "fullname" : "John Doe",
    "text" : "test test test"
  },
  "fields": ["fullname"],
  "per_field_analyzer" : {
    "fullname": "keyword"
  }
}

{
  "_index": "my-index-000001",
  "_version": 0,
  "found": true,
  "took": 6,
  "term_vectors": {
    "fullname": {
       "field_statistics": {
          "sum_doc_freq": 2,
          "doc_count": 4,
          "sum_ttf": 4
       },
       "terms": {
          "John Doe": {
             "term_freq": 1,
             "tokens": [
                {
                   "position": 0,
                   "start_offset": 0,
                   "end_offset": 8
                }
             ]
          }
       }
    }
  }
}

最后，可以根据tf-idf分数对返回的术语进行过滤。在下面的示例中，我们从具有给定“plot”字段值的人工文档中获取了三个“最有趣”的关键词。请注意，关键词“Tony”或任何停用词都不在响应中，因为它们的tf-idf分数必须太低。

GET /imdb/_termvectors
{
  "doc": {
    "plot": "When wealthy industrialist Tony Stark is forced to build an armored suit after a life-threatening incident, he ultimately decides to use its technology to fight against evil."
  },
  "term_statistics": true,
  "field_statistics": true,
  "positions": false,
  "offsets": false,
  "filter": {
    "max_num_terms": 3,
    "min_term_freq": 1,
    "min_doc_freq": 1
  }
}

响应:

{
   "_index": "imdb",
   "_version": 0,
   "found": true,
   "term_vectors": {
      "plot": {
         "field_statistics": {
            "sum_doc_freq": 3384269,
            "doc_count": 176214,
            "sum_ttf": 3753460
         },
         "terms": {
            "armored": {
               "doc_freq": 27,
               "ttf": 27,
               "term_freq": 1,
               "score": 9.74725
            },
            "industrialist": {
               "doc_freq": 88,
               "ttf": 88,
               "term_freq": 1,
               "score": 8.590818
            },
            "stark": {
               "doc_freq": 44,
               "ttf": 47,
               "term_freq": 1,
               "score": 9.272792
            }
         }
      }
   }
}

您还可以使用 mtermvectors 为请求体中提供的人工文档生成词向量。使用的映射由指定的 _index 决定。

POST /_mtermvectors
{
   "docs": [
      {
         "_index": "my-index-000001",
         "doc" : {
            "message" : "test test test"
         }
      },
      {
         "_index": "my-index-000001",
         "doc" : {
           "message" : "Another test ..."
         }
      }
   ]
}