前言

博客：http://blog.healerjean.com

一、索引 `API`

索引操作成功执行时，successful 至少是 1。

说明：默认情况下，当索引操作成功返回时，有可能一些replica 还没有开始或完成，因为只要 primary成功执行，就会返回，这种行为可以调整。其实这样做的目的是快速响应，一般的场景并不需要等待所有分片都完成索引操作再返回，除非对数据安全要求极高的场景。

`key`	说明
`_shards`	头提供有关索引操作的复制过程的信息
`total`	指示索引操作应在多少个分片 (主 `primary` 和 `replica` )上执行
`successful`	指示索引操作成功执行的分片数
`failed`	在副本分片上索引操作失败的情况下包含与复制相关的错误的数组。

入参：

PUT twitter/_doc/1
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}

出参：

{
    "_shards" : {
        "total" : 2,
        "failed" : 0,
        "successful" : 2
    },
    "_index" : "twitter",
    "_type" : "_doc",
    "_id" : "1",
    "_version" : 1,
    "_seq_no" : 0,
    "_primary_term" : 1,
    "result" : "created"
}

1、自动创建索引

当索引文档时，如果索引不存在，会自动创建索引。索引操作还将创建一个动态映射(如果尚未存在)。默认情况下，如果需要，新字段和对象将自动添加到映射定义中。

自动创建索引由 action.auto_create_index 设置控制。此设置默认为 true，这意味着索引总是自动创建的。也可以设置只有匹配特定模式的索引才允许自动创建索引，方法是将此设置的值更改为这些匹配模式的逗号分隔列表。还可以通过在列表中的模式前面加上 + 或 - ，明确地允许和禁止使用它。最后，通过将此设置更改为 false，可以完全禁用它。可以在 elasticsearch.yml 中配置，也可以通过如下URL 配置。下面是几个示例。

1）特定模式才允许创建

只允许自动创建名为 twitter、index 10 的索引，不允许创建其他与 index1* 匹配的索引

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

2）完全禁用索引的自动创建

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

3）允许使用任何名称自动创建索引

是默认设置

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

4）索引存在 ( 覆盖&失败 )

索引操作还接受一个 op_type 参数，它可以用来强制 create 操作，允许 put-if-absent 的行为。使用 create 时，如果索引中已存在具有该 ID的文档，则索引操作将失败。

⬤ 默认情况下，当文档存在时直接覆盖。

⬤ 当索引文档时，如果带有 &op_type=true 参数，明确指明是创建文档，如果文档存在就报错。

入参：

PUT twitter/_doc/1?op_type=create
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}

出参：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "version_conflict_engine_exception",
        "reason" : "[1]: version conflict, document already exists (current version [1])",
        "index_uuid" : "d9PDPxM-Tja9Hb1k1jsEbA",
        "shard" : "0",
        "index" : "twitter"
      }
    ],
    "type" : "version_conflict_engine_exception",
    "reason" : "[1]: version conflict, document already exists (current version [1])",
    "index_uuid" : "d9PDPxM-Tja9Hb1k1jsEbA",
    "shard" : "0",
    "index" : "twitter"
  },
  "status" : 409
}

2、`ID` 自动生成

索引操作可以在不指定 ID 的情况下执行。在这种情况下，将自动生成一个 ID。此外，op_type将自动设置为create。

3、路由

默认情况下，碎片放置(或路由)是通过使用文档 id 值的散列来控制的。为了实现更明确的控制，可以使用路由参数直接在每个操作的基础上指定路由器使用的散列函数的值。

注意：在设置显式 mapping 时，可以选择使用 routing 字段从文档本身提取路由值。如果定义了 mapping 的 _routing 值并将其设置为必需，则如果没有提供可提取路由值，索引操作将失败。

POST /twitter/_doc?routing=kimchy
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}

4、分发

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

5、等待活动分片

为了兼顾系统写入的效率和可靠性，可以将索引操作配置为在继续操作之前等待一定数量的活动分片。如果所需数量的活动分片不可用，则写入操作必须等待并重试，直到所需分片已启动或发生超时。默认情况下，写入操作仅在继续之前等待 primary 完成 (即 wait_for_active_shards = 1 ) 。

1、可以通过设置 index.write.wait_for_active_shards 来动态重写此默认值。

2、要更改每个请求操作的此行为，可以使用 wait_for_active_shards 请求参数。wait_for_active_shards 的有效值是任何正整数，最多为分片总数。指定负值或大于分片数的数字将引发错误。

例如：假设有一个由 3 个节点 ( A 、B 和 C ) 组成的集群，并且创建了一个索引 index ，其中副本数设置为 3 (结果是共 4 个分片（但是实际上不存在4个分配）)。如果我们尝试索引操作

1、默认情况下，该操作将仅确保 primary 在继续操作之前可用。这意味着，即使 B 和 C 发生故障，并且 A 托管了 primary ，索引操作仍然继续进行。

2、如果在请求中将 wait_for_active_shards 设置为 3 ( 并且所有 3 个节点都已启动)，那么索引操作将需要3个活动的 shard 副本才能继续。这一要求应该满足，因为集群中有 3 个活动的节点，每个节点都保存一个 shard 副本。但是，如果我们将 wait_for_active_shards 设置为 all ( 或设置为 4，这是相同的)，则索引操作将不会继续，因为索引中没有每个 shard 的所有4个副本。除非在集群中出现新节点以承载分片的第四副本，否则操作将超时

6、`detect_noop` 参数

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

二、`GET` `API`

1、根据`id` 查询索引文档

GET API 允许根据其 ID 从索引中获取 JSON 文档。以下示例从 twitter 的索引中获取 ID 值为 1 的 JSON文档:

入参：

GET twitter/_doc/1

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
  }
}

2、`head` 检查文档是否存在

场景：不存在

入参：

HEAD twitter/_doc/0

出参：

{
    "statusCode": 404,
    "error": "Not Found",
    "message": "404 - Not Found"
}

场景：存在

入参：

HEAD twitter/_doc/1

出参：

200 - OK

3、实时性

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

4、字段选择

1）`_source_includes` 和 `_source_excludes`

