【Elasticsearch】`nested`字段和`join`字段的区别
`nested`字段和`join`字段都是 Elasticsearch 中用于处理复杂数据结构的高级数据类型，但它们在设计目标、使用场景和实现方式上存在显著差异。以下是它们的主要区别：
---
1.设计目标
• `nested`字段：
• 目标：用于处理单个文档中的嵌套数组，将数组中的每个对象独立索引，使其可以独立于其他对象进行查询。
• 场景：适用于需要在数组中独立查询每个对象的场景，例如博客文章中的评论、订单中的商品等。
• `join`字段：
• 目标：用于在同一个索引中建立父子关系，允许文档之间形成层级关系。
• 场景：适用于需要表示一对多关系的场景，例如作者和书籍、问题和答案等。
---
2.数据结构
• `nested`字段：
• 数据存储在同一文档内部。
• 每个嵌套对象被索引为独立的隐藏文档，但仍然属于同一个父文档。
• 示例：
```json
PUT my-index/_doc/1
{
"title": "Elasticsearch Guide",
"comments": [
{ "user": "Alice", "comment": "Great article!" },
{ "user": "Bob", "comment": "Very useful." }
]
}
```
• `join`字段：
• 数据存储在同一个索引中的不同文档中。
• 父文档和子文档通过`join`字段关联，每个子文档必须明确指定其父文档。
• 示例：
```json
PUT my-index/_doc/1
{
"name": "John Doe",
"join_field": "parent"
}
PUT my-index/_doc/2?routing=1
{
"comment": "Interesting post",
"join_field": {
"name": "child",
"parent": "1"
}
}
```
---
3.查询方式
• `nested`字段：
• 使用`nested`查询来独立查询嵌套对象。
• 查询时需要指定`path`，指向嵌套字段。
• 示例：
```json
GET my-index/_search
{
"query": {
"nested": {
"path": "comments",
"query": {
"bool": {
"must": [
{ "match": { "comments.user": "Alice" }},
{ "match": { "comments.comment": "Great article!" }}
]
}
}
}
}
}
```
• `join`字段：
• 使用`has_child`查询来从父文档中查询匹配子文档的条件。
• 使用`has_parent`查询来从子文档中查询匹配父文档的条件。
• 示例：
```json
GET my-index/_search
{
"query": {
"has_child": {
"type": "child",
"query": {
"match": {
"comment": "Interesting post"
}
}
}
}
}
```
---
4.性能和限制
• `nested`字段：
• 查询性能通常比普通字段慢，因为每个嵌套对象都被独立索引。
• 限制：
• 每个索引中允许的最大不同`nested`映射数量默认为 50。
• 每个文档中允许的最大嵌套对象数量默认为 10000。
• `join`字段：
• 查询性能通常比`nested`字段更慢，因为需要动态解析父子关系。
• 限制：
• 每个索引只能有一个`join`字段。
• 父子文档必须索引在同一个分片上。
• 子文档只能有一个父文档，但父文档可以有多个子文档。
---
5.适用场景
• `nested`字段：
• 适用于需要在单个文档中独立查询数组对象的场景。
• 例如：博客文章中的评论、订单中的商品列表等。
• `join`字段：
• 适用于需要表示一对多关系的场景。
• 例如：作者和书籍、问题和答案、产品和评论等。
---
6.总结
• `nested`字段：
• 用于处理单个文档中的嵌套数组。
• 查询时需要使用`nested`查询。
• 性能较好，但有嵌套对象数量限制。
• `join`字段：
• 用于处理父子关系（跨文档）。
• 查询时需要使用`has_child`或`has_parent`查询。
• 性能较差，但适合表示复杂的一对多关系。
---
根据你的具体需求选择合适的字段类型。如果需要在单个文档中独立查询数组对象，`nested`字段是更好的选择；如果需要跨文档表示父子关系，则`join`字段更适合。