ElasticSearch文档数据关联关系处理

ES如何处理关联关系

关系型数据库中的范式化：

• 减少了数据冗余，节省了磁盘空间
• 减少了不必要的更新操作，因为没有了数据冗余，我更新一个地方的数据就可以了，不用去更新冗余数据
• 单查询需要join更多的表，范式简化了更新，读取操作可能更多。

反范式化：

• 不使用join关联关系，而是在文档中保存冗余数据
• 读取的性能更好，并且ES通过压缩_source字段减少所占磁盘空间
• 不适合频繁更新的场景

ElasticSearch就是使用的反范式。ES并不擅长处理关联关系，如果出现了一般会采取以下几种方式：

• 对象类型
• 嵌套对象
• 父子关联关系
• 应用层面自己处理

对象类型

文档中使用一个字段，该字段保存的值value是一个object。这种方式不适用于 value为对象数组的场景，查询会不准确。

如下所示，案例一是适用场景，案例二为不适用场景

案例一 适用场景

博客作者信息变更

对象类型：

• 在每一博客的文档中都保留作者的信息
• 如果作者信息发生变化，需要修改相关的博客文档

DELETE /blog
# 创建一个blog索引，其中的user字段保存的是一个object
PUT /blog
{"mappings": {"properties": {"content": {"type": "text"},"create_time": {"type": "date","format": ["yyyy-MM-dd HH:mm:ss"]},"user": {				# user字段中保存的是一个对象，通过properties关键字定义对象中的字段"properties": {"userid": {"type": "long"},"username": {"type": "text"},"age": {"type": "long"}}}}}
}# 插入一条 blog信息
PUT /blog/_doc/1
{"content": "I like Elasticsearch","create_time": "2024-01-01 00:00:00","user": {			# user字段中保存的是一个对象"userid": 1,"username": "hushang","age": 24}
}# 查询，可以使用使用user.field 对象内的字段查询
GET /blog/_search
{"query": {"bool": {"must": [{ "match": { "content": "Elasticsearch" } },{ "match": { "user.username": "hushang" } }]}}
}

案例二 不适用场景

user字段如果保存的是一个对象数组，在搜索时添加两个查询条件，数组中两个对象分别满足一个条件。

我使用bool must 关键字，表示两个查询条件都需要满足，才会显示文档。但是上方中数组中两个对象分别满足一个条件 这也查询出来了。

DELETE /blog
# 创建一个blog索引，其中的user字段保存的是一个object
PUT /blog
{"mappings": {"properties": {"content": {"type": "text"},"user": {			#  user字段保存 姓 和 名 两个字段"properties": {"first_name": {"type": "text"},"last_name": {"type": "text"}}}}}
}# 写入一条数据  张三和李四
PUT /blog/_doc/1
{"content": "speed","user": [{"first_name":"zhang","last_name":"san"},{"first_name":"li","last_name":"si"}]
}# 查询，此时我的性查询的是zhang  名查询的是si    而且还是采用的bool must方式。我期望的结果是应该查询不到数据
# 但实际上此时能查询到数据
GET /blog/_search
{"query": {"bool": {"must": [{ "match": { "user.first_name": "zhang" } },{ "match": { "user.last_name": "si" } }]}}
}

造成这种情况的原因是

ES在存储文档数据时，内部对象的边界并没有考虑在内，JSON格式被处理成扁平式键值对结构。当对多个字段进行查询时，导致了意外结果。

"content":"speed"
"user".first_name: ["zhang","li"]
"user".last_name: ["san","si"]

可以使用nested data type查询解决这个问题

嵌套对象nested object

• nested数据类型，它允许对象数组中的对象被独立索引

• 使用nested和properties关键字，将上方案例中所有user索引到多个分隔的文档。

• 在内部，Nested文档会被保存在两个Lucene文档中，在查询时做join处理

DELETE /blog
# 创建一个blog索引，其中的user字段保存的是一个object
# 并且使用了type：nested
PUT /blog
{"mappings": {"properties": {"content": {"type": "text"},"user": {"type": "nested", 		# 使用了type：nested"properties": {"first_name": {"type": "keyword"},"last_name": {"type": "keyword"}}}}}
}# 写入一条数据  张三和李四
PUT /blog/_doc/1
{"content": "speed","user": [{"first_name":"zhang","last_name":"san"},{"first_name":"li","last_name":"si"}]
}# 查询
GET /blog/_search
{"query": {"nested": {			# 使用nested关键字"path": "user",	# user字段是nested类型  这里指定nestred类型的字段，并且下面就是对这个字段进行查询"query": {		# 之后就是正常的查询query语句"bool": {"must": [{ "match": { "user.first_name": "zhang" } },{ "match": { "user.last_name": "si" } }]}}}}
}

nested类型的字段，直接进行aggs聚合操作是没有数据的

# user字段是nested类型 直接聚合操作是没有数据的
GET /blog/_search
{"size": 0, "aggs": {"hs_first_name": {"terms": {"field": "user.first_name"}}}
}# 需要添加nestred关键字，并指定user这个字段
GET /blog/_search
{"size": 0, "aggs": {"hs_agg": {"nested": {		# 添加nestred关键字"path": "user"}, "aggs": {		# 再进行聚合操作"hs_first_name": {"terms": {"field": "user.first_name"}}}}}
}

父子关联关系

使用ES时，大部分的场景都不会频繁更新操作，父子关联关系了解即可。

再更新操作时，对象类型和嵌套对象nested方式有一个问题，因为根对象和嵌套对象本质上它们还是存在一个文档中的，每次更新时就可以需要重新索引整个文档。

ES提供了父子关联关系，通过维护parent/child的关系，分离它们，使父文档和子文档是两个独立的文档，更新其中一个文档不会影响另一个文档。

设定 Parent/Child Mapping

# 设定 Parent/Child Mapping映射关系
# 指定我们定义的hs_blog_comments_relation字段类型为join
# 并在relations下指定两个关联的自定义字符串值 其中hs_blog为parent名称，hs_comment为child名称
PUT /my_blogs
{"settings": {"number_of_shards": 2},"mappings": {"properties": {"hs_blog_comments_relation": {"type": "join","relations": {"hs_blog": "hs_comment"}},"content": {"type": "text"},"title": {"type": "keyword"}}}
}

索引父文档

# 索引两个父文档 ,指定文档id为blog1 和 blog2
# 同时指定文档的类型为hs_blog父文档
PUT /my_blogs/_doc/blog1
{"content": "learning ELK ","title": "Learning Elasticsearch","hs_blog_comments_relation": {"name": "hs_blog"}
}
PUT /my_blogs/_doc/blog2
{"content": "learning Hadoop ","title": "Learning Hadoop","hs_blog_comments_relation": {"name": "hs_blog"}
}

索引子文档

创建子文档时，必须通过routing指定父文档id，保证父子文档在一个shard中，提高join查询性能。

当指定子文档时，必须指定父文档id

# 索引三个子文档，指定文档id、同时指定routing 让父子文档在相同的shard中
# 指定文档的类型为子文档，同时必须指定它的父文档id
PUT /my_blogs/_doc/comment1?routing=blog1
{"comment":"I am learning ELK","username":"Jack","hs_blog_comments_relation": {"name": "hs_comment","parent": "blog1"}
}
PUT /my_blogs/_doc/comment2?routing=blog2
{"comment":"I like Hadoop!!!!!","username":"Jali","hs_blog_comments_relation": {"name": "hs_comment","parent": "blog2"}
}
PUT /my_blogs/_doc/comment3?routing=blog2
{"comment":"Hello Hadoop","username":"Bob","hs_blog_comments_relation": {"name": "hs_comment","parent": "blog2"}
}

测试查询

# 查询所有文档，就是正常的查询，能查询到5个文档，因为父子文档都是独立的文档
POST /my_blogs/_search#根据父文档ID查看，也就是正常的查询
GET /my_blogs/_doc/blog2# has_child 查询,返回这个子文档对应的父文档
GET /my_blogs/_search
{"query": {"has_child": {"type": "hs_comment","query": {"match": {"username": "Jack"}}}}
}# has_parent 查询，返回相关的子文档
GET /my_blogs/_search
{"query": {"has_parent": {"parent_type": "hs_blog","query": {"match": {"content": "ELK"}}}}
}

GET /my_blogs/_search
#通过ID ，访问子文档，会发现查询不到数据，返回404
# 但是通过上方直接查询全部是能查询到comment3这个文档的
GET /my_blogs/_doc/comment3
# 通过query语句能查询到到这个子文档
GET /my_blogs/_search
{"query": {"match": {"comment": "Hello"}}
}
#通过ID和routing ，这种方式也能查询到这个子文档
GET /my_blogs/_doc/comment3?routing=blog2#更新子文档，因为使用的是PUT 全量更新，所以在文档中还是需要指定子文档类型和父文档id
PUT /my_blogs/_doc/comment3?routing=blog2
{"comment": "Hello Hadoop??","blog_comments_relation": {"name": "hs_comment","parent": "blog2"}
}

嵌套文档 VS 父子关系