Elasticsearch 中嵌套索引的优点和缺点是什么?
我正在考虑某些用户或设备的时态数据,因此平面的意思是所有数据都存储在索引的根目录中并嵌套,我的意思是数据按设备/ID 分组。因此,有一个按用户/设备 ID 划分的文档,其中每个时间条目包含一个文档。
我认为优点是:
缺点是:
我们来谈谈flat fields,,,,,之间dynamic的优缺点。objectflattenednested
优点:简单明了,字段类型在映射中指定。
put mapping缺点:首先应该做新领域。字段数量受引擎限制。不同领域没有任何关系。
对于没有表示映射的新字段或内部对象。
设置为 false,不会索引新字段,但可以通过 检索新字段_source。
设置为strict,当doc中未知新字段时会报错。
缺点:严格没有弹性,同时动态会导致映射爆炸问题,因为Elasticsearch默认限制最大字段数为1000,另请参阅index.mapping.total_fields.limit: 1000
比 daynamic 更好的类型,附带 7.3 +
优点:领域数量不受限制,所有事物都如其名称所描述的那样扁平化。
缺点:只支持少数查询:term或exist,没有突出显示。
{}在映射中使用时,对象是另一个默认值。
优点:支持自然,也适用于内部对象
缺点:不支持对象数组。Elasticsearch 实际上没有内部对象的概念。因此,它将对象层次结构扁平化为一个简单的字段名称和值列表,查看https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html#嵌套数组展平对象
优点:支持对象数组或数组对象的复杂结构,也可以将它们分开保存,从而保留单个对象内部的字段关系。假设我们有一个候选人指数,并且许多候选人具有多种教育背景。通过嵌套字段,我们现在可以检索毕业于 CMU 计算机科学专业的候选人。
缺点:每个嵌套对象都作为单独的 Lucene 文档进行索引,1 个包含 100 个嵌套对象的文档将创建 101 个 Lucene 文档。
嵌套内的字段和对象都有限制,默认为 50 和 10000。
完全同意你关于 ES 嵌套类型的优缺点的看法。只是想详细说明索引成本的深度。请记住,嵌套字段也会打开查询功能
如果您使用嵌套类型和不频繁的修改,那么它非常棒,并且可以为查询创建更广泛的范围,但如果您经常进行更改,那么它将带来巨大的成本。
nested类型映射在索引方面比平面类型映射具有更大的影响。由于Lucene 没有任何嵌套对象类型的概念,所有内容都存储为平面对象。因此在索引时执行了一个额外的操作。
想象一下,您有一个大型嵌套文档,可转换为 100k 内部文档,并将其与平面数据模型进行比较,在该模型中我们已将 100k 部分索引为独立文档。如果我们在最深的嵌套级别添加单个嵌套文档,这将添加单个平面文档,而嵌套文档最终将重新索引 100k+ 1 个文档。另一方面,如果您在根目录更改某些内容,则在这两种情况下都需要更新所有文档。因此,您可以想象单个文档更改可能会导致您重新索引该文档的所有嵌套字段。
| 归档时间: |
|
| 查看次数: |
7797 次 |
| 最近记录: |