目录
- 一、问题现象
- 二、普通数组类型
-
- 1、为什么普通数组类型匹配不准?
- 三、nested类型
- 四、nested类型查询操作
-
- 1、只根据nested对象内部数组条件查询
- 2、只根据nested对象外部条件查询
- 3、根据nested对象内部及外部条件查询
- 4、向nested对象数组追加新数据
- 5、删除nested对象数组某一个对象节点的数据
- 6、遍历更新nested对象数组的数据
- 7、动态修改nested对象数组的数据
- 8、根据下标修改nested对象数组的数据
- 9、批量修改nested对象数组的数据
一、问题现象
问题现象:在实际项目中,一些数组存储的字段,根据匹配条件去查询经常会查询到一些“其他不需要”的数据,为什么会出现这种情况?
----这种问题现象,就是ES的Object类型的数据扁平化存储问题。
nested类型是object一种数据类型,对象数组的优先选择类型。Nested将数组中的每个对象作为单独的隐藏文档(hidden separate document)进行索引。nested属于object类型的一种,是Elasticsearch中用于复杂类型对象数组的索引操作。
nested类型数据是单独存储很耗资源,因此默认一个index最多只有50个nested字段。此外,虽然nested是单独存储的,但是其字段数也算入index总字段数,默认最多1000个。
二、普通数组类型
普通数组的mapping参数设置
"word_one": {
"properties": {
"desc": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"no": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"sid": {
"type": "long"
},
"sign": {
"type": "boolean"
}
}
}
现在进行搜索sid、desc字段数据。
现象结论:word_one是普通数组List,多个must匹配条件会匹配整个List数组数据,而不是每个Bean去匹配。
1、为什么普通数组类型匹配不准?
原因分析:当字段是普通数组类型,其实在ES中,每个对象元素的属性值被扁平化存储在了数组中,已丢失了对应关系,因此无法保证搜索的准确。
{
"app_id": "42533",
"word_one": [
{
"desc": "南京有好高中么",
"no": "0963",
"sid": 2002,
"sign": false
},
{
"desc": "雨花区面积多大",
"no": "05380",
"sid": 2003,
"sign": false
}
]
}
被扁平化存储到ES中,如下所示
{
"app_id"