【发布时间】：2016-04-06 23:41:26
【问题描述】：
我正在使用Elasticsearch Bulk API 创建或更新文档。
我确实知道它们是创建还是更新，但我可以通过将它们全部设为index 或 SQL 意义上的“upserts”来简化我的代码。
与使用更明确的create 和update 相比，使用index（并让ES 解决）有什么缺点吗？
【问题讨论】：
标签： elasticsearch elasticsearch-bulk
【发布时间】：2016-04-06 23:41:26
【问题描述】：
如果您发送create，则必须确保该文档尚不存在于您的索引中，否则调用将失败，而使用index 发送相同的文档将始终成功。
然后，如果出于性能原因，您知道您将创建一个文档（使用create 或index），然后您只会更新几个属性，那么使用update 可能会有意义。
否则，如果您总是发送完整的文档，我会一直使用index 来创建和更新。每当看到index 操作时，ES 将创建文档（如果不存在）或替换它（如果存在），但调用将始终成功。
【讨论】：
-
另外，Index API 不支持脚本更新，所以如果要使用脚本，必须使用 Update API。 Update API 不支持外部版本，所以如果要使用外部版本，必须使用 Index API。
简短的回答：不，没有缺点。
创建和更新端点是特殊情况。使用 create 如果文档已经存在，您什么也不想做。如果您没有文档的所有数据，您可以通过更新提供更少的数据，您可以添加一些字段。您还可以确保仅在更新时已对文档进行索引。
【讨论】：
-
假设您可能会多次替换给定文档（例如多次索引完全相同的文档）。既然 ES 并没有真正“删除”任何东西，那你不是在添加越来越多的文档并增加它们的版本号，然后将其留给垃圾收集器来清理旧版本吗？在这种情况下，使用 index vs create 不会在短期内使您的索引膨胀，这可能会影响性能吗？未来垃圾收集的大量使用是否也会影响性能？这是我想知道的一个真正的问题，而不是一个修辞问题。谢谢
-
但是当你更新一个文档时，不就是获取、修改然后索引它吗？在更新整个文档中，我们说过更新文档的方法是检索它，更改它，然后重新索引整个文档。这是真实的。但是，使用更新 API，我们可以进行部分更新，例如在单个请求中增加计数器。我们还说文档是不可变的：它们不能更改，只能替换。更新 API 必须遵守相同的规则。