如果只需要完整 _source 中的一个或两个字段，可以使用 _source_includes 和 _source_excludes 参数来包含或排除字段。这对于大型文档尤其有用，因为部分字段检索可以节省网络开销。两个参数都采用逗号分隔的字段列表或通配符表达式。

入参：

GET twitter/_doc/1?_source_includes=*.date&_source_excludes=entities

2）`_source`

如果只需指定 include ，可以使用较短的表示法:

入参：

GET twitter/_doc/1?_source=*.id,retweeted

3）直接获取 `_source`

可以使用/{index}/_source/{id} 仅获取文档的 source 字段，而不返回任何其他内容，用法如下:

4）只返回 `_source`

入参：

GET twitter/_source/1

出参：

{
  "counter" : 1,
  "tags" : [
    "red"
  ]
}

5）筛选 `_source` 字段

入参：

GET twitter/_source/1/?_source_includes=*&_source_excludes=entities

出参：

{
  "counter" : 1,
  "tags" : [
    "red"
  ]
}

6）检查 `_source` 是否存在

入参：

HEAD twitter/_source/1

出参：

200 - OK

3.6、`routing` 路由

如果在索引文档时使用了路由参数，搜索时也应该加上该参数。当然搜索时不加也是可以的，这会降低性能。如下示例，指定了路由:

GET twitter/_doc/2?routing=user1

3.7、`preference` 参数

preference 参数的作用是控制优先从哪个 shard 获取数据。默认情况下是随机选择的。一般情况下可以设置为_local，这可以降低网络开销。

⬤ local :如果可能，该操作将更倾向于在本地分配的分片上执行。

⬤ Custom (string) value: 自定义值将用于保证相同的分片将用于相同的自定义值。当在不同的刷新状态下击中不同的分片时，这有助于“跳跃值”。示例值可以是 Web 会话 ID 或用户名之类的东西。

3.8、`refresh` 参数

可以将 refresh 参数设置为 true，以便在GET 操作之前刷新相关的分片并使其可见。将其设置为 true 应慎重考虑，因为这可能导致系统负载过重，并减慢索引速度。

3.9、分发

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

1.10、存储字段

GET 操作允许指定一组存储字段 ( store 属性值为 true )，这些字段将通过传递 stored_fields 参数返回。如果未存储请求的字段，则将忽略它们。例如，首先建立以下映射

入参：

PUT twitter
{
   "mappings": {
       "properties": {
          "counter": {
             "type": "integer",
             "store": false
          },
          "tags": {
             "type": "keyword",
             "store": true
          }
       }
   }
}

PUT twitter/_doc/1
{
    "counter" : 1,
    "tags" : ["red"]
}

1.10.1、检索数据

入参：

GET twitter/_doc/1?stored_fields=tags,counter

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "fields" : {
    "tags" : [
      "red"
    ]
  }
}

4、删除 `API`

4.1、根据特定文档 `Id` 删除

删除 API ( DELETE ) 允许根据特定文档的 ID 从其中删除 JSON 文档。下面的示例将 ID为1的JSON文档从twitter 索引中删除:

入参：

DELETE /twitter/_doc/1

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 2,
  "result" : "deleted",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}

4.2、查询删除

4.2.1、查询匹配并删除

查询删除 API ( _delete_by_query )是对每个与查询匹配的文档执行删除操作。

删除过程：_delete_by_query 操作在启动时会获取索引的一个快照，并使用内部版本控制删除找到的内容。这意味着，如果文档在获取快照的时间和处理删除请求的时间之间发生更改，则会出现版本冲突。当版本匹配时，文档将被删除。

具体过程：

1、在_delete_by_query 执行期间，将按顺序执行多个搜索请求，以查找所有要删除的匹配文档。每当找到一批文档时，都会执行相应的批量请求来删除所有这些文档。

2、如果搜索或批量请求被拒绝， _delete_by_query 按照默认策略重试被拒绝的请求(最多10次，指数下降)。达到最大重试次数限制会导致 _delete_by_query 中止，并在响应的failures中返回所有失败信息。

3、已执行的删除操作仍然保持不变。换句话说，操作不会回滚，只会中止。

4、当第一个失败导致中止时，由失败的批量请求返回的所有失败信息都会 在failures 元素中返回，因此，可能会有相当多失败的实体。

4.2.1.1、简单的查询删除

入参：

POST twitter/_delete_by_query
{
  "query": { 
    "match": {
      "name": "HealerJean"
    }
  }
} 

出参：

{
  "took" : 34,
  "timed_out" : false,
  "total" : 1,
  "deleted" : 1,
  "batches" : 1,
  "version_conflicts" : 0,
  "noops" : 0,
  "retries" : {
    "bulk" : 0,
    "search" : 0
  },
  "throttled_millis" : 0,
  "requests_per_second" : -1.0,
  "throttled_until_millis" : 0,
  "failures" : [ ]
}

4.2.1.2、拒绝版本冲突中止

如果不想因版本冲突而让它们中止，那么在 URL 上设置 conflicts = proceed 或在请求正文中设置conflicts:proceed

举例：从 twitter 索引中删除 tweet

入参：

POST twitter/_delete_by_query?conflicts=proceed
{
 
  "query": {
    "match_all": {}
  }
}
 

4,2.1.3、一次删除多个索引文档

入参：

POST twitter,blog/_delete_by_query
 
{
  "query": {
    "match_all": {}
  }
}
 

4,2.1.4、`routing` 路由

如果提供了 routing ，则路由将复制到滚动( scroll ) 查询中，并将操作限制在与该路由值匹配的分片上，如下示例:

入参：

POST twitter/_delete_by_query?routing=1
 
{
 
  "query": {
    "range" : {
        "age" : {
           "gte" : 10
        }
    }
  }
 
}

4,2.1.5、`scroll_size` 滚动批次

默认情况下，_delete_by_query 查询使用的滚动批次大小为 1000。可以使用scroll_size 参数更改批次大小

入参：

POST twitter/_delete_by_query?scroll_size=5000
 
{
    "query": {
        "term": {
            "user": "kimchy"
        }
    }
}

4.2.2、`URL` 参数

除了标准参数 ( 如 pretty ) 外，_delete_by_query API 还支持 refresh 、 wait_for_completion 、 wait_for_active_shards 、 timeout 和 scroll。

