同步更新到彈性搜索索引是否是個好主意

我有一個使用案例，其中後端存儲是S3，我們希望通過彈性搜索爲搜索提供動力。一種選擇是同時更新S3和索引。同步更新到彈性搜索索引是否是個好主意

我見過的大多數用例都是異步更新索引。同步更新的一個明顯缺點是處理S3更新成功但索引更新失敗時的失敗情況。

如果等待時間不是問題，反對進行同步更新的要點是什麼？

2017-07-27 Abhay Dubey

如果您第一次編制索引然後存儲並且存儲失敗，那麼您需要刪除索引文檔（否則，某人將能夠在搜索中找到它，並且可能會得到它存在的錯誤印象， T）。如果存儲失敗相對較少，那麼它可能會付出代價，但是你需要找出答案。另一方面，如果你存儲的對象和索引是並行處理的，那麼你實際上會得到相同的效果：當一個對象被存儲時，被另一個索引，同時仍然確保除非存儲它，否則對象將不可搜索。這樣，您就不需要回滾您在索引上執行的任何操作。

來源

2017-07-27 14:22:32

正如你所說，存儲之前的索引是沒有意義的。唯一的一點是如果寫入索引失敗，我是否應該寫入失敗？並行寫入的問題是我們需要處理兩種故障情況（寫入S3失敗或寫入索引失敗）。 –

完全取決於您的使用案例。是否可以搜索對象？有沒有其他方法可以訪問它們（例如，他們的S3密鑰存儲在其他地方）;你會重試索引;等等。 –

- 這是對象可被搜索的必要條件。 - 當我們擁有主ID並且不需要使用其他屬性進行搜索時，可以在少數使用情況下使用S3鍵讀取對象。 - 由於寫入延遲不是主要問題，因此如果失敗，我們將重試索引幾次。如果索引寫入仍然失敗，我們可能簡單地失敗呼叫。請讓我知道你是否曾經使用過類似的東西，或看到這種方法的任何主要問題。 –

同步更新到彈性搜索索引是否是個好主意

回答

相關問題