优化 es 中 should 加 matchPhraseQuery 查询性能

先说下优化的背景

我们后端的所有接口有一个质量属性的要求，就是保证我们的接口响应时长不能超过 1s，而这个根据用户名称查询用户昵称是很多其他接口的依赖，首先这个查询的过程，没法做缓存，因为客户那边需要实时看到用户更新的动态，如果将用户名称和昵称做缓存，会出现延迟响应的过程，因此只能考虑怎么更快的查询出一批用户名称对应的用户昵称。

代码存在的问题

代码中其他的查询条件都还 ok，就是有一个地方，会因为批量查询的用户名称越多而导致响应时间变慢，下面是一部分原始代码，由于涉及到业务，只贴出关键性的代码

BoolQueryBuilder userNameShouldBuilder = QueryBuilders.boolQuery();
for (String userName : userNames) {userNameShouldBuilder.should(QueryBuilders.matchPhraseQuery("user_name",userName));
}
boolQueryBuilder.must(userNameShouldBuilder);

为啥要用 should + matchPhraseQuery 的方式查询了？
其实这样看 es 索引的 mapping 字段长啥样

"mappings" : {...,"user_name" : {"type" : "text","analyzer" : "analyzer_1_20"}...,
}

user_name 字段定义了一个自定义的分词器，我们可以通过 analyzer api 看下分词效果

GET index_name/_analyze
{"analyzer": "analyzer_1_20","text": "qq1234"
}

它的结果如下

{"tokens" : [{"token" : "q","start_offset" : 0,"end_offset" : 1,"type" : "word","position" : 0},{"token" : "qq","start_offset" : 0,"end_offset" : 2,"type" : "word","position" : 1},{"token" : "qq1","start_offset" : 0,"end_offset" : 3,"type" : "word","position" : 2},{"token" : "qq12","start_offset" : 0,"end_offset" : 4,"type" : "word","position" : 3},{"token" : "qq123","start_offset" : 0,"end_offset" : 5,"type" : "word","position" : 4},{"token" : "qq1234","start_offset" : 0,"end_offset" : 6,"type" : "word","position" : 5},{"token" : "q","start_offset" : 1,"end_offset" : 2,"type" : "word","position" : 6},{"token" : "q1","start_offset" : 1,"end_offset" : 3,"type" : "word","position" : 7},{"token" : "q12","start_offset" : 1,"end_offset" : 4,"type" : "word","position" : 8},{"token" : "q123","start_offset" : 1,"end_offset" : 5,"type" : "word","position" : 9},{"token" : "q1234","start_offset" : 1,"end_offset" : 6,"type" : "word","position" : 10},{"token" : "1","start_offset" : 2,"end_offset" : 3,"type" : "word","position" : 11},{"token" : "12","start_offset" : 2,"end_offset" : 4,"type" : "word","position" : 12},{"token" : "123","start_offset" : 2,"end_offset" : 5,"type" : "word","position" : 13},{"token" : "1234","start_offset" : 2,"end_offset" : 6,"type" : "word","position" : 14},{"token" : "2","start_offset" : 3,"end_offset" : 4,"type" : "word","position" : 15},{"token" : "23","start_offset" : 3,"end_offset" : 5,"type" : "word","position" : 16},{"token" : "234","start_offset" : 3,"end_offset" : 6,"type" : "word","position" : 17},{"token" : "3","start_offset" : 4,"end_offset" : 5,"type" : "word","position" : 18},{"token" : "34","start_offset" : 4,"end_offset" : 6,"type" : "word","position" : 19},{"token" : "4","start_offset" : 5,"end_offset" : 6,"type" : "word","position" : 20}]
}

通过分词效果很容易看出来，text 类型，会根据自定义的 analyzer 进行分词处理，建立索引的作者的初衷是考虑到我们这个用户名称需要支持模糊查询，同时也支持准确查询。但我们这里的需求是需要的聚合查询，而 text 类型是不支持完全相等查询的。因此要精确查询就只能用 matchPhraseQuery。