4.2.2.1、`refresh`

发送带有 refresh 参数的请求，将在请求完成后刷新涉及的所有分片。这与 DELETE API 的 refresh 参数不同，后者只会刷新接收到删除请求的分片。同时，它不支持 wait_for 参数。

4.2.2.2、`wait_for_completion`

如果请求包含 wait_for_completion = false 设置，那么 Elasticsearch 将执行一些预检查。启动请求，然后返回一个Task 以取消或获取任务的状态。

Elasticsearch 还将在 .tasks/task/${taskId} 索引中创建此任务的记录文档，用户可以根据需要保留或删除创建的文档，完成后删除它。这样 Elasticsearch 可以回收它使用的空间。

4.2.2.3、`wait_for_active_shards` & `timeout`

⬤ wait_for_active_shards 参数用来控制在继续执行请求之前必须激活多少个分片或副本。

⬤ timeout 参数用来控制每个写请求等待不可用分片变为可用的时间。

这两个参数在批量 API 中的工作方式完全相同。由于 _delete_by_query 使用 scroll 搜索，还可以指定 scroll 参数来控制“搜索上下文”保持活动的时间，例如 scroll = 10m 。默认为 5 分钟。

4.2.24、`requests_per_second`

requests_per_second 参数可以设置为任何正十进制数(1.4、 6、1000等)，并通过用等待时间填充每个批来限制通过查询发出删除操作批的速率。通过将 requests_per_second 设置为-1，可以禁用限制。

此限制是通过在批之间等待来完成的，这样就可以为 ` _delete_by_query 内部使用的滚动指定一个超时时间。这个时间是批处理大小除以requests_per_second 与写入时间之差。默认情况下，批处理大小为 1000 ，因此如果 requests_per_second 设置为 500` ，计算方式如下:

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

注意：由于该操作是作为单个 _bulk 请求发出的，因此较大的批大小将导致 Elasticsearch 创建多个请求，并在启动下一个操作之前等待一段时间，这是不平稳的。默认值为-1。

4.2.3、返回体

{
    "took": 147,
    "timed_out": false,
    "total": 119,
    "deleted": 119,
    "batches": 1,
    "version_conflicts": 0,
    "noops": 0,
    "retries": {
        "bulk": 0,
        "search": 0
    },
    "throttled_millis": 0,
    "requests_per_second": -1,
    "throttled_until_millis": 0,
    "failures": []
}

`key`	说明
`took`	整个操作从开始到结束的毫秒数。
`timed_out`	如果在执行_delete_by_query期间执行的任何请求超时，则此标志为true
`total`	成功处理的文档数
`deleted`	成功删除的文档数
`batches`	分了多少批次执行
`version_conflicts`	版本冲突的文档数。
`noops`	对于_delete_by_query，此字段始终等于零。
`retries`	操作尝试的重试次数。
`bulk`	重试的批量操作数，
`search`	重试的搜索操作数。
`throttled_millis`	请求休眠以符合 `requests_per_second` 参数设置的毫秒数。
`requests_per_second`	每秒有效执行的请求数
`throttled_until_millis`	在`_delete_by_query` 响应中，此字段应始终等于零。它只有在使用 `_tasks` `API` 时才有意义，在该 `API` 中，它指示下一次将再次执行请求的等待时间(从 `epoch`开始以毫秒为单位)。
`failures`	⬤ 如果请求处理中有任何不可恢复的错误，则记录到这个失败数组中。如果不为空，那么请求会因为这些失败而中止。 ⬤ `_delete_by_query`是使用批处理实现的，任何失败都会导致整个过程中止，但当前批处理中的所有失败都会收集到此数组中。可以使用conflicts选项防止覆盖写入在版本冲突时中止。

4.2.4、任务 `API`

可以使用任务 API ( ` _tasks ` ) 获取任何正在运行的 _delete_by_query 的状态:

入参：

GET _tasks?detailed=true&actions=*/delete/byquery

解析：返回结果中的 status 字段，包含任务的实际状态。 total 字段是重新索引预期执行的操作总数。可以通过updated 、 created 和 deleted 的字段的加总值来估计进度。当它们的总和等于合计字段时，请求将完成。

出参：

{
    "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": ""
                }
            }
        }
    }
}

4.2.4.1、使用任务`ID`，可以直接查找任务:

此 API 的优点是，它可以与 wait_for_completion = false 一起使用，以透明地返回已完成任务的状态。

如果任务已完成，并且在其上设置了 wait_for_completion = false ，那么它将返回 results 或 error 字段。此功能的成本是创建的新的文档，需要手动来删除创建的文档。

入参：

GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619

4.2.5、取消任务 `API`

可以使用取消任务 API ( _cancel ) 取消 _delete_by_query 进程:

可以使用任务 API 找到任务ID。取消应该很快发生，但可能需要几秒钟。上面的任务状态 API 将继续列出相应的任务，直到该任务检查它是否已被取消并自行终止。

入参：

POST_tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel

4.2.6、动态调整 `API`

requests_per_second 的值可以在运行时使用动态调整 API ( _rethrottle )进行更改:

1、可以使用任务API找到任务ID。就像在 _delete_by_query API上设置它一样， requests_per_second 可以置为-1以禁用限制，也可以是任何十进制数(如1.7或12)以限制到该级别。

2、加快查询速度的重新标记将立即生效，但减慢查询速度的重新标记将在完成当前批处理后生效。这样可以防止滚动超时。

入参：

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

4.2.7、切片

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

4.2.7.1、人工切片

通过为每个请求提供一个切片 ID 和切片总数，进行人工切片:

入参：

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


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

验证是否生效，入参：

GET _refresh
POST twitter/_search?size=0&q=extra:test&filter_path=hits.total

4.2.7.2、自动切片

可以让 _delete_by_query 过程自动并行化，方法是使用“切片滚动”机制对 _id 进行切片

1、使用slices指定要使用的切片数，把 slices 设置为 auto 将允许 Elasticsearch 选择要使用的切片数。此设置将会为每个分片使用一个切片，直至达到某个限制。

2、如果存在多个源索引，它将根据具有最小分片数的索引选择切片数。通过在_delete_by_query API中添加 slices 会自动执行切片过程。

