ES查询 - 批量操作
使用id查询单条记录的方式，如果要查询n次，我们就要调用n次查询接口，这样做会对资源造成浪费，因此ES提供了批量查询的方法。
1 批量查询：mget
| 名称 | 数值 | 备注 |
|---|---|---|
| 请求地址 | http://192.168.3.214:9200/shop/_mget | |
| 请求方式 | POST |
请求参数
{
"ids":["1001", "1003", "1005"]
}
使用mget搜索不会像使用_search指定ID查询数据那样，展示源信息。 使用mget查询数据时，如果这个数据不存在，则，这个id对应的数据行也会查询出来，不过，这行数据的found字段对应的值是：false；使用_search查询，如果数据不存在，则不会展示那行数据。
2 批量操作：_bulk
2.1 基本语法
bulk操作和以往的普通请求格式有区别，不要格式化json，不然就不在同一行了，这个需要注意。
{action: {metadata}}\n
{request body }\n
{action: {meatdata}}\n
{request body }\n
{action: {metadata}} 代表批量操作的类型，可以是新增、删除或修改 \n是每行结尾必须填写的一个规范，每一行包括最后一行都要写，用于es的解析 {request body}是请求body，增加和修改操作需要，删除操作则不需要
2.2 批量操作的类型
action必须是以下选项之一：
- create: 如果文档不存在，那么久创建他，存在会报错。发生异常报错不会影响其他操作。
- index: 创建一个新文档或者替换一个现有的文档。
- update: 部分更新一个文档。
- delete: 删除一个文档
metadata中需要指定要操作的文档的_index、type和_id，_index、_type也可以在url中指定。
2.3 实际操作
| 名称 | 数值 | 备注 |
|---|---|---|
| 请求地址 | http://192.168.3.214:9200/_bulk | |
| 请求方式 | POST |
2.3.1 批量创建：create
{"create": {"_index": "shop", "_type": "_doc", "_id": "2001"}}
{"id": "2001", "nickname": "name-2001"}
{"create": {"_index": "shop", "_type": "_doc", "_id": "2002"}}
{"id": "2002", "nickname": "name-2002"}
{"create": {"_index": "shop", "_type": "_doc", "_id": "2003"}}
{"id": "2003", "nickname": "name-2003"}
创建文档时，如果文档不存在，则他会创建，如果这个文档存在，则他会报一个异常，不过这个异常不会影响其他的批量操作。上面的参数中，索引和类型可以写到URL上面，不必再参数中每一个文档都写一遍：http://192.168.3.214:9200/shop/_doc/_bulk。
2.3.2 批量创建：index
上面的create在创建时，如果文档存在，则会抛出异常，如果我们想在文档存在时更新这个文档的话，可以使用：index。
{"index": {"_id": "2001"}}
{"id": "2001", "nickname": "name-2001"}
{"index": {"_id": "2002"}}
{"id": "2002", "nickname": "name-2002"}
{"index": {"_id": "2003"}}
{"id": "2003", "nickname": "name-2003"}
2.3.3 批量更新：update
{"update": {"_id": "2001"}}
{"doc": {"id": "2001"}}
{"update": {"_id": "2002"}}
{"doc": {"nickname": "name-2002"}}
批量更新可以局部更新，参数中只需要填写想要更新的文档内的某个字段。
2.3.4 批量删除：delete
{"delete": {"_id": "2001"}}
{"delete": {"_id": "2002"}}
总结
上面的CURD的操作可以混合在一起使用，同一个请求参数可以混合所有的操作。 整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。 批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。 但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。 幸运的是，很容易找到这个 最佳点 ：通过批量索引典型文档，并不断增加批量大小进行尝试。 当性能开始下降，那么你的批量大小就太大了。一个好的办法是开始时将 1,000 到 5,000 个文档作为一个批次, 如果你的文档非常大，那么就减少批量的文档个数。 密切关注你的批量请求的物理大小往往非常有用，一千个 1KB 的文档是完全不同于一千个 1MB 文档所占的物理大小。 一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。