亿级订单表 要对物流追踪号支持 LIKE %123% 这样的前后缀都模糊查询,现在的 MySQL 查一次要几分钟,必须上 ES 或者 ClickHouse 吗?另外归档数据也要查,有没有办法压缩存储数据

查看 750|回复 70
wssy001   
@sagaxu 只顾着优化单条数据查询却不考虑报表聚合查询是吧?
skinny   
@laminux29 虽然但是,难道物流追踪号不是只包含字母数字吗?!
yuxian   
用 ES 吧,毕竟是标配。一次部署,后面梭哈。资源不够加机器,加节点。成本?等你的价值有机器贵了再说。可以早点下班的事儿,为何不干呢?我用 es 处理百亿级别的数据,都很轻松。什么垃圾都可以往里面丢。
ES 有优秀的生态,出问题了,都可以找到相应的解决方案。有专业人在维护。你只是用 ES 做索引而已。又不用担心数据丢失问题。
如果再想加速,套个 redis 也不是不行,对于常常用到的缓存一下。基本上 99.99%都是冷数据。
关系型数据库,已经用 mysql 了,没有必要用 pgdb 。本质上没有太大区别。
isnullstring   
物流号不应该是%%查询呀
想清楚 这个需求是不是对的,是不是硬性要求再考虑怎么做
sagaxu   
@lmshl 19#
1. 订单号不是随机数,部分匹配区分度低,比如 2023 匹配出来就是 2023 年全年订单。
2. pg_trgm 是匹配出相似度大于阈值的条目,跟 is_substring 逻辑不同,有假阳性。
3. 切分单号改成 like 'xxx%'匹配,索引规模放大十几倍,且解决不了'%a??b%'这种。
iseki   
@laminux29 non-word 是指空白符什么的,数字属于 word ,虽然我也不知道这是哪里的规定
iseki   
@sagaxu pg 一般这种场景直接用 like ,系统会自动加一个 recheck 解决假阳性
tairan2006   
伪需求把,模糊查询岂不是信息泄露了……
godwinma   
@Granado 这个思路很合理
ala2008   
不应该先查询出 id ,再去匹配吗
您需要登录后才可以回帖 登录 | 立即注册

返回顶部