Elasticsearch 基于时间的提要模块的最佳方法？

Posted 2023-02-16

【中文标题】Elasticsearch 基于时间的提要模块的最佳方法？

【英文标题】：Best approch of Elastic Search time based feeds module?

【发布时间】：2017-12-17 04:01:15

【问题描述】：

我是弹性搜索的新手，正在寻找最佳解决方案，我可以使用它创建一个提要模块，该模块具有基于时间的提要以及组和评论。

我学得很少，想出以下方法。

PUT /group
    
      "mappings": 
        "groupDetail": ,
        "content": 
          "_parent": 
            "type": "groupDetail" 
          
        ,
        "comment": 
          "_parent": 
            "type": "content" 
          
        
      
    

以便根据索引单独放置。

但是在我发现一篇帖子之后，我发现父子对象比嵌套对象的搜索操作成本更高。

类似以下的内容是两个组（提要），其中包含内容和 cmets 作为嵌套元素的详细信息。

  "_index": "group",
  "_type": "groupDetail",
  "_id": 6829,
  "_score": 1,
  "_source": 
    "groupid": 6829,
    "name": "Jignesh Public",
    "insdate": "2016-10-01T04:09:33.916Z",
    "upddate": "2017-04-19T05:19:40.281Z",
    "isVerified": true,
    "tags": [
      "spotrs",
      "surat"
    ],
    "content": [
      
        "contentid": 1,
        "type": "1",
        "byUser": 5858,
        "insdate": "2016-10-01 11:20",
        "info": [
          
            "t": 1,
            "v": "lorem ipsum long text 1"
          ,
          
            "t": 2,
            "v": "http://www.imageurl.com/1"
          
        ],
        "comments": [
          
            "byuser": 5859,
            "comment": "Comment 1",
            "upddate": "2016-10-01T04:09:33.916Z"
          ,
          
            "byuser": 5860,
            "comment": "Comment 2",
            "upddate": "2016-10-01T04:09:33.916Z"
          
        ]
      ,
      
        "contentid": 2,
        "type": "2",
        "byUser": 5859,
        "insdate": "2016-10-01 11:20",
        "info": [
          
            "t": 4,
            "v": "http://www.videoURL.com/1"
          
        ],
        "comments": [
          
            "byuser": 5859,
            "comment": "Comment 1",
            "upddate": "2016-10-01T04:09:33.916Z"
          ,
          
            "byuser": 5860,
            "comment": "Comment 2",
            "upddate": "2016-10-01T04:09:33.916Z"
          
        ]
      
    ]
  



  "_index": "group",
  "_type": "groupDetail",
  "_id": 6849,
  "_score": 1,
  "_source": 
    "groupid": 6849,
    "name": "Xyz Group Public",
    "insdate": "2016-10-01T04:09:33.916Z",
    "upddate": "2017-04-19T05:19:40.281Z",
    "isVerified": false,
    "tags": [
      "spotrs",
      "food"
    ],
    "content": [
      
        "contentid": 3,
        "type": "1",
        "byUser": 5858,
        "insdate": "2016-10-01 11:20",
        "info": [
          
            "t": 1,
            "v": "lorem ipsum long text 3"
          ,
          
            "t": 2,
            "v": "http://www.imageurl.com/1"
          
        ],
        "comments": [
          
            "byuser": 5859,
            "comment": "Comment 1",
            "upddate": "2016-10-01T04:09:33.916Z"
          ,
          
            "byuser": 5860,
            "comment": "Comment 2",
            "upddate": "2016-10-01T04:09:33.916Z"
          
        ]
      ,
      
        "contentid": 4,
        "type": "2",
        "byUser": 5859,
        "insdate": "2016-10-01 11:20",
        "info": [
          
            "t": 4,
            "v": "http://www.videoURL.com/1"
          
        ],
        "comments": [
          
            "byuser": 5859,
            "comment": "Comment 1",
            "upddate": "2016-10-01T04:09:33.916Z"
          ,
          
            "byuser": 5860,
            "comment": "Comment 2",
            "upddate": "2016-10-01T04:09:33.916Z"
          
        ]
      
    ]
  

现在，如果我尝试使用嵌套对象进行思考，那么如果用户频繁添加评论而不是重新索引因子会产生影响，我会感到困惑？

所以我主要想问的是哪种方法是我可以经常添加评论的最佳方法，并且我的内容搜索结果也更快。

【参考方案1】：

性能

父/子将相关数据存储在同一个分片中，作为单独的doc，避免了网络； 父/子在检索数据时需要加入进程； 嵌套对象将内部和外部对象存储在一起，作为单个文档；

所以，我们可以推断：

更新嵌套对象将重新索引整个索引，如果您的文档很大，这可能会非常昂贵； 单独更新父或子不会影响另一个； 搜索嵌套对象有点快，省去了加入的过程；

建议

据我了解您的问题，您应该使用父/子。

当您的小组的 cmets 越来越多时，添加新评论仍会重新索引整个内容，这可能非常耗时； 另一方面，搜索带有父/子的评论只需要在找到子之后再查找，这是相对可以接受的。

此外，您还应该考虑搜索评论与添加评论的比率：

如果您需要搜索很多但有一点新的 cmets，也许您可​​以选择嵌套对象； 否则，选择父/子；

顺便说一句，你可以将它们结合起来：

当此提要处于活动状态时，使用父/子存储它们； 当它关闭时，即不能再添加 cmets，将它们移动到具有嵌套对象的新索引；

【参考方案2】：

如果您没有指定除very frequently 以外的更详细信息，则很难提出建议。你也没有提到你的数据是什么样子的。即使在激烈的讨论中，博客文章中的评论也可能很少发生。论坛帖子中的评论/回复（这将导致巨大的文档）可能会非常不同。我个人会从嵌套开始，看看它是如何进行的，但我也不知道所有的要求，所以这可能是一个非常错误的答案。

【讨论】：

我已经编辑了内容，如果你没有暗示它对我很有帮助。