如何使用ElasticSearch組織對嵌套對象的搜索？

Question

我正在嘗試使用ElasticSearch在我的項目中組織搜索，但找不到一件事。

讓我們簡化上下文，並假設有兩種模型：用戶及其消息。 因此，我想提供2種搜索類型：

• 查找我的短信
• 通過郵件查找用戶

文字訊息（很簡單）

應該如何工作：用戶輸入“關於會議的筆記”，他將獲得帶有此文本的消息列表。

消息像這樣存儲在ElasticSearch中：

{
  "id" : "1",
  "user_id" : "101",
  "text": "hello"
}

因此，通過文本查找消息沒有問題。

文字使用者（問題）

它應該如何工作：用戶輸入“關於會議的筆記”，然后他獲得了使用此文本編寫消息的用戶列表。

我幾乎不知道如何組織它，但是我真的不喜歡其中任何一個。

想法1

查找所有消息，提取其user_id，然后像這樣運行SQL查詢

SELECT * FROM users WHERE id IN ('101', '102', '103')

這是最明顯的方法，但有一個問題-如何組織適當的分頁？ 消息是分頁的，但用戶不是。

想法2

將用戶存儲在ElasticSearch中，並將其消息作為嵌套對象：

{ 
  "id" : "101",
  "name" : "Bob",
  "messages" : [
    { "id" : "1", "text" : "hello" },
    { "id" : "2", "text" : "howdy?" },
    { "id" : "3", "text" : "bye" }
  ]
}

現在，我可以通過對ElasticSearch的一個查詢來找到用戶。 但是也有一些缺點：

• 添加新消息時，我必須重新索引整個用戶對象
• 我必須在ElasticSearch緩存中復制消息以提供兩種類型的搜索：第一次作為單獨的消息對象，第二次作為用戶對象中的嵌套對象。 我有很多數據（至少10億條消息），所以這種重復會使我的緩存很大（可能很慢？）。

您能給我建議解決這個問題的最好，最常用的方法嗎？

Answer 1

正如您所指出的，可以通過使用嵌套對象來解決，但是更好的方法是使用父子關系。

您可以通過使用父子關系 （考慮閱讀整節內容，尤其是this ）並根據需要使用has_child或has_parent查詢來解決嵌套對象中可能遇到的問題。

它將解決需要索引整個對象的問題。 但是您將需要考慮內存，因為elasticsearch會破壞內存中的子文檔ID（到目前為止）。