PUT /customer?pretty 创建索引customer，返回json格式
GET /_cat/indices?v 列出所有索引列表
PUT /customer/doc/1?pretty 在客户索引中插入数据（动词 /索引[库名]/类型[表名]/id?返回json格式的响应）
{
"name": "yufei"
}
Get /customer/doc/1?pretty 检索编入的索引文档
*_source:指lucene的document，相当于数据库表中的一行记录
DELETE /customer?pretty 删除索引
ElasticSearch访问数据的模式:<REST动词> / <索引> / <类型> / <ID>
*索引时，ID部分是可选的,如果未指定，Elasticsearch将生成随机ID，然后使用它来索引文档。Elasticsearch生成的实际ID（或前面示例中显式指定的内容）将作为索引API调用的一部分返回
*POST动词而不是PUT，因为我们没有指定ID
POST /customer/doc?pretty 插入数据没有指定id时用动词post,自动生成字符串id(UUID)
{
"name": "Jane Doe"
}
更新文档：
*Elasticsearch实际上并没有在内部进行就地更新。每当我们进行更新时，Elasticsearch都会删除旧文档，然后一次性对应用了更新的新文档编制索引
更新之前的文档并加入字段age
POST /customer/doc/1/_update?pretty 更新文档用动词post,id后用_update
{
"doc": { "name": "Jane Doe", "age": 20 } 这儿的doc值lucene的docuemt，相当于数据库表 中的一行记录
}
也可以使用简单脚本执行更新。此示例使用脚本将年龄增加5：
POST /customer/doc/1/_update?pretty
{
"script" : "ctx._source.age += 5"
}
在上面的示例中，ctx._source指的是即将更新的当前源文档。
Elasticsearch提供了在给定查询条件（如SQL UPDATE-WHERE语句）的情况下更新多个文档的功能
*删除文档 相当于删除表中的一行记录
DELETE /customer/doc/2?pretty 删除文档用动词delete
————————————————————————————————————————————————————————————————————————————————————
_bulkAPI批处理：用来多条执行上述操作
Bulk API不会因其中一个操作失败而失败。如果单个操作因任何原因失败，它将继续处理其后的其余操作。批量API返回时，它将为每个操作提供一个状态（按照发送的顺序），以便您可以检查特定操作是否失败
POST /customer/doc/_bulk?pretty
{"index":{"_id":"3"}}
{"name": "John Doe" }
{"index":{"_id":"4"}}
{"name": "Jane Doe" }
对于删除操作，之后没有相应的源文档，因为删除只需要删除文档的ID。
POST /customer/doc/_bulk?pretty bulk批处理更新并删除文档
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"3"}}
——————————————————————————————————————————————————————————————————————————
样本：
curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/doc/_bulk?pretty&refresh" --data-binary "@accounts.json"
curl "localhost:9200/_cat/indices?v"
————————————————————————————————Search API————————————————————————————————————————
1、请求以URL方法：
GET /bank/_search?q=*&sort=account_number:asc&pretty
动词/索引/搜索？匹配所有文档&升序进行排序
q=*参数指示Elasticsearch匹配索引中的所有文档。该sort=account_number:asc参数指示使用account_number每个文档的字段以升序对结果进行排序。该pretty参数再次告诉Elasticsearch返回漂亮打印的JSON结果
返回结果刨析：
took - Elasticsearch执行搜索的时间（以毫秒为单位）
timed_out - 告诉我们搜索是否超时
_shards - 告诉我们搜索了多少个分片，以及搜索成功/失败分片的计数
hits - 搜索结果
hits.total - 符合我们搜索条件的文档总数
hits.hits - 实际的搜索结果数组（默认为前10个文档）
hits.sort - 对结果进行排序（如果按分数排序则丢失）
hits._score并max_score- 暂时忽略这些字段
2、不是传入q=* url,采用_search API提供json格式的请求体
GET /bank/_search
{
"query": { "match_all": {} }, 匹配所有文档
"sort": [
{ "account_number": "asc" } 按account_number排序（升序）
]
}
一旦您获得了搜索结果，Elasticsearch就完全完成了请求，并且不会在结果中维护任何类型的服务器端资源或打开游标。这与SQL等许多其他平台形成鲜明对比，其中您可能最初预先获得查询结果的部分子集，然后如果要获取（或翻页）其余的则必须连续返回服务器使用某种有状态服务器端游标的结果。
—————————————————————————————————————————— Query DSL——————————————————————————————————
GET / bank / _search
{
“query”：{“match_all”：{}} 搜索所有文档
"size": 1 请注意，如果size未指定，则默认为10。实际搜索的结果,返回前几个文档
}
query部分告诉我们查询定义是什么，match_all部分只是我们想要运行的查询类型。该match_all查询仅仅是在指定索引的所有文件进行搜索
GET /bank/_search
{
"query": { "match_all": {} },
"from": 10, 返回文档10-19，用于分页
"size": 10
}
在from（从0开始）参数规定了从启动该文件的索引和size参数指定了多少文件，返回从参数开始的。在实现搜索结果的分页时，此功能非常有用。请注意，如果from未指定，则默认为0
GET / bank / _search 按账户余额排序，返回前10个默认文档
{
“query”：{“match_all”：{}}，
“sort”：{“balance”： 排序字段
{“order”：“desc”} 排序方式
}
}
————————————————————————————————————————————————————————————————————————————
搜索返回指定字段 返回两个字段account_number和balance（内部_source）
概念与SQL SELECT FROM字段列表有些相似
GET /bank/_search
{
"query": { "match_all": {} },
"_source": ["account_number", "balance"]
}
———————————————————————match查询针对特定字段或字段集进行的搜索————————————————————————————————
返回编号为20的帐户： match 指定要查询的字段
GET /bank/_search
{
"query": { "match": { "account_number": 20 } }
}
地址中包含术语“mill”或“lane”的所有帐户 包含两个元素用空格隔开 示例是match（match_phrase）的变体
GET /bank/_search
{
"query": { "match": { "address":"mill lane"}}
}
———————————————————————————————————bool查询———————————————————————————————————————————————————————
使用布尔逻辑将较小的查询组成更大的查询。
(1)bool must 必须两这都包含，相当于sql中的and
此示例组成两个match查询并返回地址中包含“mill”和“lane”的所有帐户：
GET /bank/_search
{
"query": {
"bool": {
"must": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
(2)bool should 满足其中一个条件返回相当于sql中的or
GET /bank/_search
{
"query": {
"bool": {
"should": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
(3)bool must_not 既不包含A有不包含B，子句指定了一个查询列表，对于文档而言，这些查询都不能为真匹配
GET /bank/_search
{
"query": {
"bool": {
"must_not": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
总结：must should moust_not 是bool型，必须包含在bool内,多个条件条件用数组包起来
返回任何40岁但不住在ID（aho）的人的所有帐户：
GET /bank/_search
{
"query": {
"bool": {
"must": [
{ "match": { "age": "40" } }
],
"must_not": [
{ "match": { "state": "ID" } }
]
}
}
}
___________________________________________执行过滤器_____________________________________________________
range查询：通常用于数字或日期过滤
使用bool查询返回所有余额介于20000和30000之间的帐户。换句话说，我们希望找到余额大于或等于20000且小于或等于30000的帐户
GET /bank/_search
{
"query": {
"bool": {
"must": { "match_all": {} },
"filter": {
"range": {
"balance": {
"gte": 20000,
"lte": 30000
}
}
}
}
}
}
解析上面的内容，bool查询包含match_all查询（查询部分）和range查询（过滤部分）。我们可以将任何其他查询替换为查询和过滤器部分。在上面的情况中，范围查询非常有意义，因为落入范围的文档都“相同”匹配，即，没有文档比另一文档更相关
—————————————————————————————————————————————执行聚合—————————————————————————————————————————————————————
聚合提供了从数据中分组和提取统计信息的功能。考虑聚合的最简单方法是将其大致等同于SQL GROUP BY和SQL聚合函数。在Elasticsearch中，您可以执行返回匹配的搜索，同时在一个响应中返回与命中相关的聚合结果。这是非常强大和高效的，因为您可以运行查询和多个聚合，并一次性获取两个（或任一）操作的结果，避免使用简洁和简化的API进行网络往返。
此示例按状态对所有帐户进行分组，然后返回按计数降序排序的前10个（默认）状态（也是默认值）：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword"
}
}
}
}
在SQL中，上述聚合在概念上类似于：
SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC
请注意，我们设置size=0为不显示搜索匹配，因为我们只希望在响应中看到聚合结果。
在前一个聚合的基础上，此示例按州计算平均帐户余额（同样仅针对按降序排序的前10个州）：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword"
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
请注意我们如何嵌套average_balance聚合内的group_by_state聚合。这是所有聚合的常见模式。您可以在聚合中任意嵌套聚合，以从数据中提取所需的轮转摘要。
在前一个聚合的基础上，我们现在按降序排列平均余额：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword",
"order": {
"average_balance": "desc"
}
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
此示例演示了我们如何按年龄段（20-29岁，30-39岁和40-49岁）进行分组，然后按性别分组，最后得到每个年龄段的平均帐户余额：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_age": {
"range": {
"field": "age",
"ranges": [
{
"from": 20,
"to": 30
},
{
"from": 30,
"to": 40
},
{
"from": 40,
"to": 50
}
]
},
"aggs": {
"group_by_gender": {
"terms": {
"field": "gender.keyword"
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
}
}
——————————————————————————————————————————————————安装配置————————————————————————————————
要将Elasticsearch作为守护程序运行，请-d在命令行中指定，并使用以下-p选项将进程ID记录在文件中：
./bin/elasticsearch -d -p pid
可以在$ES_HOME/logs/目录中找到日志消息。
要关闭Elasticsearch，请终止pid文件中记录的进程ID
kill `cat pid`
重要的Elasticsearch配置编辑
虽然Elasticsearch只需要很少的配置，但在投入生产之前需要考虑许多设置。
在投入生产之前，必须考虑以下设置：
路径设置：
群集名称：
cluster.name编辑
节点只能cluster.name在与群集中的所有其他节点共享群集时才能加入群集。默认名称是elasticsearch，但您应将其更改为适当的名称，该名称描述了群集的用途。
cluster.name：logging-prod
确保不要在不同的环境中重用相同的群集名称，否则最终会导致节点加入错误的群集
节点名称：
node.name编辑
默认情况下，Elasticsearch将使用随机生成的UUID的前七个字符作为节点id。请注意节点ID是持久的，并且在节点重新启动时不会更改，因此默认节点名称也不会更改。
值得配置一个更有意义的名称，它还具有在重新启动节点后保持持久性的优点：
node.name:prod-data-2
该node.name如下，也可以设置为服务器的主机名：
node.name: $ {HOSTNAME}
网络主机：
network.host编辑
默认情况下，Elasticsearch仅绑定到环回地址 - 例如127.0.0.1 和[::1]。这足以在服务器上运行单个开发节点。
实际上，可以从$ES_HOME 单个节点上的相同位置启动多个节点。这对于测试Elasticsearch形成集群的能力非常有用，但它不是推荐用于生产的配置。
为了与其他服务器上的节点进行通信并形成集群，您的节点将需要绑定到非环回地址。虽然有许多 网络设置，但通常您需要配置的是 network.host：
network.host:192.168.1.10
该network.host设置也了解一些特殊的值，比如 _local_，_site_，_global_和喜欢修饰:ip4和:ip6，其中的细节中可以找到的特殊值network.host编辑。
发现设置：
Elasticsearch使用名为“Zen Discovery”的自定义发现实现进行节点到节点的群集和主选举。在投入生产之前，应该配置两个重要的发现设置。
discovery.zen.ping.unicast.hosts编辑
开箱即用，没有任何网络配置，Elasticsearch将绑定到可用的环回地址，并将扫描端口9300到9305以尝试连接到在同一服务器上运行的其他节点。这提供了自动群集体验，无需进行任何配置。
当需要在其他服务器上形成具有节点的群集时，您必须提供群集中可能是实时且可联系的其他节点的种子列表。这可以指定如下：
discovery.zen.ping.unicast.hosts：
- 192.168.1.10:9300
- 192.168.1.11
- seeds.mydomain.com
如果未指定 ，端口将默认为transport.profiles.default.port和回退 transport.tcp.port。
解析为多个IP地址的主机名将尝试所有已解析的地址。
discovery.zen.minimum_master_nodes编辑
为防止数据丢失，必须配置 discovery.zen.minimum_master_nodes设置，以便每个符合主节点的节点都知道必须可见的最大主节点数，才能形成集群。
如果没有此设置，遭受网络故障的群集可能会将群集拆分为两个独立的群集 - 分裂的大脑 - 这将导致数据丢失。在通过minimum_master_nodes编辑避免裂脑的过程中提供了更详细的解释 。
为避免分裂大脑，应将此设置设置为符合条件的主节点的法定数量：
（master_eligible_nodes / 2）+ 1
换句话说，如果有三个符合主节点的节点，则应将最小主节点设置为(3 / 2) + 1或2：
discovery.zen.minimum_master_nodes：2
堆大小：
堆转储路径
GC记录
——————————————————————————————————————日期数学索引名称————————————————————————————————————————-
日期数学索引名称解析使您可以搜索一系列时间序列索引，而不是搜索所有时间序列索引并过滤结果或维护别名。限制搜索的索引数可以减少集群上的负载并提高执行性能。例如，如果要在日常日志中搜索错误，则可以使用日期数学名称模板将搜索限制为过去两天。
几乎所有具有index参数的API都支持index参数值中的日期数学。
日期数学索引名称采用以下形式：
<static_name {date_math_expr {DATE_FORMAT |的time_zone}}>
static_name 是名称的静态文本部分
date_math_expr 是动态计算日期的动态日期数学表达式
date_format 是应该呈现计算日期的可选格式。默认为YYYY.MM.dd。
time_zone 是可选的时区。默认为utc。
您必须在尖括号中包含日期数学索引名称表达式，并且所有特殊字符都应该是URI编码的。例如：
# GET /<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
"query" : {
"match": {
"test": "data"
}
}
}
以下示例显示了日期数学索引名称的不同形式以及它们在给定当前时间时解析的最终索引名称是2024年3月22日中午utc。
表达 解决了
<logstash-{now/d}>
logstash-2024.03.22
<logstash-{now/M}>
logstash-2024.03.01
<logstash-{now/M{YYYY.MM}}>
logstash-2024.03
<logstash-{now/M-1M{YYYY.MM}}>
logstash-2024.02
<logstash-{now/d{YYYY.MM.dd|+12:00}}>
logstash-2024.03.23
要使用索引名称模板中的字符{和}静态部分，请使用反斜杠对其进行转义\，例如：
<elastic\\{ON\\}-{now/M}> 解决了 elastic{ON}-2024.03.01
以下示例显示搜索请求，该搜索请求搜索过去三天的Logstash索引，假设索引使用默认的Logstash索引名称格式， logstash-YYYY.MM.dd。
# GET /<logstash-{now/d-2d}>,<logstash-{now/d-1d}>,<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd-2d%7D%3E%2C%3Clogstash-%7Bnow%2Fd-1d%7D%3E%2C%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
"query" : {
"match": {
"test": "data"
}
}
}
———————————————————————————————————————————————————返回值格式———————————————————————————————————————
漂亮的结果编辑
当附加?pretty=true到任何请求时，返回的JSON将被格式化（仅用于调试！）。另一种选择是设置?format=yaml哪个将导致以（有时）更可读的yaml格式返回结果。
————————————————————————————————————————————————人类可读的输出——————————————————————————————————————
统计信息以适合人类（例如"exists_time": "1h"或"size": "1kb"）和计算机（例如"exists_time_in_millis": 3600000或"size_in_bytes": 1024）的格式返回。可以通过添加?human=false 到查询字符串来关闭人类可读取的值。当统计结果被监控工具消耗时，这是有意义的，而不是用于人类消费。human标志的默认值是 false。
————————————————————————————————————————————————————响应过滤—————————————————————————————————————————————————
所有REST API都接受一个filter_path参数，该参数可用于减少Elasticsearch返回的响应。此参数采用逗号分隔的过滤器列表，用点表示法表示：
GET /_search?q=elasticsearch&filter_path=took,hits.hits._id,hits.hits._score
Elasticsearch有时会直接返回字段的原始值，如_source字段。如果要筛选_source字段，则应考虑将已存在的_source参数（请参阅 获取API以获取更多详细信息）与以下filter_path 参数组合：
POST / library / book？refresh
{“title”：“Book＃1”，“rating”：200.1}
POST / library / book？refresh
{“title”：“Book＃2”，“rating”：1.7}
POST / library / book？refresh
{“title”：“Book＃3”，“rating”：0.1}
GET /_search?filter_path=hits.hits._source&_source=title&sort=rating:desc
———————————————————————————————————————————————平面设置—————————————————————————————————————————————
该flat_settings标志会影响设置列表的呈现。当 flat_settings标志被true设置返回在一个平面格式
———————————————————————————————————————————————基于URL的访问控制————————————————————————————————————
许多用户使用具有基于URL的访问控制的代理来保护对Elasticsearch索引的访问。对于多搜索， 多重获取和批量请求，用户可以选择在URL和请求正文中的每个单独请求中指定索引。这可以使基于URL的访问控制具有挑战性。
要防止用户覆盖URL中指定的索引，请将此设置添加到elasticsearch.yml文件中：
rest.action.multi.allow_explicit_index：false
默认值为true，但设置false为时，Elasticsearch将拒绝在请求正文中指定了显式索引的请求。
———————————————————————————————————————————————文档API———————————————————————————————————————————————
1、单文档API
自动创建索引：
可以通过在所有节点的配置文件中设置action.auto_create_index来禁用自动索引创建 false。通过将per-index 设置index.mapper.dynamic为false索引设置，可以禁用自动映射创建 。
自动索引创建可以包括基于模式的白/黑列表，例如，设置action.auto_create_index为+aaa*,-bbb*,+ccc*,-*（+表示允许， - 表示不允许）。
创建索引文档： 可以用_create也可以指定？op_type = create参数
PUT twitter/tweet/3/_create
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
自动生成ID:
可以在不指定id的情况下执行索引操作。在这种情况下，将自动生成id。此外，op_type 将自动设置为create。这是一个例子（注意使用 POST而不是PUT）：
POST twitter/tweet/
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
__________________________________________________________路由_________________________________
默认情况下，分片放置 - 或routing- 通过使用文档的id值的散列来控制。对于更明确的控制，可以使用routing参数在每个操作的基础上直接指定输入到路由器使用的散列函数的值。例如：
POST twitter/tweet?routing=kimchy
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
在上面的示例中，“tweet”文档根据提供的routing参数路由到分片：“kimchy”。
设置显式映射时，_routing可以选择使用该字段指示索引操作从文档本身提取路由值。这确实来自另一个文档解析过程的（非常小的）成本。如果_routing映射已定义并设置为required，则如果未提供或提取路由值，则索引操作将失败。
———————————————————————————————————————————Noop更新—————————————————————————————————————————
使用索引api更新文档时，即使文档未更改，也始终会创建新版本的文档。如果这是不可接受的，请使用设置为true 的_updateapi detect_noop。索引api上没有此选项，因为索引api不会获取旧源，也无法将其与新源进行比较。
关于何时不接受noop更新，没有一条硬性规定。它是许多因素的组合，例如您的数据源发送实际noops更新的频率以及Elasticsearch在接收更新时在分片上运行的每秒查询数。
——————————————————————————————————————————————Get API————————————————————————————————————
get API允许根据其id从索引中获取类型化的JSON文档。以下示例从名为twitter的索引中获取一个JSON文档，该索引名为tweet，id值为0：
获取twitter / tweet / 0
API还允许使用以下方式检查文档是否存在 HEAD：
HEAD twitter / tweet / 0
实时：
默认情况下，get API是实时的，并且不受索引刷新率的影响（当数据对搜索可见时）。如果文档已更新但尚未刷新，则get API将就地发出刷新调用以使文档可见。这也将使上次刷新后其他文档发生变化。为了禁用实时GET，可以将realtime参数设置为false。
源过滤:
默认情况下，get操作返回_source字段的内容，除非您已使用该stored_fields参数或该_source字段已禁用。您可以_source使用以下_source参数关闭检索
GET twitter/tweet/1?_source=false 返回的json没有_source源
如果您只需要完整的一个或两个字段，则_source可以使用_source_include ＆_source_exclude参数来包含或过滤掉您需要的部分。这对于大型文档尤其有用，其中部分检索可以节省网络开销。这两个参数都使用逗号分隔的字段列表或通配符表达式。例：
GET twitter/tweet/1?_source_include=*.id&_source_exclude=entities
如果您只想指定包含，则可以使用较短的表示法：
GET twitter/tweet/0?_source=*.id,retweeted
—————————————————————————————————————————————存储字段————————————————————————————————————————————————————
get操作允许指定将通过传递stored_fields参数返回的一组存储字段。如果未存储请求的字段，则将忽略它们。例如，考虑以下映射：
PUT twitter
{
"mappings": {
"tweet": {
"properties": {
"counter": {
"type": "integer",
"store": false
},
"tags": {
"type": "keyword",
"store": true
}
}
}
}
}
现在我们可以添加一个文档：
PUT twitter/tweet/1
{
"counter" : 1,
"tags" : ["red"]
}
只有叶子字段可以通过stored_field选项返回。因此无法返回对象字段，此类请求将失败
——————————————————————————————————————————获取_source直接——————————————————————————————————————————————————
使用/{index}/{type}/{id}/_source端点只获取_source文档的字段，而不包含任何其他内容。例如
GET twitter/tweet/1/_source
您还可以使用相同的源过滤参数来控制_source将返回的部分：
GET twitter/tweet/1/_source?_source_include=*.id&_source_exclude=entities'
_source端点还有一个HEAD变体，可以有效地测试document _source的存在。如果在映射中禁用了现有文档，则该文档将没有_source 。
HEAD twitter / tweet / 1 / _source
使用控制路由的能力进行索引时，为了获取文档，还应提供路由值。例如：
GET twitter/tweet/2?routing=user1
以上将获得id为2的推文，但将根据用户进行路由。注意，在没有正确路由的情况下发出get，将导致无法获取文档。
————————————————————————————————————————————Delete API————————————————-----——————————————————————
delete API允许根据其id从特定索引中删除类型化的JSON文档。以下示例从名为twitter的索引中删除JSON文档，该索引名为tweet，id为1：
DELETE / twitter / tweet / 1
版本控制编辑
索引的每个文档都是版本化的。删除文档时，version可以指定以确保我们尝试删除的相关文档实际上已被删除，并且在此期间没有更改。对文档执行的每个写入操作（包括删除）都会导致其版本递增。删除文档的版本号在删除后仍可短时间使用，以便控制并发操作。已删除文档的版本保持可用的时间长度由index.gc_deletes索引设置决定，默认为60秒。
______________________________________Delete By Query API________________________________________________
最简单的用法是_delete_by_query对匹配查询的每个文档执行删除操作。这是API
POST twitter/_delete_by_query 相当于delete.....where.....
{
"query": {
"match": {
"message": "some message"
}
}
}
必须query以与Search API相同的方式将查询作为值传递给键。您也可以使用q 与搜索API相同的方式使用参数。
_delete_by_query在索引启动时获取索引的快照，并使用internal版本控制删除它找到的内容。这意味着如果文档在拍摄快照的时间和处理删除请求之间发生更改，则会出现版本冲突。当版本匹配时，文档将被删除。
在_delete_by_query执行期间，顺序执行多个搜索请求以便找到要删除的所有匹配文档。每次找到一批文档时，都会执行相应的批量请求以删除所有这些文档。如果搜索或批量请求被拒绝，则_delete_by_query 依赖于默认策略来重试被拒绝的请求（最多10次，指数后退）。达到最大重试次数限制会导致_delete_by_query 中止，并failures在响应中返回所有失败。已执行的删除仍然有效。换句话说，该过程不会回滚，只会中止。当第一个失败导致中止时，失败的批量请求返回的所有失败都将返回到failures 元件; 因此，可能存在相当多的失败实体。
如果您想计算版本冲突而不是让它们中止，那么请conflicts=proceed在URL或"conflicts": "proceed"请求正文中设置。
回到API格式，您可以限制_delete_by_query为单一类型。这只会tweet从twitter索引中删除文档
POST twitter/tweet/_delete_by_query?conflicts=proceed
{
"query": {
"match_all": {}
}
}
也可以一次删除多个索引和多个类型的文档，就像搜索API一样：
POST twitter,blog/tweet,post/_delete_by_query
{
"query": {
"match_all": {}
}
}
——————————————————————————————————————————————Task API—————————————————————————————————————————————————
GET _tasks?detailed=true&actions=*/delete/byquery
该对象包含实际状态。它就像响应json一样，重要的是增加了这个total领域。total是reindex期望执行的操作总数。您可以通过添加估计的进展updated，created以及deleted多个领域。请求将在其总和等于total字段时结束。
————————————————————————————————————————————————Update API————————————————————————————————————————————————
让我们索引一个简单的文档
PUT test/type1/1
{
"counter" : 1,
"tags" : ["red"]
}
现在，我们可以执行一个增加计数器的脚本：
POST test/type1/1/_update
{
"script" : {
"source": "ctx._source.counter += params.count",
"lang": "painless",
"params" : {
"count" : 4
}
}
}
我们还可以在文档中添加一个新字段：
POST test/type1/1/_update
{
"script" : "ctx._source.new_field = 'value_of_new_field'"
}
或者从文档中删除字段：
POST test/type1/1/_update
{
"script" : "ctx._source.remove('new_field')"
}
而且，我们甚至可以改变执行的操作。如果tags字段包含green，此示例将删除doc ，否则它不执行任何操作（noop）：
POST test/type1/1/_update
{
"script" : {
"source": "if (ctx._source.tags.contains(params.tag)) { ctx.op = 'delete' } else { ctx.op = 'none' }",
"lang": "painless",
"params" : {
"tag" : "green"
}
}
}
部分文档更新：
更新API还支持传递部分文档，该部分文档将合并到现有文档中（简单的递归合并，对象的内部合并，替换核心“键/值”和数组）。例如：
POST test/type1/1/_update
{
"doc" : {
"name" : "new_name"
}
}
如果同时doc和script指定，然后doc被忽略。最好是将部分文档的字段对放在脚本本身中。
Uperts：
如果文档尚不存在，则upsert元素的内容将作为新文档插入。如果文档确实存在，那么 script将执行：
POST test/type1/1/_update
{
"script" : {
"source": "ctx._source.counter += params.count",
"lang": "painless",
"params" : {
"count" : 4
}
},
"upsert" : {
"counter" : 1
}
}
—————————————————————————————————————————Update By Query API—————————————————————————————————————————————
按查询API更新:
最简单的用法是_update_by_query在不更改源的情况下对索引中的每个文档执行更新。这对于获取新属性或其他一些在线映射更改很有用 。这是API：
POST twitter / _update_by_query？conflicts = proceed
您还可以_update_by_query使用 Query DSL进行限制。这将更新twitter用户索引中的所有文档 kimchy：
POST twitter/_update_by_query?conflicts=proceed
{
"query": {
"term": {
"user": "kimchy"
}
}
}
您可以使用Task API获取所有正在运行的逐个查询请求的状态 ：
GET _tasks？detailed = true＆actions = * byquery
____________________________________Multi Get API____________________________________________________
Multi GET API允许基于索引，类型（可选）和id（以及可能的路由）获取多个文档。响应包括一个docs数组，其中所有获取的文档按顺序对应于原始的多重获取请求（如果特定获取失败，则包含此错误的对象将包含在响应中）。成功获取的结构在结构上类似于get API 提供的文档 。
GET /_mget 此处用_mget
{
"docs" : [
{
"_index" : "test",
"_type" : "type",
"_id" : "1"
},
{
"_index" : "test",
"_type" : "type",
"_id" : "2"
}
]
}
mget端点也可以针对索引（在这种情况下它不能在体内所需的）中使用：
GET /test/_mget
{
"docs" : [
{
"_type" : "type",
"_id" : "1"
},
{
"_type" : "type",
"_id" : "2"
}
]
}
———————————————————————————————————————————————————————批量API—————————————————————————————————————
批量API使得在单个API调用中执行许多索引/删除操作成为可能。这可以大大提高索引速度
以下是批量命令的正确序列示例：
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_type" : "type1", "_id" : "2" } }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }