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个。

OR

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

OR

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

OR

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将是理想的解决方案之一，但是由于必须在两个不同的索引中进行搜索，因此可能会影响您的查询时间。您可以通过在同一索引中引入一个称为“类型”的字段来避免这种情况，该字段可用于区分文档，这将使编写Es索引查询和获取时间变得容易。

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

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

    },

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

    }

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

1 个答案: