elasticsearch 解决全模糊匹配最佳实践

事件背景:

某 CRM 系统,定义了如下两个表:

客户表 t_custom

字段名 类型 描述
id long 自增主键
phone string 客户手机
... ... ...

客户产品关系表 t_custom_product

字段名 类型 描述
id long 自增主键
custom_id long 客户id
product_id long 产品id
... ... ...

有个页面查询的需求,需要根据手机号模糊匹配,查询出所有匹配上的产品信息。

想要快速实现,可以写出如下 sql:

|--------------------------------------------------------------------------------------------------------------------------------------------------------|
| select * ``from t_custom_product ``as ta ``left join t_custom ``as tb ``on ta.custom_id = tb.id ``where tb.phone ``like %#{phone}% |

过了3年,其中 t_custom 已经有了100w 数据、t_custom_product 有了 1000w 数据,这时候,这条 sql 理所当然成了头号慢 sql。

新来的开发 @纪潘霞,受命解决这个问题。

改造 sql

一开始,纪先生想快速解决,就将 sql 改造成如下模式,然后给 phone 字段添加了正向以及反向索引 index(phone,id) 和 index (reverse(phone),id)

|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SELECT * ``FROM ( ``(``select * ``from t_custom_product ``as ta ``left join t_custom ``as tb ``on ta.custom_id = tb.id ``where tb.phone ``like #{phone}% ``order by id ``desc limit 10) ``UNION ALL ``(``select * ``from t_custom_product ``as ta ``left join t_custom ``as tb ``on ta.custom_id = tb.id ``where tb.phone ``like %#{phone} ``order by id ``desc limit 10) ) ``AS combined ORDER BY id ``DESC LIMIT 10; |

改造之后,查询速度飞起,慢 sql 没有了。但是线上用户开始抱怨了,只输中间号码的场景,无法查询了。例如某客户手机号为:13098830998,查询 988 就无法查询出来。

纪先生说:

es 保存宽表

因为不符合需求,方案打回重做。

这时候,纪先生申请了一套 ES 集群。使用黄工提供的 canal 、datax 技术,将这个表的数据打成大宽表,写入 ES,字段大致如下:

客户关系宽表 index_custom_product (1000w数据)

字段名 类型 描述
id long t_custom_product 的主键
custom_id long t_custom 的主键
phone string t_custom 的手机号
product_id long 产品id
... ... ...

先采用 wildcard 的语句进行查询,查询语句如下 (不加 keyword 什么都查不出来):

|------------------------------------------------------------------------------------------------------------------------------------------|
| GET index_custom_product/_search { ``"query"``: { ``"wildcard" : { ``"phone.keyword" : ``"*#{phone}*" ``} ``} } |

结果发现性能超差,查询资料得知,这种也是走的全表扫描。

es 匹配搜索

考虑 es 本身支持搜索,所以将查询改用搜索的方式:

|-----------------------------------------------------------------------------------------------------------------------------|
| GET index_custom_product/_search { ``"query"``: { ``"match" : { ``"phone" : ``"#{phone}" ``} ``} } |

结果在搜索号码片段的时候,什么都查不出来。查阅资料得知,默认分词器,不会对数字进行分词。

考虑切换成 N-gram 分词器,这个分词器特性如下:

|---------------------------------------------------------------------------------------|
| POST _analyze { ``"tokenizer"``: ``"ngram"``, ``"text"``: ``"Quick Fox" } |

将会返回(其中 min length = 1 ,max length = 2 )

|-----------------------------------------------------------------------------------|
| [ Q, Qu, u, ui, i, ic, c, ck, k, ``"k "``, ``" "``, ``" F"``, F, Fo, o, ox, x ] |

原理讲解部分(略,即兴演讲)

纪先生切换之后,这时候对手机号 13098830995 分词,会返回如下结果:

|-------------------------------------------------------------------------------|
| [ ``1``, ``13``, ``3``, ``30``, ``0``, ``09``, ``9``, ``98``, ``8``...... ] |

然后如果用户查询 988,这个查询会被解析为如下词组的查询

|---------------------------------|
| [ ``9``,``98``,``8``,``88 ] |

显然,可以匹配到手机号 13098830995 的分词,从而查询出结果。

仍然有问题

改造之后,纪先生高兴的发布了,结果毫无疑问的,被测试打回来了。

因为测试拿 998 查询,结果只要手机号有 9 的数据都查询出来了。

因为 match 只要有一个词匹配,即匹配成功。

将 match 改成 match_phrase 即可。

|------------------------------------------------------------------------------------------------------------------------------------|
| GET index_custom_product/_search { ``"query"``: { ``"match_phrase" : { ``"phone" : ``"#{phone}" ``} ``} } |

还有问题?

改造之后,纪先生高兴的发布了,结果又被测试打回来了。

测试拿出 9888 进行查询,这个查询的分词组为:

|---------------------------------|
| [ ``9``,``98``,``8``,``88 ] |

显然,可以匹配到手机号 13098830995。

纪先生接着又改了一版,考虑到查询出的结果集已经比较固定了,所以加了 filter 作为后置过滤,通过正则过滤出正确的手机号。

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| GET index_custom_product/_search { ``"query"``: { ``"must"``: [ ``{ ``"match_phrase"``: { ``"phone"``: ``"#{phone}" }} ``], ``"filter"``: [ ``{ ``"regexp"``: { ``"phone"``: ``"#{phone_regexp}" }} ``] ``} } |

性能问题?调优

发布之后,某天,用户输入了 1111111111111(11个1) 进行查询,因为查询很慢,用户等不及狂点起来了。

毫无疑问的,ES 集群挂了。

这个是个开放性的结果,有后面几个调优方向:

  1. 经过纪先生和产品的激烈沟通,业务同意这个查询框加入一个判断条件:至少输入 4 位数字。然后 ngram length 调整到 4、4。(需要业务妥协,资源消耗少)
  2. ngram 调整 length 到 2、11,但是这样会让 es 内存占用加倍,需要扩容一下 ES。(业务体验最好,最占资源)
  3. ngram 调整 length 到 2、2,然后改用 term 查询,但是会有一定的幻觉。例如 8398 可以查询出 13398830995 => 高亮词汇为 83、39、98。(资源消耗少,极端情况会有异常数据)

这里只是给一个思路,调优本质上还是根据具体业务场景进行定制,技术和业务的互相妥协

相关推荐
binishuaio2 分钟前
Java 第11天 (git版本控制器基础用法)
java·开发语言·git
zz.YE4 分钟前
【Java SE】StringBuffer
java·开发语言
老友@4 分钟前
aspose如何获取PPT放映页“切换”的“持续时间”值
java·powerpoint·aspose
superman超哥12 分钟前
04 深入 Oracle 并发世界:MVCC、锁、闩锁、事务隔离与并发性能优化的探索
数据库·oracle·性能优化·dba
wrx繁星点点19 分钟前
状态模式(State Pattern)详解
java·开发语言·ui·设计模式·状态模式
Upaaui22 分钟前
Aop+自定义注解实现数据字典映射
java
zzzgd81623 分钟前
easyexcel实现自定义的策略类, 最后追加错误提示列, 自适应列宽,自动合并重复单元格, 美化表头
java·excel·表格·easyexcel·导入导出
友善的鸡蛋24 分钟前
解决:使用EasyExcel导入Excel模板时出现数据导入不进去的问题
java·easyexcel·excel导入
星沁城24 分钟前
240. 搜索二维矩阵 II
java·线性代数·算法·leetcode·矩阵
NoneCoder37 分钟前
Java企业级开发系列(1)
java·开发语言·spring·团队开发·开发