ES101系列08 | 数据建模和索引重建本篇文章主要讲解 ElasticSearch 中的数据建模内容，包括如何处理关

本篇文章主要讲解 ElasticSearch 中的数据建模内容，包括如何处理关联关系、索引重建和字段建模最佳实践等。

在 ElasticSearch 中处理关联关系

关系型数据库，一般会考虑 Normalize 数据；在 Elasticsearch，往往考虑 Denormalize 数据。

Denormalize 的好处：读的速度变快/无需表连接/无需行锁

Elasticsearch 并不擅长处理关联关系。我们一般采用以下四种方法处理关联：

对象类型
嵌套对象 (Nested Object)
父子关联关系 (Parent/Child）
应用端关联

特性	对象类型	嵌套对象	父子关联	应用端关联
本质	默认处理 JSON 对象的方式	特殊的对象类型	同一索引内文档间的逻辑链接	由应用程序维护关联
存储结构	对象属性扁平化存储到父文档	作为父文档内部的独立隐藏文档	父子文档独立存储在同一分片	关联数据存储在不同文档或外部系统
数据边界	无边界，对象属性合并到父文档	有边界，每个嵌套对象独立存储	父子文档完全独立	完全独立，无 ES 内部关联
查询特点	可能匹配不同对象的字段组合	确保条件匹配同一嵌套对象内部	需用 `has_child`、`has_parent` 等查询	需多次查询，先查主文档再查关联文档
更新特点	更新需重索引整个父文档	更新需重索引整个父文档	可单独更新子文档，不影响父文档	每个文档可单独更新
适用场景	简单键值对对象，无需独立查询	对象数组需独立查询和匹配	子文档频繁更新或数量大	关系简单、查询量小或数据分散
缺点	无法精确匹配数组内对象组合	更新成本高，嵌套数量有限制	查询性能低，内存消耗大	网络开销大，应用逻辑复杂

Nested Data Type

Nested 数据类型：允许对象数组中的对象被独立索引。
使用 nested 和 properties 关键字，将所有数组索引到多个分隔的文档。
在内部，Nested 文档会被保存在两个 Lucene 文档中，在查询时做 Join 处理。

示例

PUT my_movies
{
    "mappings": {
        "properties": {
            "actors": {
                "type": "nested",
                "properties": {
                    "first_name": {
                        "type": "keyword"
                    },
                    "last_name": {
                        "type": "keyword"
                    }
                }
            },
            "title": {
                "type": "text",
                "fields": {
                    "keyword": {
                        "type": "keyword",
                        "ignore_above": 256
                    }
                }
            }
        }
    }
}

若没有指定 "type": "nested" 时，数组数据会扁平化存储，搜索会出现不该出现的内容。

Parent / Child

对象和 Nested 对象每次更新都需要重新索引整个对象。

ES 提供了类似关系型数据库中 Join 的实现。可通过维护 Parent / Child 的关系，从而分离两个对象。

父文档和子文档是两个独立的文档。
更新父文档无需重新索引子文档。子文档被添加，更新或者删除也不会影响到父文档和其他的子文档。

示例

1、添加数据

PUT my_blogs
{
  "settings": {
    "number_of_shards": 2
  },
  "mappings": {
    "properties": {
      "blog_comments_relation": {
        "type": "join",
        "relations": {
          "blog": "comment"
        }
      },
      "content": {
        "type": "text"
      },
      "title": {
        "type": "keyword"
      }
    }
  }
}

// 索引父文档
PUT my_blogs/_doc/blog2
{
  "title":"Learning Hadoop",
  "content":"learning Hadoop",
    "blog_comments_relation":{
    "name":"blog"
  }
}


// 索引子文档
PUT my_blogs/_doc/comment1?routing=blog1
{
  "comment":"I am learning ELK",
  "username":"Jack",
  "blog_comments_relation":{
    "name":"comment",
    "parent":"blog1"
  }
}

// 索引子文档
PUT my_blogs/_doc/comment2?routing=blog2
{
  "comment":"I like Hadoop!!!!!",
  "username":"Jack",
  "blog_comments_relation":{
    "name":"comment",
    "parent":"blog2"
  }
}

// 索引子文档
PUT my_blogs/_doc/comment3?routing=blog2
{
  "comment":"Hello Hadoop",
  "username":"Bob",
  "blog_comments_relation":{
    "name":"comment",
    "parent":"blog2"
  }
}

2、父子关系查询

// 根据父文档ID查看
GET my_blogs/_doc/blog2

// 根据 Parent Id 查询
POST my_blogs/_search
{
  "query": {
    "parent_id": {
      "type": "comment",
      "id": "blog2"
    }
  }
}

// has_child 查询，返回父文档
POST my_blogs/_search
{
  "query": {
    "has_child": {
      "type": "comment",
      "query" : {
            "match": {
                "username" : "Jack"
            }
        }
    }
  }
}

// has_parent 查询，返回相关的子文档
POST my_blogs/_search
{
  "query": {
    "has_parent": {
      "parent_type": "blog",
      "query" : {
			"match": {
				"title" : "Learning Hadoop"
			}
		}
    }
  }
}

索引重建

需要索引重建的场景如下：

索引的 Mappings 发生变更：字段类型更改，分词器及字典更新。
索引的 Settings 发生变更：索引的主分片数发生改变。
集群内，集群间需要做数据迁移。

索引重建的方式：

Update By Query：在现有索引上重建。
Reindex：在其他索引上重建索引。

特性	Update By Query	Reindex
核心操作	原地更新现有索引文档	复制数据到新索引
操作对象	单个索引	源索引和目标索引
数据迁移	不支持	支持
索引结构	不可更改 Mapping/Settings/分片	可更改 Mapping/Settings/分片
主要用途	批量修改文档内容或删除文档	重建索引结构/迁移数据
性能影响	对原索引读写压力大	源索引读压力，目标索引写压力
原子性	非原子操作，失败需手动处理	目标索引独立，失败可重试
适用场景	字段值更新、文档删除	更改字段类型、分片数或跨集群迁移等

字段建模

flowchart LR

    字段类型["字段类型"] --> 是否要搜索及分词["是否要搜索及分词"]

    是否要搜索及分词 --> a1["是否要聚合及排序"]

    a1 --> 是否要额外的存储

Mapping 字段的相关设置：

Enabled —— 设置成 false，仅做存储，不支持搜索和聚合分析（数据保存在 _source 中）。
Index —— 是否构建倒排索引。设置成 false，无法被搜索，但还是支持 aggregation，并出现在 _source 中。
Norms —— 如果字段用来过滤和聚合分析，可以关闭，节约存储。
Doc_values —— 是否启用 doc_values，用于排序和聚合分析。
Field_data —— 如果要对 text 类型启用排序和聚合分析，fielddata 需要设置成 true。
Store —— 默认不存储，数据默认存储在 _source。
Coerce —— 默认开启，是否开启数据类型的自动转换（例如，字符串转数字）。
Multifields 多字段特性。
Dynamic —— true/false/strict 控制 Mapping 的自动更新。

写在最后

这是该系列的第八篇，主要讲解 ElasticSearch 中的数据建模内容，包括如何处理关联关系、索引重建和字段建模最佳实践。可以自己去到 Kibana 的 Dev Tool 实战操作，未来会持续更新该系列，欢迎关注👏🏻。

同时欢迎关注公众号：LanTech指南。不定时分享职场思考、独立开发日志、大厂方法论和后端经验❤️

ES101系列08 | 数据建模和索引重建