Elasticsearch 7.x Nested 嵌套类型查询 | ES 干货

Elasticsearch 有很多数据类型，大致如下：

注意：tring／nested／array 类型字段不能用作排序字段。因此 string 类型会升级为：text 和 keyword。keyword 可以排序，text 默认分词，不可以排序。

Elasticsearch 7.x 文档中，这样写到：

Nested （嵌套）类型，是特殊的对象类型，特殊的地方是索引对象数组方式不同，允许数组中的对象各自地进行索引。目的是对象之间彼此独立被查询出来。

在 ES 的 my_index 索引中存储 users 字段。比如说：

其实存储看上去跟 Object 类型一样，只不过底层原理对数组 users 字段索引方式不同。设置 users 字段的索引方式 Nested 嵌套类型：

比如小老弟我有一波小粉丝，users 字段类型是 object。存储如下：

比如 18 岁大姑娘 Alice 是小老弟我的粉丝，她也可能是周杰伦的粉丝。那这边就有一个需求，即应用场景：

如何找到 18 岁大姑娘 Alice {"name" : "Alice","age" : "18"} 关注的所有明星呢？

如果用老的查询语句是这样搜索的：

结果发现结果是不对的，路人甲 这条记录也出现了。

因为匹配到了第一个 Alice + 第二个 Jeff 的 18。所以这种查询不满足这个场景

那么需要使用 Nested 类型并用 Nested 查询，即让数组中的对象各自地进行索引。目的是对象之间彼此独立被查询出来。

根据 2.2 如何使用 Nested 类型，将 users 字段类型从 object 修改为 nested：

修改后，对应的 Nested Query ，如下：

语法很简单就是：

这样查询得结果就是对的。

这边测试过，给大家一个测试报告和建议。

压测环境：3 个 server ，6 个 ES 节点

压测结论： 使用上小节查询语句，50 并发情况下，导致千兆网卡被打满了。TPS 4000 左右，如果提高并发，就会增加 RT。所以如果高性能大流量情况下，必须用 Nested 应该从网络流量方向进行优化。二者，尽量减少大数据对象的返回

建议：泥瓦匠建议，你听听看

（完）

参考资料：

应用场景当中经常会遇到模糊查询或多条件匹配查询，数据量较小的情况下通过简单的数据库模糊查询是可以解决的，但是对于数据量庞大的情况，数据库模糊查询就会出现性能问题。这种情况下的一种解决方案就是根据查询内容构建反向索引，借助搜索引擎进行查询，提升查询性能。

目前使用比较多的分布式搜索引擎是ElasticSearch。那么项目中如何使用ES？如何保证ES的数据更新？下面简单做个描述。

Elasticsearch使用可以简单分为两个阶段。数据初始化阶段、数据更新阶段。

数据初始化阶段。数据初始化常见的方式如下：

一、通过应用程序手动将数据库中的数据，调用ES接口API插入ES索引库中。

二、同过数据迁移工具将数据初始化到ES数据库。目前常用的ES同步工具有logstash-input-jdbc、DataX。通过同步迁移工具可以全量将数据库数据初始化到ES索引库中。

数据更新阶段。数据更新阶段常见的处理方式如下：

一、通过应用服务直接调用ES更新接口。这种方式实现比较简单但是对业务侵入性比较大。

二、对于实时性要求不高的可以采用定时任务监控数据表变化然后调用ES接口实现数据更新。

三、业务应用中通过发送消息异步更新数据。

四、通过DataX同步工具定时将修改的数据同步到ES库中。

上述是ElasticSearch使用的简单描述。使用的关键还是数据库与ES间的数据同步。能否用的好关键也是数据间的同步。

---