matchPhraseQuery 是短语精确查询，它会保证所有分词的顺序以及分词组合都完全一致的才会查询出来，但其实这里还存在另外一个问题，如果用户名称中包含一些标点符号，可能会出现查询结果不准确的问题，因为实际的需求是要找到完全相等的用户名称对应的用户昵称。

更极端的问题是，代码中可能出现内存爆满的问题，或者查询结果超时等问题，举个例子来说比如有一个用户名称为 nownow_ 的用户，那么它会匹配所有去掉停用词的之后只有 nownow 的用户，举个例子来说， idontknownow, snownow, knownow 等都会匹配到，能想象一下如果一次性拿出所有匹配到这些数据，它查出来的结果会有多大。幸好的事我们的代码中加了查询个数限制，是因为当时预发环境测试的时候就发现查询数据量很大的问题，才加的这个限制，只是当时没有对这个问题引起足够的重视，因为测试人员他测试的用户名称很少，且对 es 来说比较好区分的那种。

因此解决这个问题，需要增加一个字段，支持完全相等的查询。

keyword 类型不会分词，是直接建立索引的，支持完全相等的查询。

同时由于我们同时要支持一次查询一批用户的昵称，所以需要配合should 进行查询

总结问题：

matchPhraseQuery + should 查询性能低，批量查询的用户名称越多，性能越差
现有的实现未满足需求要求，分词时会移除标点符号等无意义的词，可能造成查询结果不准确

解决存在的问题

既然需要一个不分词的字段，自然考虑到添加一个 keyword 的字段， text 下面天然支持 keyword，通过下面的方式给已有的字段添加一个 keyword 字段

PUT /index_name/_mapping
{"properties": {"user_name": {"type": "text","analyzer" : "analyzer_1_20","fields": {"keyword": {"type": "keyword","ignore_above": 256}}}}
}

现在直接去查这个 keyword 字段是没有数据的，需要重新索引下数据。

通过 _update_by_query 重新索引下数据，这样 keyword 中就有数据了，这里可以根据业务条件，限定下数据量，注意在 _update_by_query 之前最好看一下查询条件对不对, 比如我这里只考虑有 nick_name 字段的数据

GET index_name/_count
{"query": {"bool": {"must": [{"exists": {"field": "nick_name"}}]}}
}

确认没问题之后，就可以重建下索引了

POST index_name/_update_by_query?conflicts=proceed&slices=4
{"query": {"bool": {"must": [{"exists": {"field": "nick_name"}}]}}
}

注意： conflicts=proceed ， _update_by_query 在开始执行的时候获取一个快照，类似 scroll 查询，此时的数据会控制一个内部版本号，如果快照的数据在 update 的时候，已经有过更新处理，那么就会出现版本号冲突，导致更新中断，抛出更新冲突异常。conflicts=proceed 就是在遇到版本冲突的时候，不会中断 update 操作, 只是做简单的冲突计数，我们这里只是给 keyword 字段建立一个索引，所以不用考虑文档更新冲突问题。

如果数据量很大，_update_by_query 可能会执行很长的时间，怎么看它的进度，可以直接查已经建立 keyword 索引字段的数据量来计算大概的进度

GET index_name\_count
{"query": {"bool": {"must": [{"exists": {"field": "user_name.keyword"}}]}}
}

这里可能有的小伙伴不理解为啥，不直接建个索引，然后 reindex 下就行，搞这么麻烦，首先这里有前提条件，一个索引数据量很大，上亿，但真正要重建索引的数据很少，另外一点就是这个索引在实时用的，迁移的过程当中很难保证重建之后的索引数据状态，需要做许多额外的工作，可能比这个过程更加复杂，更加漫长。

keyword 字段建立索引之后，就需要修改代码了，来优化查询

boolQueryBuilder.must(QueryBuilders.termsQuery("user_name.keyword",userNames));

修改完代码，可以在预发环境测试下，查询性能