Elasticsearch Ngram tokenizer大索引场景查询慢优化咨询

Ngram分词器确实天然存在查询性能低于whitespace、standard这类常规分词器的问题，核心原因是倒排索引的term规模会出现量级膨胀：

• whitespace分词器会按空格把文本拆分为完整词项，单条文本生成的token数和原文本词数基本一致
• 你当前配置的2-3位普通ngram分词器，会把每个词拆成所有长度为2、3的连续字符片段，token生成量是whitespace分词器的10~30倍；再加上你把symbol、punctuation都纳入了token生成范围，还会额外产生大量无意义的符号类token，7000万文档规模下倒排表体积会膨胀十几倍，查询时需要扫描、做交集计算的倒排链长度陡增，6-7秒的返回时长是这类配置下的典型表现，不是配置错误导致的异常。

按优化优先级从高到低排列：

• 拆分索引分词器和查询分词器。这是收益最高的优化项，你当前配置中索引和查询阶段都使用ngram分词器，会导致搜索关键词也被拆成大量短token，大幅增加查询计算量。调整方式为：索引阶段保留ngram分词器保证模糊匹配能力，查询阶段使用不带ngram的常规分词器（比如加了lowercase的whitespace分词器、standard分词器），字段配置示例如下：

"name": {
  "type": "text",
  "analyzer": "custom_analyzer",
  "search_analyzer": "standard"
}

仅这一项调整通常就能带来5~10倍的性能提升。

• 收缩token生成范围。把custom_tokenizer配置里的symbol、punctuation从token_chars中移除，仅保留letter、digit，剔除几乎不会被用户搜索的符号类token，倒排体积可降低30%以上，查询速度同步提升。
• 优先替换为edge_ngram分词器。如果你的业务只需要前缀匹配（比如搜"Tes"能匹配"Test"，不需要搜"est"也匹配"Test"），直接把普通ngram分词器换成edge_ngram分词器，edge_ngram只会从词的起始位置拆分token，倒排规模能降到普通ngram的1/5以内，性能提升非常明显。只有业务必须支持任意位置的中缀匹配时，才需要保留普通ngram分词器。
• 调整分片规模匹配数据量。7000万文档不要使用默认的单分片配置，按集群节点数调整主分片数量，保证单分片文档量在200~500万区间，同时开启查询请求缓存，高频重复查询可直接返回缓存结果，避免重复计算。
• 多字段映射分流查询。给name字段配置多子字段：一个子字段用ngram分词器承载模糊匹配需求，另一个子字段用whitespace/standard分词器承载精确匹配需求。查询时优先匹配精确子字段，命中结果满足返回阈值就直接返回，未命中时再走ngram子字段做模糊兜底，可覆盖绝大多数高频查询场景。

注意：不建议为了压缩倒排盲目调大min_gram参数，比如直接把min_gram从2改成3，会导致长度为2的搜索关键词完全无法召回结果，所有参数调整需要先匹配业务搜索需求再落地。

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