同步更新到弹性搜索索引是否是个好主意

我有一个使用案例，其中后端存储是S3，我们希望通过弹性搜索为搜索提供动力。一种选择是同时更新S3和索引。同步更新到弹性搜索索引是否是个好主意

我见过的大多数用例都是异步更新索引。同步更新的一个明显缺点是处理S3更新成功但索引更新失败时的失败情况。

如果等待时间不是问题，反对进行同步更新的要点是什么？

2017-07-27 Abhay Dubey

如果您第一次编制索引然后存储并且存储失败，那么您需要删除索引文档（否则，某人将能够在搜索中找到它，并且可能会得到它存在的错误印象， T）。如果存储失败相对较少，那么它可能会付出代价，但是你需要找出答案。另一方面，如果你存储的对象和索引是并行处理的，那么你实际上会得到相同的效果：当一个对象被存储时，被另一个索引，同时仍然确保除非存储它，否则对象将不可搜索。这样，您就不需要回滚您在索引上执行的任何操作。

来源

2017-07-27 14:22:32

正如你所说，存储之前的索引是没有意义的。唯一的一点是如果写入索引失败，我是否应该写入失败？并行写入的问题是我们需要处理两种故障情况（写入S3失败或写入索引失败）。 –

完全取决于您的使用案例。是否可以搜索对象？有没有其他方法可以访问它们（例如，他们的S3密钥存储在其他地方）;你会重试索引;等等。 –

- 这是对象可被搜索的必要条件。 - 当我们拥有主ID并且不需要使用其他属性进行搜索时，可以在少数使用情况下使用S3键读取对象。 - 由于写入延迟不是主要问题，因此如果失败，我们将重试索引几次。如果索引写入仍然失败，我们可能简单地失败呼叫。请让我知道你是否曾经使用过类似的东西，或看到这种方法的任何主要问题。 –

同步更新到弹性搜索索引是否是个好主意

回答

相关问题