更新数据时的elasticsearch批量导入速度

Question

我当前的 elasticsearch 集群配置有一个主节点和六个数据节点，每个节点位于独立的 AWS ec2 实例上。

Master t2.large [2 vcpu, 8G ram]

每个数据节点 r4.xlarge [4 vcpu. 30.5GB]

分片数 = 12 [是不是太少了？]

我每天都会从日志中批量导入 110GB 数据。

分三步导入。

首先，新建索引，批量导入50GB数据。

导入运行非常快，通常在 50-65 分钟内完成

然后我运行大约 40GB 数据的第二个批量导入任务，这实际上是对先前导入的记录的更新。 [绝对没有新记录]

该更新任务平均需要大约 6 个小时。

有什么方法可以加速/优化整个过程以更快地运行？

我正在考虑的选项

1- 将数据节点数从当前的 6 个增加到 10 个。

或

2- 增加每个数据节点上的内存/CPU。

或

3- 完全放弃更新部分并将所有数据导入单独的索引。这将需要更新应用程序端的查询逻辑，以便从多个索引进行查询，但除此之外，多个索引是否有任何缺点？

或

4- 还有其他我可能忽略的选项吗？

编辑：

我继续增加节点数量作为测试运行，我可以确认以下结果。[在此处发布以防万一它可以帮助某人]

注意：每个节点的规格与上面相同

Current System 6 nodes 12 shards
Main insert (~50G) = 54 Min
Update      (~40G) = 5H30min

Test 1 System 10 nodes 24 shards
Main insert (~50G) = 51 Min
Update      (~40G) = 2H15min

Test 2 System 12 nodes 24 shards
Main insert (~50G) = 51 Min
Update      (~40G) = 1H36min

有很大的改进，但仍然在寻找建议，尽管有这么多实例在经济上是沉重的。

Answer 1

增加数据节点并增加每个数据节点上的内存/CPU 不会解决您的问题，因为索引时间不会有显着差异。

因为，更新要求 Elasticsearch 首先找到文档，然后通过创建具有新版本号的新索引然后删除旧索引来覆盖它，这往往会随着分片越大而变得越慢。 您打算使用的选项 3 将是它的理想解决方案之一，但它可能会影响您的查询时间，因为它必须在两个不同的索引中进行搜索。 您可以通过在同一索引中引入一个名为“type”的字段来避免这种情况，该字段可用于区分文档，从而可以轻松编写 Es 索引的查询以及获取时间。

例如：（您的索引将类似于您可以获取数据的类型）

    { 
      data:'some data'
      type:'first-inserted'

    },

   { 
      data:'some data'
      type:'second-inserted'

    }