入参：

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

验证是否生效，入参：

POST twitter/_search?size=0&q=extra:test&filter_path=hits.total

4.2.7.3、切片数量选择

⬤ 如果使用自动切片机制，将为大多数索引选择一个合理的切片数字。

⬤ 如果要手动切片或调整自动切片，请遵循以下准则:

1、当切片数等于索引中的分片数时，查询性能最佳。如果该数字很大(例如500)，请选择一个较小的数字，因为太多的切片会影响性能。设置高于分片数量的切片通常不会提高效率并增加开销。

2、删除性能随可用资源的切片数线性扩展。

3、查询或删除性能是否支配运行时间取决于重新索引的文档和集群资源。

5、更新 `API`

5.1、使用 `script` 更新

5.2、部分字段更新

更新 API 还支持传递部分文档字段进行更新，在内部完成合并 (简单的递归合并、对象的内部合并、替换核心“键值”和数组)。要完全替换现有文档，应使用索引 API。以下实例，通过部分更新机制将现有文档添加新字段:

注意：如果同时指定了 doc 和 script，则忽略 doc。

入参：

POST /animal/_update/1?pretty
{
    "doc": {
        "name": "熊猫update"
    }
}

5.3、避免无效更新

⬤ 如果指定了 doc，则其值将与现有的 _source 合并。默认情况下，不更改任何内容的更新并不会真正执行并返回 “result “: “noop”

⬤ 因为传入的 name 值和 source中的一样，则忽略整个更新请求。如果请求被忽略，响应中的 result元素将返回 noop。

入参：

POST /animal/_update/1?pretty
{
    "doc": {
        "name": "熊猫update"
    }
}

出参：

{
  "_index" : "animal",
  "_id" : "1",
  "_version" : 17,
  "result" : "noop",
  "_shards" : {
    "total" : 0,
    "successful" : 0,
    "failed" : 0
  },
  "_seq_no" : 33,
  "_primary_term" : 3
}

5.4、`upsert` 元素

如果文档不存在，则 upsert 元素的内容将作为新文档插入。如果文档确实存在，则将执行 script:

5.4.1、文档不存在，则创建

入参：

POST test/_update/2
{
    "script" : {
        "inline": "ctx._source.counter += params.count",
        "lang": "painless",
        "params" : {
            "count" : 4
        }
    },
    "upsert" : {
        "counter" : 1
    }
}

出参：

解析：因为ID为2的文档不存在，可以看出执行了创建操作 (“result”:”created”)。

{
  "_index" : "test",
  "_id" : "2",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

5.4.2、文档存在，则执行 `Script`

入参：

POST test/_update/2
{
    "script" : {
        "inline": "ctx._source.counter += params.count",
        "lang": "painless",
        "params" : {
            "count" : 4
        }
    },
    "upsert" : {
        "counter" : 1
    }
}

出参：

{
  "_index" : "test",
  "_id" : "2",
  "_version" : 4,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 3,
  "_primary_term" : 1
}

5.5、查询更新

查询更新 API ( _update_by_query ) 的功能是在不更改源的情况下对索引中的每个文档执行更新。这对于获取新属性或其他联机映射更改很有用。示例如下:

查询更新过程：

1、_update_by_query 在索引启动时获取索引的快照，并使用 internal 版本控制索引它。这意味着如果文档在拍摄快照的时间和处理索引请求之间发生更改，则会出现版本冲突。当版本匹配时，文档会更新，版本号会递增。

2、所有更新和查询失败都会导致 _update_by_query 中止并 failures 在响应中返回。已执行的更新仍然存在。换句话说，该过程不会回滚，只会中止。

4、当第一个失败导致中止时，失败的批量请求返回的所有失败都将在failures元素中返回; 因此，可能存在相当多的失败实体。

5、如果您只想计算版本冲突，不要导致_update_by_query 中止，您可以 conflicts = proceed 在 URL 或 "conflicts": "proceed" 请求正文中设置。

5.5.1、`URL` 参数

除了标准的参数，如pretty，此更新通过查询API也支持 refresh， wait_for_completion ， wait_for_active_shards ， timeout 和scroll。

5.5.1.1、`refresh`

发送将在请求完成时更新正在更新的索引中的所有分片。这与 Index API 的 refresh 参数不同，后者仅导致接收新数据的分片被编入索引。

5.5.1.2、`wait_for_completion`

如果请求包含 wait_for_completion = false，那么 Elasticsearch 将执行一些预检查，启动请求，然后返回一个 Task，以取消或获取任务的状态。Elasticsearch 还将在. asks / task / ${taskId} . 索引中创建此任务的记录文档，可以根据需要保留或删除创建的文档。完成后删除它，这样 Elasticsearch 可以回收它使用的空间。

5.5.1.3、`wait_for_active_shards` & `timeout`

⬤ wait_for_active_shards 控制在继续执行请求之前必须激活多少个shard 副本。

⬤ timeout 控制每个写请求等待不可用分片变为可用分片的时间。

这两个参数在 Bulk API中的工作方式完全相同。由于 _update_by_query 操作使用滚动搜索，还可以指定 scroll 参数来控制 “搜索上下文”保持活动的时间，例如 scroll = 10m 。默认为5分钟。

5.5.1.4、`requests_per_second`

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：

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

5.5.2、请求体

JSON 响应如下

{
  "took" : 147,
  "timed_out": false,
  "total": 5,
  "updated": 5,
  "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,
  "failures" : [ ]
}:

· :

· :。 · :。 · :。 · :。 · :。 · :。

· :。bulk是重试的批量操作数， search是重试的搜索操作数。

5.5.3、任务API

同查询删除任务API

5.5.4、取消任务API

同查询删除取消任务API

5.5.5、动态调整API

同查询删除动态调整API

5.5.6、切片

同查询删除动态调整API

6、`MGet` `API`

MGet API ( _mget ) 基于单个索引、类型(可选)和 ID (可能还有路由)返回多个文档。响应包括一个 docs数组，其中包含与原始 ` _mget 请求相对应的所有已提取文档(如果特定Get 失败，则在响应中包含此错误的对象)。成功的 Get 的结构与Get AP`I提供的文档在结构上类似。示例如下:

6.1、普通查询

入参：

GET _mget
{
    "docs": [
        {
            "_index": "example",
            "_id": "1"
        },
        {
            "_index": "example",
            "_id": "2"
        },
        {
            "_index": "example_test",
            "_id": "1"
        },
        {
            "_index": "example_test",
            "_id": "2"
        }
    ]
}

6.2、指定索引查询

_mget 请求也可以用于指定索引(在这种情况下，主体中不需要它)

入参：

GET test/_doc/_mget
{
    "docs": [
        {
            "_id": "1"
        },
        {
            "_id": "2"
        },
        {
            "_id": "1"
        },
        {
            "_id": "2"
        }
    ]
}

6.2.1、简化查询

可以直接使用 ids 元素来简化请求:

入参：

GET test/_mget
{
    "ids": ["1", "2"]
}

6.3、`_source` 过滤

默认情况下，将为每个文档返回_source字段(如果已存储)。与 Get API类似，可以使用 _source 参数仅检索 _source 的部分内容 ( 或者根本不检索 ) ，还可以使用 URL 参数 _source 、 _source_includes 和 _source_excludes 指定默认值。示例如下:

入参：

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"]
            }
        }
    ]
}

