Elasticsearch 关系映射(一对一和一对多)

Question

在我的 Elasticsearch 服务器中，我有一个索引http://localhost:9200/blog。
(博客)索引包含多种类型。

例如:http://localhost:9200/blog/posts，http://localhost:9200/blog/tags。

在标签类型中，我创建了超过 1000 个标签和 10 个帖子类型。

例如:帖子

{   
    "_index":"blog",
    "_type":"posts",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "catalogId" : "1",
       "name" : "cricket",
       "url" : "http://www.wikipedia/cricket"
    }
}

例如:标签

{   
    "_index":"blog",
    "_type":"tags",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "tagId" : "1",
        "name" : "game"
    }
}

我想将现有标签分配给博客文章(即关系 => 映射)。

如何将标签分配给帖子映射？

Answer 1

您可以在 Elasticsearch 中使用 4 种方法来管理关系。 Elasticsearch 博客文章 - Managing Relations Inside Elasticsearch 中对它们进行了很好的概述。我建议阅读整篇文章以获取有关每种方法的更多详细信息，然后选择最能满足您的业务需求同时保持技术适用性的方法。

以下是 4 种方法的重点。

Inner Object

• Easy, fast, performant
• Only applicable when one-to-one relationships are maintained
• No need for special queries

Nested

• Nested docs are stored in the same Lucene block as each other, which helps read/query performance. Reading a nested doc is faster than the equivalent parent/child.
• Updating a single field in a nested document (parent or nested children) forces ES to reindex the entire nested document. This can be very expensive for large nested docs
• “Cross referencing” nested documents is impossible
• Best suited for data that does not change frequently

Parent/Child

• Children are stored separately from the parent, but are routed to the same shard. So parent/children are slightly less performance on read/query than nested
• Parent/child mappings have a bit extra memory overhead, since ES maintains a “join” list in memory
• Updating a child doc does not affect the parent or any other children, which can potentially save a lot of indexing on large docs
• Sorting/scoring can be difficult with Parent/Child since the Has Child/Has Parent operations can be opaque at times

Denormalization

• You get to manage all the relations yourself!
• Most flexible, most administrative overhead
• May be more or less performant depending on your setup