OpenSearch通配符查询失效问题及高效搜索方案咨询

问题背景 #

在生产环境OpenSearch中处理百万级员工数据检索，需支持employee_id、employee_name、location、employee_info.external_employee_id字段的部分匹配与全匹配，且要求大小写不敏感。当前query_string查询可正常运行，但wildcard组合查询失效。

有效查询示例（query_string） #

POST /employee_search_index/_search
{
  "query": {
    "query_string": {
      "fields": ["employee_id", "employee_name","location","employee_info.external_employee_id"],
      "query": "Rich*",
      "analyze_wildcard": true,
      "default_operator": "AND"
    }
  }
}

失效查询示例（wildcard） #

{
  "query": {
    "bool": {
      "should": [
        { "wildcard": { "employee_id": { "value": "rich*" } } },
        { "wildcard": { "employee_name": { "value": "rich*" } } },
        { "wildcard": { "location": { "value": "rich*" } } },
        { "wildcard": { "employee_info.external_employee_id": { "value": "rich*"}}} 
      ],
      "minimum_should_match": 1
    }
  }
}

Wildcard查询失效原因 #

1. 大小写不匹配：Wildcard查询直接对索引中的原始词条进行精确匹配，不经过分析器。如果字段使用了standard这类自带小写转换的分析器（text类型），或未配置小写归一化（keyword类型），索引中存储的是小写词条，但原始数据若包含大写内容，仅用rich*会漏掉大小写混合的匹配项；反之若索引存的是原始大小写，rich*也无法匹配Rich开头的内容。
2. 字段类型不兼容：若字段为keyword类型且未配置归一化，原始数据的大小写会被原样存储，此时rich*无法匹配Rich开头的词条。

解决方案 #

一、修复Wildcard查询与大小写不敏感 #

1. Text类型字段处理

确保字段使用包含lowercase过滤器的分析器（如默认standard），查询时将通配符值统一转小写：

// 确认/更新字段mapping
PUT /employee_search_index/_mapping
{
  "properties": {
    "employee_name": {
      "type": "text",
      "analyzer": "standard"
    },
    "employee_info": {
      "properties": {
        "external_employee_id": {
          "type": "text",
          "analyzer": "standard"
        }
      }
    }
  }
}

此时用rich*作为wildcard值，即可匹配索引中已转小写的所有相关词条，实现大小写不敏感。

2. Keyword类型字段处理

为keyword字段配置小写归一器，索引时自动转小写，确保查询与索引词条一致：

// 更新索引设置与mapping
PUT /employee_search_index
{
  "settings": {
    "analysis": {
      "normalizer": {
        "lowercase_norm": {
          "type": "custom",
          "filter": ["lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "employee_id": {
        "type": "keyword",
        "normalizer": "lowercase_norm"
      },
      "employee_info": {
        "properties": {
          "external_employee_id": {
            "type": "keyword",
            "normalizer": "lowercase_norm"
          }
        }
      }
    }
  }
}

二、百万级数据的高效检索优化 #

直接使用wildcard性能较差，推荐根据场景选择以下方案：

1. 前缀匹配优化（xxx*场景）

• 使用Prefix查询：比wildcard更高效，专为前缀匹配设计：

POST /employee_search_index/_search
{
  "query": {
    "bool": {
      "should": [
        {"prefix": {"employee_id": "rich"}},
        {"prefix": {"employee_name": "rich"}},
        {"prefix": {"location": "rich"}},
        {"prefix": {"employee_info.external_employee_id": "rich"}}
      ],
      "minimum_should_match": 1
    }
  }
}

• 开启索引前缀：在字段mapping中配置index_prefixes，提前生成前缀索引，大幅提升前缀查询速度：

PUT /employee_search_index/_mapping
{
  "properties": {
    "employee_name": {
      "type": "text",
      "index_prefixes": {
        "min_chars": 2,
        "max_chars": 10
      }
    }
  }
}

2. 全匹配优化

为text字段添加keyword子字段，用于精确全匹配，避免分析器干扰：

PUT /employee_search_index/_mapping
{
  "properties": {
    "employee_name": {
      "type": "text",
      "analyzer": "standard",
      "fields": {
        "keyword": {
          "type": "keyword",
          "normalizer": "lowercase_norm"
        }
      }
    }
  }
}

全匹配时查询employee_name.keyword字段，性能远高于text字段的精确查询。

3. 中间模糊匹配（*xxx*场景）

使用NGram分析器提前拆分文本为子串索引，避免全索引扫描：

PUT /employee_search_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ngram_analyzer": {
          "tokenizer": "standard",
          "filter": ["lowercase", "custom_ngram"]
        }
      },
      "filter": {
        "custom_ngram": {
          "type": "ngram",
          "min_gram": 2,
          "max_gram": 10
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "employee_name": {
        "type": "text",
        "analyzer": "ngram_analyzer",
        "search_analyzer": "standard"
      }
    }
  }
}

此时用普通match查询即可实现高效模糊匹配，无需wildcard。

4. 保留query_string的便捷性

继续使用query_string并开启analyze_wildcard: true，结合正确的分析器配置，既能支持多字段批量搜索，又能实现大小写不敏感的前缀匹配，性能优于多个wildcard组合。

内容的提问来源于stack exchange，提问作者Kinova