6.4、存储字段

可以为每个要获取的文档指定检索特定存储字段( store 属性为 true )，类似于 Get API 的 stored_fields 参数。例如:

6.4.1、请求体指定

入参：

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

6.4.2、`URL` 中指定

可以在查询字符串中指定 stored_fields 参数作为默认值，应用于所有文档

入参：

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

6.5、路由

可以将路由值作为参数

举例：

1、文档 test/_doc/2 将从路由键key1 对应的分片中获取，

2、文档 test/_doc/1 将从路由键 key2对应的分片中提取，因为 test/_doc/2 没有单独指定路由。

入参：

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

7、`bulk` 批量操作

批量操作API ( _bulk ) 可以在单个 API 调用中执行多个索引和删除操作。这可以大大提高索引速度

⬤ bulk api 对 json 的语法，有严格的要求，每个 json 串不能换行，只能放一行，同时一个 json 串和一个 json 串之间，必须有一个换行

⬤ bulk 操作中，任意一个操作失败，是不会影响其他的操作的，但是在返回结果里，会告诉你异常日志

⬤ bulk size 最佳大小：bulk request 会加载到内存里，如果太大的话，性能反而会下降，因此需要反复尝试一个最佳的 bulk size-。一般从1000-5000条数据开始，尝试逐渐增加。另外，如果看大小的话，最好是在5-15MB 之间。

7.1、简单操作

入参：

POST _bulk
{"delete":{"_index":"megacorp","_id":30}}
{"create":{"_index":"megacorp","_id":5}}
{"first_name":"John","last_name":"Smith","age":25,"about":"I love to go rock climbing","interests":["sports","music"]}
{"create":{"_index":"megacorp","_id":6}}
{"first_name":"John","last_name":"Smith","age":25,"about":"I love to go rock climbing","interests":["sports","music"]}
{"index":{"_index":"megacorp","_id":7}}
{"first_name":"John","last_name":"Smith","age":25,"about":"I love to go rock climbing","interests":["sports","music"]}
{"index":{"_index":"megacorp","_id":8}}
{"first_name":"John","last_name":"Smith","age":25,"about":"I love to go rock climbing","interests":["sports","music"]}
{"update":{"_index":"megacorp","_id":1}}
{"doc":{"age":55}}

出参：

{
  "took" : 29,
  "errors" : true,
  "items" : [
    {
      "delete" : {
        "_index" : "megacorp",
        "_id" : "30",
        "_version" : 1,
        "result" : "not_found",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 5,
        "_primary_term" : 1,
        "status" : 404
      }
    },
    {
      "create" : {
        "_index" : "megacorp",
        "_id" : "5",
        "status" : 409,
        "error" : {
          "type" : "version_conflict_engine_exception",
          "reason" : "[5]: version conflict, document already exists (current version [1])",
          "index_uuid" : "n8I5TI3SQDuVuFoLuPxvnw",
          "shard" : "0",
          "index" : "megacorp"
        }
      }
    },
    {
      "create" : {
        "_index" : "megacorp",
        "_id" : "6",
        "status" : 409,
        "error" : {
          "type" : "version_conflict_engine_exception",
          "reason" : "[6]: version conflict, document already exists (current version [1])",
          "index_uuid" : "n8I5TI3SQDuVuFoLuPxvnw",
          "shard" : "0",
          "index" : "megacorp"
        }
      }
    },
    {
      "index" : {
        "_index" : "megacorp",
        "_id" : "7",
        "_version" : 2,
        "result" : "updated",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 6,
        "_primary_term" : 1,
        "status" : 200
      }
    },
    {
      "index" : {
        "_index" : "megacorp",
        "_id" : "8",
        "_version" : 2,
        "result" : "updated",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 7,
        "_primary_term" : 1,
        "status" : 200
      }
    },
    {
      "update" : {
        "_index" : "megacorp",
        "_id" : "1",
        "status" : 404,
        "error" : {
          "type" : "document_missing_exception",
          "reason" : "[1]: document missing",
          "index_uuid" : "n8I5TI3SQDuVuFoLuPxvnw",
          "shard" : "0",
          "index" : "megacorp"
        }
      }
    }
  ]
}

7.2、指定索引操作

如果只是操作同一个索引可以想 mget 一样指定索引

入参：

POST /megacorp/_bulk
{"delete":{"_id":30}}
{"delete":{"_id":31}}
{"delete":{"_id":32}}

7.3、路由

每个批量项目都可以使用 routing 字段传递路由值。它会根据 _routing映射自动跟踪索引和删除操作的行为。

7.4、批量更新

当使用更新操作时，retry_on_conflict 可以用作操作本身(不在额外的有效负载行中)中的字段，以指定在发生版本冲突时应重试更新的次数。

Update 操作支持以下选项 :doc (部分文档)、upsert、 doc_as_upsert、script、params用于脚本)、lang(用于脚本) 和_source。更新操作示例如下:

