前面介绍说，Elasticsearch 都是通过 REST API 接口来操作数据的，那么下面接通过几个接口的请求来演示它的使用。（当前虚拟机IP为192.168.200.130）

_cat

GET /_cat/nodes：查看所有节点

image.png

GET /_cat/health：查看 es 健康状况

image.png

GET /_cat/master：查看主节点

image.png

GET /_cat/indices：查看所有索引

等价于 mysql 数据库的 show databases;

image.png

索引一个文档

保存一个数据，保存在哪个索引的哪个类型下，指定用哪个唯一标识

PUT 请求

接口格式：/{index}/{type}/{id}
请求体：一串JSON数据

示例

接口：PUT``/customer/external/1
请求体：{ "name": "Hong" }
PS：PUT在REST风格中应该时修改操作, 由于我们发送的数据目前是不存在的, 因此是created操作, 后续再次发送这个请求, 将会是updated操作
PUT可以新增也可以修改。PUT必须指定id；由于PUT需要指定id，我们一般用来做修改操作，不指定id会报错。
image.png

POST 请求

接口格式：/{index}/{type}
请求体：一串JSON数据

示例

接口：POST``/customer/external
请求体：{ "name": "Hong" }
PS：POST新增, 如果不指定id, 会自动生成id; 指定id就会修改这个数据, 并新增版本号
image.png

查询文档

GET 请求

接口格式：/{index}/{type}/{id}

示例

接口：GET``/customer/external/1
image.png

  1. {
  2.     "_index": "customer",  # 在哪个索引(库)
  3.     "_type": "external",   # 在哪个类型(表)
  4.     "_id": "1",            # 文档id(记录)
  5.     "_version": 1,         # 版本号
  6.     "_seq_no": 0,          # 并发控制字段，每次更新都会+1，用来做乐观锁
  7.     "_primary_term": 5,    # 同上，主分片重新分配，如重启，就会变化
  8.     "found": true,
  9.     "_source": {           # 数据
  10.         "name": "Hong"
  11.     }
  12. }
  14. # 乐观锁更新时在uri后携带 [?_seq_no=0&_primary_term=5]  当携带数据与实际值不匹配时更新失败

更新文档

POST 请求

接口格式：/{index}/{type}/{id}/_update
请求体：{ "doc": { "key": "value" } }

示例

接口：POST``/customer/external/1/_update
请求体：{ "doc": { "name": "Tom" } }
版本号加一，result：updated
image.png

再发送一次相同的请求

版本号没有发送改变，result：noop ( 空操作 )，_seq_no 也没有发送变化。
image.png

几种更新文档的区别

在上面索引文档即保存文档的时候介绍，还有两种更新文档的方式：

  • 当PUT请求带id，且有该id数据存在时，会更新文档；
  • 当POST请求带id，与PUT相同，该id数据已经存在时，会更新文档；

这两种请求类似，即带id，且数据存在，就会执行更新操作。
类比：

  • 请求体的报文格式不同，_update方式要修改的数据要包裹在 doc 键下
  • _update方式不会重复更新，数据已存在不会更新，版本号不会改变，另两种方式会重复更新（覆盖原来数据），版本号会改变
  • 这几种方式在更新时都可以增加属性，PUT请求带id更新和POST请求带id更新，会直接覆盖原来的数据，不会在原来的属性里面新增属性

删除文档&索引

删除文档

DELETE请求

接口格式：/{index}/{type}/{id}

示例

接口：DELTE``/customer/external/1
image.png

删除索引

DELETE请求

接口格式：/{index}

示例

接口：DELTE``/customer
image.png

bulk-批量操作数据

语法格式

  1. # action: 动作、metadata: 元数据
  2. {action:{metadata}}\n
  3. {request body  }\n
  5. {action:{metadata}}\n
  6. {request body  }\n

指定索引和类型的批量操作

接口：POST``/customer/external/_bulk
参数：

  1. {"index":{"_id":"1"}}
  2. {"name":"John Doe"}
  3. {"index":{"_id":"2"}}
  4. {"name":"John Doe"}

image.png

  1. POST /customer/external/_bulk
  2. {"index":{"_id":"1"}}
  3. {"name":"John Doe"}
  4. {"index":{"_id":"2"}}
  5. {"name":"John Doe"}

image.png

对所有索引执行批量操作

接口：POST``/_bulk
参数：

  1. {"delete":{"_index":"website","_type":"blog","_id":"123"}}
  2. {"create":{"_index":"website","_type":"blog","_id":"123"}}
  3. {"title":"my first blog post"}
  4. {"index":{"_index":"website","_type":"blog"}}
  5. {"title":"my second blog post"}
  6. {"update":{"_index":"website","_type":"blog","_id":"123"}}
  7. {"doc":{"title":"my updated blog post"}}

image.png

  • 这里的批量操作，当发生某一条执行发生失败时，其他的数据仍然能够接着执行，也就是说彼此之间是独立的。
  • bulk api以此按顺序执行所有的action（动作）。如果一个单个的动作因任何原因失败，它将继续处理它后面剩余的动作。
  • 当bulk api返回时，它将提供每个动作的状态（与发送的顺序相同），所以您可以检查是否一个指定的动作是否失败了。