elasticsearch nested object查询带空格

最新推荐文章于 2024-08-19 18:00:44 发布

墨笙弘一

最新推荐文章于 2024-08-19 18:00:44 发布

阅读量942

点赞数

分类专栏：分布式搜索引擎ElasticSearch 文章标签： elasticsearch

本文链接：https://blog.csdn.net/u012934325/article/details/111951726

版权

本文通过一个保险业务案例，探讨了Elasticsearch中nested object类型的查询问题。在解决被保人姓名查询不匹配的问题时，发现fullName字段使用text类型导致分词，影响精确匹配。解决方案是将fullName类型改为keyword，以避免分词。此外，文章还介绍了nested object的模糊查询、mapping结构查看、索引设置检查以及处理多个对象的情况，并解释了查询结果中为何返回多个匹配项的原因。

摘要由CSDN通过智能技术生成

这里总结一个实践的case，是关于elasticsearch中对于nested object类型的查询

问题背景

在保险业务中，存在投保人和被保人的概念，一般一个保单是只有一个投保人，一个被保人，也存在团单，一个投保人多个被保人。实际的需求是按照被保人的姓名去查询，结果发现返回的结果不匹配或者不存在命中的文档

问题分析

在我们业务中，因为数据库采用了分库分表，所以在b端画面的查询，如果去数据库查询，效率肯定会慢，因为多个库的数据，还存在分表，最后做聚合，性能方便肯定存在问题，最后采用elasticsearch对一些核心数据进行存储，供B端画面查询。

在出现问题后，分析了一下现有定义的elasticseach的文档mapping，发现对应的被保人姓名fullName是text类型，如果了解es，那么知道text类型的数据，是会被分词的，什么叫分词，可以自行查询了解一下。举个简单的例子，你输了的fullName为张三里斯，如果你直接用张三里斯去查询，无法命中，因为分词以后存储的可能是两个词张三和里斯，那么你想做精准匹配是无法实现的。

最后修改了fullName的type为keyword，keyword是不会被分词，且在搜索中的查询效率是高于其他的。

实验验证

定义一个nested object的索引mapping

PUT my_index
{
   
  "mappings": {
   
    "my_type": {
   
      "properties": {
   
        "user": {
   
          "type": "nested" ,
          "properties": {
   
            "first"