POST _bulk
{ "update" : {"_id" : "1", "_index" : "index1", "retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"} }
{ "update" : { "_id" : "0", "_index" : "index1", "retry_on_conflict" : 3} }
{ "script" : { "source": "ctx._source.counter += params.param1", "lang" : "painless", "params" : {"param1" : 1}}, "upsert" : {"counter" : 1}}
{ "update" : {"_id" : "2", "_index" : "index1", "retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"}, "doc_as_upsert" : true }
{ "update" : {"_id" : "3", "_index" : "index1", "_source" : true} }
{ "doc" : {"field" : "value"} }
{ "update" : {"_id" : "4", "_index" : "index1"} }
{ "doc" : {"field" : "value"}, "_source": true}

8、`Term` 向量

Term 向量 ( Term Vectors ) 用来存储文档字段的 Term 信息(字段文本分词得到的词条)和统计信息。文档可以存储在索引中，也可以由用户人工提供。Term 向量在默认情况下是实时的。这可以通过将 realtime 参数设置为 false来更改。

8.1、返回值

可以请求三种类型的值 : Term 信息、Term 统计信息和字段统计信息。默认情况下，返回所有字段的所有 Term信息和字段统计信息，但不返回Term统计信息。

8.1.1、`Term` 信息

⬤ Term 的频率 ( 在对应字段中 ) ，这部分信息是始终返回的。

⬤ Term 的位置，需要设置 positions : true。

⬤ Term 开始和结束的偏移量，需要设置 offsets : true。

⬤ Term Payloads (有效载荷，请参考Lucene相关文档)，需要设置payloads : true。

注意：如果请求的信息没有存储在索引中，如果可能它将被即时计算。另外，对于甚至不存在于索引中但由用户提供的文档，也可以计算词条向量。

警告：开始与结束的偏移量假设 UTF - 16 编码被使用。如果要使用这些偏移量来从原始文本中获取词条，则应确保使用UTF - 16 对正在使用的子字符串进行编码。

Term 信息在 Elasticsearch 中的具体存储格式如图

8.1.2、字段统计信息

字段统计信息默认是返回的，可以将 field_statistics 设为 false 来禁止返回。字段统计信息包括如下三方面的内容:

⬤ 文档计数，即多少个文档存在这个字段值。

⬤ 文档频率总和，即此字段中所有 Term 的文档频率总和。

⬤ Term 频率总和，即该字段中每个 Term 的总项频率之和

8.1.3、`Term` 过滤

使用参数 filter ，还可以根据 tf - idf 分数过滤返回的 Term。这有助于找出文档的特征向量。此功能的工作方式更类似于此查询的第二阶段。

样例：在下面的示例中，从具有给定 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",
   "_type": "movies",
   "_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
            }
         }
      }
   }
}

8.1.3.1、子参数

key	说明
`max_num_terms`	每个字段返回的最大`Term`数。默认值为25。也就是只有一个字段最多 `25` 个Term
`min_term_freq`	忽略源文档中低于此频率的单词。默认值为1。
`max_term_freq`	忽略源文档中超过此频率的单词。默认为无限大
`min_doc_freq`	忽略文档频率低于这个值的 `Term`。默认值为1。
`max_doc_freq`	忽略文档频率高于这个值的`Term`。默认值为1。
`min_word_length`	忽略低于此值的`Term`。默认值为0。
`max_word_length`	忽略高于此值的`Term`。默认值为无穷大。

8.2、行为分析

Term 和 Field 统计信息是不准确的，仅检索请求文档所在的分片的信息，而删除的文档不考虑在内。

因此，Term 和 Field 统计信息仅用作相对测量，而绝对数值在此上下文中没有意义。默认情况下，当请求人工文档的 Term 向量时，将随机选择一个分片来获取统计信息。使用 routing 只命中特定的分片。

8.2.1、返回存储词条向量

8.2.1.1、创建一个存储词条向量、有效载荷等的索引

入参：

PUT /twitter
{ "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"
          ]
        }
      }
    }
  }
}

出参：

{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "twitter"
}

8.2.1.2、添加一些文档：

入参：

PUT /twitter/_doc/1
{
  "fullname" : "John Doe",
  "text" : "twitter test test test "
}
 
PUT /twitter/_doc/2
{
  "fullname" : "Jane Doe",
  "text" : "Another twitter test ..."
}

出参：

# PUT /twitter/_doc/1
{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

# PUT /twitter/_doc/2
{
  "_index" : "twitter",
  "_id" : "2",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}

8.2.1.3、返回`Id`=1 中字段`text`的所有信息和统计信息：

入参：

GET /twitter/_termvectors/1
{
  "fields" : ["text"],
  "offsets" : true,
  "payloads" : true,
  "positions" : true,
  "term_statistics" : true,
  "field_statistics" : true
} 

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 2,
  "found" : true,
  "took" : 3,
  "term_vectors" : {
    "text" : {
      "field_statistics" : {
        "sum_doc_freq" : 6,
        "doc_count" : 2,
        "sum_ttf" : 8
      },
      "terms" : {
        "test" : {
          "doc_freq" : 2,
          "ttf" : 4,
          "term_freq" : 3,
          "tokens" : [
            {
              "position" : 1,
              "start_offset" : 8,
              "end_offset" : 12,
              "payload" : "d29yZA=="
            },
            {
              "position" : 2,
              "start_offset" : 13,
              "end_offset" : 17,
              "payload" : "d29yZA=="
            },
            {
              "position" : 3,
              "start_offset" : 18,
              "end_offset" : 22,
              "payload" : "d29yZA=="
            }
          ]
        },
        "twitter" : {
          "doc_freq" : 2,
          "ttf" : 2,
          "term_freq" : 1,
          "tokens" : [
            {
              "position" : 0,
              "start_offset" : 0,
              "end_offset" : 7,
              "payload" : "d29yZA=="
            }
          ]
        }
      }
    }
  }
}

8.2.1.4、自动生成词条向量

未明确存储在索引中的词条向量将自动计算。以下请求返回文档 1 中字段的所有信息和统计信息，即使词条尚未明确存储在索引中。请注意，对于字段 text，术语不会重新生成。

入参：

