search - 如何使用ElasticSearch组织对嵌套对象的搜索？

Question

我正在尝试使用ElasticSearch在我的项目中组织搜索，但找不到一件事。

让我们简化上下文，并假设有两种模型:用户及其消息。因此，我想提供2种搜索类型:

查找我的短信

通过他们的消息查找用户

文字讯息(很简单)

应该如何工作:用户输入“关于 session 的笔记”，他将获得带有此文本的消息列表。

消息像这样存储在ElasticSearch中:

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

因此，通过文本查找消息没有问题。

文字使用者(问题)

它应该如何工作:用户输入“关于 session 的笔记”，然后他获得了使用此文本编写消息的用户列表。

我几乎不知道如何组织它，但是我真的不喜欢其中任何一个。

想法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

正如您所指出的，可以通过使用嵌套对象来解决，但是更好的方法是使用父子关系。

您可以通过使用parent-child relationship(考虑阅读整节内容，尤其是this)并根据需要使用has_child或has_parent查询来解决嵌套对象中可能遇到的问题。

它将解决需要索引整个对象的问题。但是您将需要考虑内存，因为elasticsearch会破坏内存中的子文档ID(到目前为止)。