当数据量很大时导入或更新elasticsearch

Question

我需要根据以下工作流程决定是使用elasticsearch导入还是更新/更新插入。

Elasticsearch 充当商业智能应用程序的后端。

我们每天从 Hadoop 收集大约 200GB 的日志和分析数据作为纯文本文件。

elasticsearch 中的所有现有索引都将被删除，并为今天的数据创建一个新索引。

200GB数据导入到新索引中。

导入大约需要 3.5 小时，然后 Elasticsearch 在接下来的 24 小时内为该应用程序提供服务，直到下一个导入过程开始，一切都会再次重复。

如果该信息有帮助的话，我们正在使用elasticsearch-php SDK来处理批量导入。

我们导入的日志数据格式如下

id: 30459,
age: 45,
country: US
page_view_count: 4657

显然，数据包含诸如永远不会改变的国家、很少改变的年龄以及偶尔可能改变的观看次数等字段。

大约在 200GB 中，我可以说与昨天的数据相比，大约 80-85% 的数据没有变化。

我有以下两个问题想请教专家。

1- 很明显，由于大多数数据都是相同的，所以我们应该只使用 upsert，我尝试过，但 upsert 过程花费的时间太长，有时甚至超过 8 小时以上。 （我也使用了 doc 样式更新命令来确保数据是否相同，它会被跳过，但结果相同）。您是否认为我跳过了 upsert 处理器中明显缺少的一些 elasticsearch 标志，我应该在 upsert 之前切换该标志并恢复到进程完成？我应该检查哪些标志、设置、集群或节点参数以使批量更新插入更快（至少它应该比新鲜索引更快......不？）

2- 删除索引并每天进行全新导入似乎违反直觉，但该过程及时完成，并且服务在 4 小时内上线。为什么在这种特定情况下导入比更新插入更快？我相信这不应该是因为索引 200GB 数据需要完成所有工作。

你能指出我正确的方向吗？

Answer 1

为什么

upsert

没有帮助

您认为更新单个值只会触及文档的一部分，但相反，整个对象将被重新索引，因为在 ES 中它们是不可变的。这就是 update API 的工作原理。

为什么速度变慢了？

当写入一大堆新文档时，ES 只做两件事：索引和写入磁盘（粗略地说）。

部分更新时，它会执行三件事：检索、索引、写入。

可以采取哪些措施来加快索引速度

有一些用于调整索引性能的一般建议，我建议先看一下

index.refresh_interval

，您可能会考虑放大它或完全禁用它。

请注意，在创建新索引时不必删除索引，您可以使用 aliases 指向当前索引。