GET /twitter/_termvectors/1
{
  "fields" : ["text", "some_field_without_term_vectors"],
  "offsets" : true,
  "positions" : true,
  "term_statistics" : true,
  "field_statistics" : true
} 

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 2,
  "found" : true,
  "took" : 2,
  "term_vectors" : {
    "text" : {
      "field_statistics" : {
        "sum_doc_freq" : 6,
        "doc_count" : 2,
        "sum_ttf" : 8
      },
      "terms" : {
        "test" : {
          "doc_freq" : 2,
          "ttf" : 4,
          "term_freq" : 3,
          "tokens" : [
            {
              "position" : 1,
              "start_offset" : 8,
              "end_offset" : 12,
              "payload" : "d29yZA=="
            },
            {
              "position" : 2,
              "start_offset" : 13,
              "end_offset" : 17,
              "payload" : "d29yZA=="
            },
            {
              "position" : 3,
              "start_offset" : 18,
              "end_offset" : 22,
              "payload" : "d29yZA=="
            }
          ]
        },
        "twitter" : {
          "doc_freq" : 2,
          "ttf" : 2,
          "term_freq" : 1,
          "tokens" : [
            {
              "position" : 0,
              "start_offset" : 0,
              "end_offset" : 7,
              "payload" : "d29yZA=="
            }
          ]
        }
      }
    }
  }
}

8.2.1.5、人造文档

还可以为人造文档生成词条向量，也就是生成索引中不存在的文档。

入参：

GET /twitter/_termvectors
{
  "doc" : {
    "fullname" : "John Doe",
    "text" : "twitter test test test"
  }
} 

出参：

{
  "_index" : "twitter",
  "_version" : 0,
  "found" : true,
  "took" : 111,
  "term_vectors" : {
    "fullname" : {
      "field_statistics" : {
        "sum_doc_freq" : 4,
        "doc_count" : 2,
        "sum_ttf" : 4
      },
      "terms" : {
        "doe" : {
          "term_freq" : 1,
          "tokens" : [
            {
              "position" : 1,
              "start_offset" : 5,
              "end_offset" : 8
            }
          ]
        },
        "john" : {
          "term_freq" : 1,
          "tokens" : [
            {
              "position" : 0,
              "start_offset" : 0,
              "end_offset" : 4
            }
          ]
        }
      }
    },
    "text" : {
      "field_statistics" : {
        "sum_doc_freq" : 6,
        "doc_count" : 2,
        "sum_ttf" : 8
      },
      "terms" : {
        "test" : {
          "term_freq" : 3,
          "tokens" : [
            {
              "position" : 1,
              "start_offset" : 8,
              "end_offset" : 12
            },
            {
              "position" : 2,
              "start_offset" : 13,
              "end_offset" : 17
            },
            {
              "position" : 3,
              "start_offset" : 18,
              "end_offset" : 22
            }
          ]
        },
        "twitter" : {
          "term_freq" : 1,
          "tokens" : [
            {
              "position" : 0,
              "start_offset" : 0,
              "end_offset" : 7
            }
          ]
        }
      }
    }
  }
}

8.2.1.6、字段分析器

此外，可以使用 per_field_analyzer 参数为不同的字段提供不同的分析器，这对于以任何方式生成 Term 向量都很有用，特别是在使用人工文档时。当为已经存储 Term 向量的字段提供分析器时，将重新生成 Term 向量。

入参：

GET /twitter/_termvectors
{
  "doc" : {
    "fullname" : "John Doe",
    "text" : "twitter test test test"
  },
  "fields": ["fullname"],
  "per_field_analyzer" : {
    "fullname": "keyword"
  }
} 

出参：

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

9、`refresh` 参数

索引、更新、删除和批量 API 支持用 refresh 参数来控制请求所做的更改何时对搜索可见。允许的值如下。

9.1、参数配置

9.1.1、空或 `true`

操作发生后立即刷新相关的主分片和副本分片 (不是整个索引)，以便更新的文档立即显示在搜索结果中。这个设置需要仔细考虑和验证，因为会导致性能下降(从索引和搜索的角度来看)

PUT /test/_doc/1?refresh
{"test":"test"}

PUT /test/_doc/2?refresh=true
{"test":"test"}

9.1.2、`wait_for`

在返回结果之前，将等待刷新使请求所做的更改可见，这不会强制立即刷新，而是等待刷新发生。

⬤ Elasticsearch自动刷新，刷新频率是 index.refresh_interval，默认是 1s。这个设置是动态的。调用 refresh API，或在响应的 API 上设置 refresh 为 true 都将导致刷新，请求将返回。

PUT /test/_doc/3
{"test":"test"}

PUT /test/_doc/4?refresh=false
{"test":"test"}

9.1.3、`false` (默认值)

不执行与刷新相关的操作。此请求所做的更改将在请求返回后的某个时间点可见

PUT /test/_doc/4?refresh=wait_for
{"test":"test"}

9.2、如何选择`refresh`的值

除非有充分的理由等待更改变为可见，否则始终使用 refresh = false

如果必须使请求所做的更改与请求同步可见当

⬤ 设置refresh 为 ` true 时，Elasticsearch` 将增加更多负载

⬤ 设置为 wait_for ;将等待更长时间，这需要结合实际情况决定。

9.3、强制刷新

如果当已经有 index.max_refresh_listeners 值定义数量 ( 默认为 1000 个) 的请求在该分片上等待刷新时，该请求的行为将如同 refresh 设置为true 一样:它将强制刷新。这保证了当该请求返回时，其更改对搜索可见，同时防止对被阻塞的请求使用未经检查的资源。如果请求由于监听器槽用完而强制刷新，则其响应将包含”forced_refresh”: true 信息。

10、乐观并发控制

Elasticsearch是分布式的，创建、更新或删除文档时，必须将文档的新版本复制到集群中的其他节点。Elasticsearch也是异步和并发的，这意味着这些复制请求是并行发送的，并且可能不按顺序到达目的地。Elasticsearch需要一种方法来确保旧版本的文档永远不会覆盖新版本的文档。

保证并发：为了确保旧版本的文档不会覆盖新版本文档，对文档执行的每个操作都由主分片分配一个序列号，序列号随着每个操作的增加而增加，因此新操作的序列号肯定比旧操作的序列号更高。然后， Elasticsearch可以使用这个序列号来确保新的文档版本不会被分配了较小序列号的更改覆盖。

