深度剖析Elasticsearch的bulk api使用以及底层原理

一、api

1、概念

就是批量操作，将多条PUT/POST/DELETE命令合并成一个bulk命令进行操作，节省代码量也提高性能。

2、语法

PUT /_bulk
{"action":{"metadata"}}
{"data"}

action取值（如下是常用的）：
index：普通的PUT操作，可以是创建文档，也可以是全量替换
create：PUT /index/_doc/id/_create，强制创建
delete：删除一个文档，只要1个metadata就可以了，无需{“data”}部分
update：执行的partial update操作


metadata：json，对应的是这部分内容 PUT /product/_doc/1


data：具体操作内容的json，比如

{
   "name": "huawei shouji",
   "desc": "4G 5G",
   "tags": ["shouji"]
}

3、Demo

3.1、需求一

比如要创建一个index名称为test_index1且_id为1的一个document，document里面包含如下两个字段

{
	"test_field1" : "test1", 
	"test_field2" : "test2"
}

PUT /_bulk
{"index" : {"_index" : "test_index1", "_id" : "1"}}
{"test_field1" : "test1", "test_field2" : "test2"}

查看数据进行验证

GET /test_index1/_search
{
  "query": {
    "match_all": {}
  }
}

结果：

{
  "took" : 5,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 1,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "test_index1",
        "_type" : "test_type",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "test_field1" : "test1",
          "test_field2" : "test2"
        }
      }
    ]
  }
}

3.2、需求二

综合应用

POST /_bulk
{"delete":{"_index":"test_index2","_id":"1"}}
{"create":{"_index":"test_index2","_id":"2"}}
{"test_field":"test2"}
{"index":{"_index":"test_index2","_id":"3"}}
{"test_field":"test3"}
{"update":{"_index":"test_index2","_id":"2","retry_on_conflict":3}}
{"doc":{"test_field2":"bulk test"}}

返回结果是对每一条操作都做一个结果，彼此之间互不影响，也就是说比如第一条delete报错了，不会影响下面的语句，粗糙理解成“没mysql的事务控制”。但是再返回结果里，会告诉你异常日志。具体返回结果如下，比如第一个delete是404了。：

{
  "took" : 394,
  "errors" : false,
  "items" : [
    {
      "delete" : {
        "_index" : "test_index2",
        "_type" : "_doc",
        "_id" : "1",
        "_version" : 1,
        "result" : "not_found",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 0,
        "_primary_term" : 1,
        "status" : 404
      }
    },
    {
      "create" : {
        "_index" : "test_index2",
        "_type" : "_doc",
        "_id" : "2",
        "_version" : 1,
        "result" : "created",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 1,
        "_primary_term" : 1,
        "status" : 201
      }
    },
    {
      "index" : {
        "_index" : "test_index2",
        "_type" : "_doc",
        "_id" : "3",
        "_version" : 1,
        "result" : "created",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 2,
        "_primary_term" : 1,
        "status" : 201
      }
    },
    {
      "update" : {
        "_index" : "test_index2",
        "_type" : "_doc",
        "_id" : "2",
        "_version" : 2,
        "result" : "updated",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 3,
        "_primary_term" : 1,
        "status" : 200
      }
    }
  ]
}

二、补充

1、格式

比如严格遵守如下格式，多一个回车符号都会报错

PUT /_bulk
{"action":{"metadata"}}
{"data"}

比如如下会报错：

PUT /_bulk
{"index" : {"_index" : "test_index1", "_id" : "1"}}
{
  "test_field1" : "test1", "test_field2" : "test2"
  
}

返回结果

{
  "error" : {
    "root_cause" : [
      {
        "type" : "illegal_argument_exception",
        "reason" : "Malformed action/metadata line [3], expected START_OBJECT but found [VALUE_STRING]"
      }
    ],
    "type" : "illegal_argument_exception",
    "reason" : "Malformed action/metadata line [3], expected START_OBJECT but found [VALUE_STRING]"
  },
  "status" : 400
}

2、优化

bulk size建议大小：

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

三、底层原理

1、问题

为什么bulk api那么的丑陋不堪？换行、格式化都会报错，比如那么丑陋的格式才能执行？

2、答案

因为bulk中的每组操作（index/create/delete/update）都可能要转发到不同的node的shard上去执行。
如果采取优雅的json格式，如下：

[
  {
    "action" : {},
    "data" : {}
  }
]

首先，整个可读性非常棒，读起来很爽，但是ES拿到那种标准格式的JSON串以后，要按照下述流程去进行处理
（1）将JSON数组解析为JSONArray对象，这个时候，整个数据，就会在内存中出现一份一模一样的拷贝，一份数据是JSON文本，一份数据是JSONArray对象。
（2）解析JSON数组里的每个JSON，对每个请求中的document进行路由
（3）为路由到同一个shard上的多个请求，创建一个请求数组。
（4）将这个请求数组序列化
（5）将序列化后的请求数组发送到对应的节点上去

再看这种丑陋的bulk json格式

{"action" : {"meta"}}
{"data"}
{"action" : {"meta"}}
{"data"}

（1）不用将其转换为JSON对象，不会出现内存中的相同数据的拷贝，直接按照换行符切割JSON
（2）对每两个一组的json，读取meta，进行document路由
（3）直接将对应的json发送到node上去

两种格式对比：
（1）优雅格式：
耗费更多的内存，更多的JVM GC开销
我们之前提到过 bulk size最佳大小的问题，一般建议说在几千条那样，然后大小在10MB左右，所以说，可怕的事情来了，假设说现在100个bulk请求发送到了一个节点上去，然后每个请求是10MB，100个请求就是1000MB=1GB。然后每个请求的json都copy一份为JSONArray对象，此时内存中的占用就会翻倍，就会占用2GB内存，甚至还不止，因为弄成JSONArray后，还可能会多搞一些其他的数据结构，2GB+的内存占用。
占用更多的内存可能就会积压其他请求的内存使用量，比如说最重要的搜索请求，分析请求，等等，此时就可能会导致其他请求的性能急速下降
另外的话，占用内存更多，就会导致ES的java虚拟机的垃圾回收次数更多，更频繁，每次要回收的垃圾对象更多，耗费的时间更多，导致ES的java虚拟机停止工作线程的时间更多。

（2）丑陋的JSON格式：
最大的优势在于，不需要将JSON数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能的保证性能。

微信公众号