ES实战--文档间的关系

文档常见关系
1.对象类型
2.嵌套文档
3.文档间的父子关系
4.反规范化
5.应用端的链接
嵌套映射和对象映射看上去差不多,不过其type不是object而是nested
查询和过滤器区别
1.查询是计算得分的,查询返回按照相关性得分排列的结果
2,过滤器不计算得分,运行更快,且易缓存
Nested查询和过滤器

GET /get-together/_search
{
  "query": {
    "nested": {
      "path": "members",
      "query": {
        "bool": {
          "must": [
            {
              "term": {
                "members.first_name":"lee"
              }
            },
            {
              "term": {
                "members.last_name": "gheorghe"
              }
            }
          ]
        }
      }
    }
  }
}

从get-together索引中找到所有文档中的members嵌套字段，然后根据members.name字段的值进行分组和计数，以找出哪些成员名字出现得最频繁。这对于分析社交聚会、会员参与度或社区活动中成员的参与情况非常有用

GET /get-together/_search?pretty
{
  "aggs": {
    "members": {
      "nested": {
        "path": "members"
      },
      "aggs": {
        "frequent_members": {
          "terms": {
            "field": "members.name"
          }
        }
      }
    }
  }
}

索引的操作如何分发到分片:
索引的每篇文档都有一个ID,而且ID经过了散列处理.与此同时,索引的每个分片有一个散列的取值范围.可能就包含了文档的ID散列值.索引的文档就会分发到散列范围包含该文档ID散列值的分片
散列的ID被称为路由值,而将文档分配到某个分片的过程称为路由,由于每个ID都不同,而且对其进行散列处理,所以默认的路由机制将文档均匀地分配到不同的分片上
父子关系文档查询
1.通过has_child 使用子辈的条件来搜索父辈
2.通过has_parent使用父辈条件来搜索子辈
反规范化:使用复制腐剧来避免昂贵的链接操作
在嵌套类型,父子关系和反规范化之间进行选择时,需要根据实际数据情况衡量.如果数据规模真的很小,内容基本不变,而且有很多查询请求,可以使用反规范化一对多的关系.没有链接/join速度更快.
反规范化定义关系有缺点:
优点:
1.允许使用多对多的关系
2.没有引入链接,如果集群可以处理复制导致的额外数据,则查询将更快
不足:
1.在索引,更新和删除时,需要额外处理复制的数据
2.由于数据的复制,导致某些搜索和聚合无法按照预期那样工作(例如去重)
应用端的链接
如果不进行反规范化,处理分组和会员之间关系的另一种选择时,将它们保存在各自单独的索引中,然后在应用程序中进行链接.需要存储ID来表示哪些会员属于哪些分组