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

[drymonfidelia]

[niubee1]

首先，全文检索对你这个问题的效率也很低，因为订单号你怎么分词？全文检索是建立在分词然后倒排索引的基础上的，你这是需要对十几位订单号，就按 18 位好了，你知道 18 位全组合的组合模式有多少种么？无脑说上全文检索的，先搞清楚全文检索原理先啊。
相比起来
22 楼 @lmshl 的方案更具备工程上的可行性。

[windyboy]

like % 这种类型，数据量大就是要全文索引

[winglight2016]

@drymonfidelia #9 不能既要又要还要啊，哪有懒得输入这种需求的，最多给他提供复制粘贴、图片识别、bar 枪扫码这些工具

另外，ES 并不能解决模糊查询的问题，ES 的反向索引是基于分词去做的，连续的字母数字会被分为一个词，没法提前建立索引。

归根结底，不定长模糊查询查出来的数量无法提前预估，超过 100 条了，必然需要分页，那这个功能对于用户来说毫无意义。

[kaf]

v2 就是性能焦虑太严重，类似需求 6 亿数据 es 查询轻轻松松

[securityCoding]

这种需求一般是数仓来做, 业务做的话应该是缩小数据范围,uid->order id list -> like order id

[dylanqqt]

@lmshl 开战！！

[xmh51]

不确定的检索，推荐 starrocks, ClickHouse 等列数据库，暴力检索，适当的分片，在没有索引的情况下，列数据库比行数据库好多了，你说归档数据就更加适合了，基本上都是数仓的场景，数仓会稍微慢一点点，这个数据量毫秒级。

假如要非常快的查询，可以说服产品，允许少概率查不中的场景，es 分词一般情况下能够命中，某些场景下，会检索不到，它毕竟不是模糊检索。

事实上全世界都没有解决低延迟的海量数据的模糊匹配，快和模糊查询是不可能并存的。

[ichou]

ClickHouse 吧， 你这亿级对它来说都不够看，估计单机都能做到秒级查询
数据比你大一个数量级的，多字段模糊查询 + 统计聚合出报表，分片后也能坐到秒级

ES 很多年我也用过，也是亿级数据（甚至也是查单号），很折腾，除非你能保证一辈子不重建索引，重建一次就半条命

但，我不确定你是不是真的需要这些东西，在企业里这些成本都挺高的
如果你只是单字段有模糊查询的需求的话，pg 都足够应付了，楼上也有兄弟提到了
只有查询没有聚合需求的话，你还可以极端一点，搞一张表两字段，专门用来查询

[Morriaty]

那些说 ES 能搞定的，你们告诉我这种需求，analyzer 要怎么配置？

限制用户查询范围，做前缀、后缀匹配，才是正解

[hejw19970413]

少量多次查询，可以根据发生的查询时间进行少量多次的查询，第一次查询可能是近一周的，根据模糊查询的词的长短来控制查询时间段，关键词越少可能量就会很多，那么就缩短查询的时间间隔。最不理想的情况是数据的全部查询。核心还是前面所说的数据剪枝，根据当前的场景进行条件的增加。

[chobitssp]

新添加 2 列 前后三位 专门用于这种场景

[raysonlu]

这种需求，可以先从产品经理开始优化（ doge

[jhdxr]

@lmshl 嘲讽了半天但你图片里的例子也不是%132%这一类的啊

[liprais]

@jhdxr 建议你再看看

[yudoo]

@yuxian 百亿级别机器啥配置,我们单节点 64G 内存只能存储几千万条数据了

[a67793581]

@photon006 感谢分享

[a67793581]

@lmshl 感谢分享

[yuji]

订单都到亿级了，上个 ES 不过分的

[lefer]

@drymonfidelia #9 好神奇，主要是正常软件 APP 里面都是提供一键复制运单号，我以为输入完整运单号才是简单的。

[sockpuppet9527]

@laminux29 #11 gin index 了解一下 https://www.postgresql.org/docs/current/gin.html