【Elasticsearch】`nested`和`flattened`字段在索引时有显著的区别

有同学问,nested查询效率不高为啥不直接扁平化查询呢?就跟之前的普通结构查询一样,这就有些想当然了,因为扁平化的结构在存储时,其实跟我们想的不一样,接下来给出扁平化在索引时的存储结构(尤其是当嵌套对象为数组时)

在 Elasticsearch 中,`nested`和`flattened`字段在索引时有显著的区别,这些区别主要体现在数据的存储方式、查询能力和性能上。以下是详细的对比:


1.数据存储方式

`nested`字段

• 存储方式:`nested`字段将数组中的每个对象作为独立的隐藏文档进行索引。每个嵌套对象可以独立于其他对象进行查询。

• 示例:

```json

PUT my-index

{

"mappings": {

"properties": {

"comments": {

"type": "nested",

"properties": {

"author": { "type": "text" },

"content": { "type": "text" }

}

}

}

}

}

PUT my-index/_doc/1

{

"comments": [

{ "author": "Alice", "content": "Great post!" },

{ "author": "Bob", "content": "Very useful." }

]

}

```

在内部,Elasticsearch 会将每个`comments`对象索引为独立的隐藏文档,类似于:

```json

{

"comments.author": "Alice", "Bob",

"comments.content": "Great post!", "Very useful."

}[

{

"author": "Alice",

"content": "Great post!"

},

{

"author": "Bob",

"content": "Very useful."

}

]

```

`flattened`字段

• 存储方式:`flattened`字段将整个对象扁平化为一个单一字段,所有键值对都被存储在一个字段中。这种方式适合简单的键值对数据,但不适合复杂的数据结构。

• 示例:

```json

PUT my-index

{

"mappings": {

"properties": {

"comments": {

"type": "flattened"

}

}

}

}

PUT my-index/_doc/1

{

"comments": [

{ "author": "Alice", "content": "Great post!" },

{ "author": "Bob", "content": "Very useful." }

]

}

```

在内部,Elasticsearch 会将`comments`扁平化为:

```json

{

"comments.author": "Alice", "Bob",

"comments.content": "Great post!", "Very useful."

}

```

2.查询能力

`nested`字段

• 查询方式:使用`nested`查询,可以独立查询数组中的每个对象。

• 示例:

```json

GET my-index/_search

{

"query": {

"nested": {

"path": "comments",

"query": {

"bool": {

"must": [

{ "match": { "comments.author": "Alice" }},

{ "match": { "comments.content": "Great post!" }}

]

}

}

}

}

}

```

这个查询会匹配`author`为`Alice`且`content`为`Great post!`的评论。

`flattened`字段

• 查询方式:使用普通查询,但无法独立查询数组中的每个对象。

• 示例:

```json

GET my-index/_search

{

"query": {

"bool": {

"must": [

{ "match": { "comments.author": "Alice" }},

{ "match": { "comments.content": "Great post!" }}

]

}

}

}

```

这个查询会匹配包含`author`为`Alice`和`content`为`Great post!`的文档,但无法保证它们属于同一个评论对象。

3.性能

`nested`字段

• 性能:`nested`字段的查询性能通常比普通字段慢,因为每个嵌套对象都被索引为独立的隐藏文档。查询时需要额外的处理来匹配嵌套对象。

• 适用场景:适用于需要独立查询数组中的每个对象的场景。

`flattened`字段

• 性能:`flattened`字段的查询性能通常比`nested`字段高,因为数据结构更简单,索引和查询更高效。

• 适用场景:适用于简单的键值对数据,不需要复杂的查询。

4.总结

• `nested`字段:

• 优点:支持复杂的查询,可以独立查询数组中的每个对象。

• 缺点:查询性能较低,索引和查询更复杂。

• 适用场景:需要独立查询数组中的每个对象,或需要支持复杂的嵌套查询。

• `flattened`字段:

• 优点:查询性能高,索引和查询更简单。

• 缺点:不支持复杂的查询,无法独立查询数组中的每个对象。

• 适用场景:简单的键值对数据,不需要复杂的查询。


5.是否可以在索引时选择使用`nested`或`flattened`?

在索引时,你可以根据需求选择使用`nested`或`flattened`字段,但它们的存储方式和查询能力有显著区别。以下是选择的建议:

• 如果需要独立查询数组中的每个对象,或者需要支持复杂的嵌套查询,应使用`nested`字段。

• 如果数据结构简单,不需要复杂的查询,且需要更高的性能,应使用`flattened`字段。

总之,选择哪种字段类型取决于你的具体需求和数据结构。

相关推荐
Elasticsearch15 分钟前
Elastic 与 Deductive AI 携手合作,加速工程团队的 agent 式事件调查
elasticsearch
Elasticsearch1 小时前
将你的 Grafana Kubernetes 仪表板迁移到 Elastic Observability:相同的 PromQL,30 倍更快的查询
elasticsearch
爱莉希雅&&&6 小时前
elasticsearch+kibana+logstash+filebeat链路部署流程
大数据·elasticsearch·搜索引擎·kibana·logstash·filebeat
前端 贾公子7 小时前
Git Worktree 使用指南
大数据·elasticsearch·搜索引擎
Elasticsearch8 小时前
如何使用 OpenTelemetry 对你的搜索 API 进行埋点,并使用 ES|QL 对其进行查询
elasticsearch
阿里云大数据AI技术20 小时前
更快、更稳、更省:揭秘阿里云 Elasticsearch 存算分离与弹性扩缩
elasticsearch
阿里云大数据AI技术1 天前
Search Lake:ES x Paimon 让湖上多模态数据可搜可用
人工智能·elasticsearch·搜索引擎
Elasticsearch1 天前
Elastic 如何利用磁盘支持的追踪存储将 OpenTelemetry 尾部采样内存占用降低 65%
elasticsearch
.柒宇.1 天前
ELK日志分析系统实战指南:Elasticsearch搭建与入门(8.18.8版本)
运维·elk·elasticsearch·logback·日志系统
Linux-18742 天前
分布式链路追踪系统之二进制安装skywalking
elasticsearch·云原生·skywalking·分布式链路追踪系统·应用程序性能监控