Hibernate Search + Elasticsearch - 請求中的version_type - 如何實現

Question

在我們的應用程序中，我們將 Hibernate Search + Elasticsearch 一起用作最終用戶的搜索引擎。 搜索服務中的配置（我們稱之為XXXsearch，用java編寫）如下所示：

spring:
  profiles: elasticsearch
  elasticsearch:
    rest:
      uris: "http://${XXX_ELASTICSEARCH_HOST:localhost}:${XXX_ELASTICSEARCH_PORT:9200}"
  jpa:
    properties:
      hibernate:
        search:
          default:
            indexmanager: elasticsearch
            elasticsearch:
              host: "http://${XXX_ELASTICSEARCH_HOST:localhost}:${XXX_ELASTICSEARCH_PORT:9200}"
              index_schema_management_strategy: "${XXX_ELASTICSEARCH_SCHEMA_MANAGEMENT_STRATEGY}"
              required_index_status: green

我們應用程序中每條記錄的數據都保存在關系數據庫 (Oracle) 中，並通過 Hibernate Search 傳播到 Elasticsearch。

快速解釋一下我們的問題：我們遇到了搜索服務 (XXXsearch) 的兩個 Pod (Kubernetes) 並發提交的問題——數據過去幾乎同時提交（相差毫秒）時會被不按順序覆蓋。 我們為數據庫中的記錄添加了版本控制：

@Field(index = Index.YES, analyze = Analyze.NO)
@Version
private int version;

它解決了在 Oracle DB 中覆蓋數據的問題。 但是，當搜索完成時，例如，按參數/字段狀態及其值“ A ”，搜索查詢返回狀態為“ A ”、“ B ”和“ C ”的分數。 Oracle DB中的數據記錄是最新的，所以我認為問題是Hibernate Search是批量更新Elasticsearch的索引，所以存在不按順序更新的可能。

目前，我解決這個問題的最好辦法是使用Elasitcsearch 的版本控制，但我找不到任何關於如何在 Hibernate Search 中配置它的信息。 我只在Spring Data 的文檔中找到了這樣的配置。

Answer 1

我不知道這是否是您的情況，但是在關聯上使用@IndexedEmbedded時，文檔最終會跨越多個實體，這可能會導致與您遇到的問題類似的問題。 這是一個已知的限制，並在此處記錄。

不幸的是，（通常）沒有辦法將涉及的多個源實體的數據庫版本 ( @Version ) 可靠地映射到文檔版本，因此 Elasticsearch 版本控制無濟於事。

這就是為什么 Elasticsearch 版本控制目前沒有在 Hibernate Search 中實現的原因：它只適用於非常特定的場景，即您將一個實體恰好映射到一個文檔，這是可能的，但不是很常見。 實施這個並不能完全解決問題，同時給人一種虛假的安全感，這就是為什么我們決定不這樣做，並致力於尋找更好的解決方案。

相反，Hibernate Search 6.1（目前處於 Alpha 階段）引入了節點間協調的概念，這樣給定的實體永遠不會被並發索引，一勞永逸地解決了這個問題。

您可以在此處找到更多信息： https : //docs.jboss.org/hibernate/search/6.1/reference/en-US/html_single/#coordination-database-polling

（注意配置屬性，目前文檔中有錯別字， hibernate.search.backend.coordination.*實際上應該是hibernate.search.coordination.* ；我們將在下一個版本中修復它）

目前僅支持靜態分片（固定數量的應用程序節點），但正在研究動態分片（具有自動重新平衡）。

同時，如果你有一個自動伸縮的應用程序集群，你可以讓你的節點的一個固定子集（例如 4 個“主要”節點，總是啟動）執行自動索引，而其他節點只收集實體更改事件而不收集自己執行自動索引。

最終，我們的目標是提供不依賴於數據庫中的附加表的替代協調策略（例如使用 Debezium ），但稍后會出現。