es的bulk注意点

转载

编程小达 2024-07-16 06:02:57

文章标签 es的bulk注意点 elasticsearch bulk 性能源码 文章分类 架构后端开发

什么是bulk操作

bulk是批量的意思，也就是把原来单个的操作打包好，通过批量的api提交到ES集群。下面是个示例：

单个操作：

PUT my-index-000001/_doc/1
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {
    "id": "kimchy"
  }
}

bulk操作：

POST _bulk
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_id" : "2" } }
{ "create" : { "_index" : "test", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }

另外，ES还提供了相关的API支持bulk操作，

BulkRequest bulkRequest = new BulkRequest();
        entityWrapperList.forEach(item -> {
            IndexRequest request  = new IndexRequest(item.getIndexName());
            request.id(item.getId());
            if (item.getVersion() > 0) {
                request.version(item.getVersion());
                request.versionType(VersionType.EXTERNAL_GTE);
            }

            request.source(JSON.toJSONString(item.getData()), XContentType.JSON);
            bulkRequest.add(request);
        });

        try {
            BulkResponse bulkResponse = client.bulk(bulkRequest, RequestOptions.DEFAULT);

es的bulk注意点_源码

es的bulk注意点_bulk_02

可以看到，我们可以把多个不同的命令打包好通过bulk提交。不过我个人的经验实际场景中多是相同的命令（比如批量index）。

bulk操作的顺序问题

一提到批量操作，有经验的人马上就会提出一个问题：一堆命令提交到ES，那么ES执行的顺序和我们提交的顺序是一致的吗？毕竟有些业务场景会对执行命令的顺序有要求。

答案是不一定。

es的bulk注意点_源码_03

根源在于ES的分布式架构。如上图所示，客户端的命令首先是请求到coordinating node（协调节点），然后协调节点根据命令提供的的路由字段（没有的话默认使用文档id），经过路由算法，找到对应的主shard（分片）。所以真正执行的节点就是shard所在的节点，而每条命令发送到节点上到底哪个先执行是没有保障的，取决于很多因素。比如发送到节点的时间，节点本身的空闲资源情况等。

不过从上面这段解释，我们也可以得出另外一个结论，就是对于同一个文档的操作是有序的。了解这点在一些业务场景下很重要。

虽然处理的顺序不能保证，但是ES会保证响应结果和提交的顺序是一致的。

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

这个返回的结果顺序，跟提交的顺序是一致的，标注每条命令执行的结果。

bulk操作的性能如何

ES官方是建议在业务场景允许的情况下，尽量使用bulk操作来提高index的性能，官方文档是这么说的。

Bulk requests will yield much better performance than single-document index requests. In order to know the optimal size of a bulk request, you should run a benchmark on a single node with a single shard. First try to index 100 documents at once, then 200, then 400, etc. doubling the number of documents in a bulk request in every benchmark run. When the indexing speed starts to plateau then you know you reached the optimal size of a bulk request for your data. In case of tie, it is better to err in the direction of too few rather than too many documents. Beware that too large bulk requests might put the cluster under memory pressure when many of them are sent concurrently, so it is advisable to avoid going beyond a couple tens of megabytes per request even if larger requests seem to perform better.

这句话的大概意思是，bulk的index操作性能是高于单文档的index操作的。至于bulk每个批次多少个文档是最优的，需要根据自己的实际环境进行压力测试，以实际的结果为准。

bulk性能高是自然的，因为它大大降低了业务和ES集群之间的IO。