举例：以下索引命令将创建一个文档并为其分配初始序列号 _seq_no 和 _primary_term ( _primary_term 和 _seq_no 都是整数)，每当主分片发生重新分配时，比如重启、Primary 选举等， _primary_term 会递增1:

入参：

GET twitter/_doc/1

出参：

{
  "_index" : "twitter",
  "_id" : "1",
  "_version" : 14,
  "_seq_no" : 15,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "fullname" : "John Doe",
    "text" : "twitter test test test "
  }
}

10.1、乐观更新

_seq_no 和 _primary_term 唯一地标识一个变更。通过记下返回的这两个值，可以确保仅在检索文档后没有对其进行其他更改的情况下更改文档。这是通过设置索引 API 或删除 API 的 if_seq_no 和 if_primary_term 参数来完成的

例如，以下调用将确保向文档中添加标记 tag，而不会丢失对描述的任何潜在更改或由其他API添加其他标记:

入参：

PUT /products/_doc/1567?if_seq_no=362&if_primary_term=2
{
    "product" : "r2d2",
    "details" : "A resourceful astromech droid",
    "tags": ["droid"]
}
'

二、级别语法

模糊查询

{  
    "query": {  
        "wildcard": {  
            "bizDesc": "*命中配置规则:*"  
        }  
    }  
}

范围查询

{
    "query": {
        "range": {
            "inValidateTime": {
                "lte": "2024-04-24 13:41:06"
            }
        }
    }
}

直接命中

{
    "query": {
        "match": {
            "insuranceId": "5000"
        }
    }
}

多条件查询

{
    "query": {
        "bool": {
            "must": [
                {
                    "wildcard": {
                        "bizDesc": "*定价策略*"
                    }
                },
                {
                    "range": {
                        "inValidateTime": {
                            "lte": "2024-04-24 13:41:06"
                        }
                    }
                }
            ]
        }
    }
}

ContactAuthor

一、索引 API

1、自动创建索引

1）特定模式才允许创建

2）完全禁用索引的自动创建

3）允许使用任何名称自动创建索引

4）索引存在 ( 覆盖&失败 )

2、ID 自动生成

3、路由

4、分发

5、等待活动分片

6、detect_noop 参数

二、GET API

1、根据id 查询索引文档

2、head 检查文档是否存在

3、实时性

4、字段选择

1）_source_includes 和 _source_excludes

2）_source

3）直接获取 _source

4）只返回 _source

5）筛选 _source 字段

6）检查 _source 是否存在

3.6、routing 路由

3.7、preference 参数

3.8、refresh 参数

3.9、分发

1.10、存储字段

1.10.1、检索数据

4、删除 API

4.1、根据特定文档 Id 删除

4.2、查询删除

4.2.1、查询匹配并删除

4.2.1.1、简单的查询删除

4.2.1.2、拒绝版本冲突中止

4,2.1.3、一次删除多个索引文档

4,2.1.4、routing 路由

4,2.1.5、scroll_size 滚动批次

4.2.2、URL 参数

4.2.2.1、refresh

4.2.2.2、wait_for_completion

4.2.2.3、wait_for_active_shards & timeout

4.2.24、requests_per_second

4.2.3、返回体

4.2.4、任务 API

4.2.4.1、使用任务ID，可以直接查找任务:

4.2.5、取消任务 API

4.2.6、动态调整 API

4.2.7、切片

4.2.7.1、人工切片

4.2.7.2、自动切片

4.2.7.3、切片数量选择

5、更新 API

5.1、使用 script 更新

5.2、部分字段更新

5.3、避免无效更新

5.4、upsert 元素

5.4.1、文档不存在，则创建

5.4.2、文档存在，则执行 Script

5.5、查询更新

5.5.1、URL 参数

5.5.1.1、refresh

5.5.1.2、wait_for_completion

5.5.1.3、wait_for_active_shards & timeout

5.5.1.4、requests_per_second

5.5.2、请求体

5.5.3、任务API

5.5.4、取消任务API

5.5.5、动态调整API

5.5.6、切片

6、MGet API

6.1、普通查询

6.2、指定索引查询

6.2.1、简化查询

6.3、_source 过滤

6.4、存储字段

6.4.1、请求体指定

6.4.2、URL 中指定

6.5、路由

7、bulk 批量操作

7.1、简单操作

一、索引 `API`

2、`ID` 自动生成

6、`detect_noop` 参数

二、`GET` `API`

1、根据`id` 查询索引文档

2、`head` 检查文档是否存在

1）`_source_includes` 和 `_source_excludes`

2）`_source`

3）直接获取 `_source`

4）只返回 `_source`

5）筛选 `_source` 字段

6）检查 `_source` 是否存在

3.6、`routing` 路由

3.7、`preference` 参数

3.8、`refresh` 参数

4、删除 `API`

4.1、根据特定文档 `Id` 删除

4,2.1.4、`routing` 路由

4,2.1.5、`scroll_size` 滚动批次

4.2.2、`URL` 参数

4.2.2.1、`refresh`

4.2.2.2、`wait_for_completion`

4.2.2.3、`wait_for_active_shards` & `timeout`

4.2.24、`requests_per_second`

4.2.4、任务 `API`

4.2.4.1、使用任务`ID`，可以直接查找任务:

4.2.5、取消任务 `API`

4.2.6、动态调整 `API`

5、更新 `API`

5.1、使用 `script` 更新

5.4、`upsert` 元素

5.4.2、文档存在，则执行 `Script`

5.5.1、`URL` 参数

5.5.1.1、`refresh`

5.5.1.2、`wait_for_completion`

5.5.1.3、`wait_for_active_shards` & `timeout`

5.5.1.4、`requests_per_second`

6、`MGet` `API`

6.3、`_source` 过滤

6.4.2、`URL` 中指定

7、`bulk` 批量操作

8、`Term` 向量

8.1.1、`Term` 信息

8.1.3、`Term` 过滤

8.2.1.3、返回`Id`=1 中字段`text`的所有信息和统计信息：

9、`refresh` 参数

9.1.1、空或 `true`

9.1.2、`wait_for`

9.1.3、`false` (默认值)

9.2、如何选择`refresh`的值