如何低成本解决模糊搜索问题

41个回复

• 

  danbai 会员

  2022年5月26日 09:56
  最近刚好用到了一个搜索引擎，
  0 0
  评论

• 

  Jooooooooo 会员

  2022年5月26日 09:56
  搞个 es 吧
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月26日 09:56
  成本太高了啊，要知道，我们一个后台列表页的需求，按小时算的，就给 2-3 小时工时，去折腾 es ，绩效做不出来
  0 0
  评论

• 

  SjwNo1 会员

  2022年5月26日 09:56
  mysql ngram
  0 0
  评论

• 

  redorblacck886 会员

  2022年5月26日 09:56
  like 的话使用前缀索引好点 、
  0 0
  评论

• 

  Jooooooooo 会员

  2022年5月26日 09:56
  那只有改需求一个法子了. 比如只搜一段时间内的, 数据会少点.
  0 0
  评论

• 

  ragnaroks 会员

  2022年5月26日 09:56
  只读从库
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月26日 09:56
  产品不让，就是要模糊搜索效果
  0 0
  评论

• 

  liaohongxing 会员

  2022年5月26日 09:56
  mysql ngram 全文，最方便的了
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月26日 10:26
  这个好像方便，如果我用自带的全文索引，不装 ngram 这个插件，模糊查找会出什么问题吗？
  0 0
  评论

• 

  pengtdyd 会员

  2022年5月26日 10:26
  需求评审没人提这个问题 ？？？
  0 0
  评论

• 

  liaohongxing 会员

  2022年5月26日 10:26
  大哥 ngram 是 mysq8 内置插件。都不需要装 ，支持中文 ，简单几下就配起来的。不想麻烦，就这个最简单 。比 like 强一点
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月26日 10:26
  那帮蠢货从来不开需求评审，需求时间评估也不让开发评估，都是产品或测试一口价定的时间
  0 0
  评论

• 

  encro 会员

  2022年5月26日 10:26
  Mysql 中文全文索引（含实例 5 分钟上手）
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月26日 10:26
  8 好遥远啊，我们还是 5.6 还是 5.7 来着
  0 0
  评论

• 

  wellerman 会员

  2022年5月26日 10:26
  简单点就用空间换时间，提取关键词（或全部分词），弄个索引。再顶不住了就只有上 ES 了。
  0 0
  评论

• 

  MoYi123 会员

  2022年5月26日 10:26
  换 pg,用 gin 索引
  0 0
  评论

• 

  cowwa 会员

  2022年5月26日 10:26
  搞个 Redi 缓存起来
  0 0
  评论

• 

  teel 会员

  2022年5月26日 10:26
  如果数据量不是特别大的话，把列表内需要搜索的字段全部拉取到前端用 Fuse.js 做模糊搜索。前提是数据量不能太大。 PS：不让开发评估时间的公司还是尽早走吧
  0 0
  评论

• 

  dzdh 会员

  2022年5月26日 10:26
  刚在隔壁帖子里看到了个 zinc 已经在自己的小机器上跑起来了。 meilisearch 自己测试了 1kw 数据服务器内存撑不住了。 要长治久安就用 postgresql 吧，装个 zhparser 还能指定分词和词库。
  0 0
  评论

• 

  sadfQED2 会员

  2022年5月26日 10:26
  5.6 5.7 的 mysql ，不用 es ，不用 like ，那你手动拆词，然后在 mysql 里面建一张表当倒排索引？相当于用 mysql 实现一个简易版的 es 不然的话就找那些奇奇怪怪的 mysql 插件或者存储引擎？但是这种稳定性就不敢保证了 最后，人和代码有一个能跑就行，没有需求评审，也没有技术评审，上线时间拍脑袋决定，我觉得该你跑了
  0 0
  评论

• 

  Latin 会员

  2022年5月26日 10:26
  上个 elasticsearch 解君忧
  0 0
  评论

• 

  3kkkk 会员

  2022年5月26日 10:26
  如果没用过，上面哪种方案用到生产都不是几个小时搞定的。 让产品需求做技术调研，不给时间就让他们自己搞你把上面方案给罗列了。
  0 0
  评论

• 

  Buges 会员

  2022年5月26日 10:26
  当然是 meilisearch ，简单轻量，适合小规模数据。
  0 0
  评论

• 

  clf 会员

  2022年5月26日 10:26
  搜索的时候加上数据量限制？不返回有多少条符合结果的 total 。 前缀搜索的效率会高很多，能走索引。
  0 0
  评论

• 

  documentzhangx66 会员

  2022年5月26日 10:56
  模糊搜索本来就是个成本高上天的事情，其成本比分词方案还要高，所以你这出发点就不对。 你只能采用 有限度的分词 + 主动缓存 + 控制频次的方式，来降低成本，这种思路类似于剪枝，但仍然有一定成本。
  0 0
  评论

• 

  zamaojava 会员

  2022年5月26日 10:56
  不直接 run 吗，兄弟，我上家就是给我 精确 crud ，老子直接不干了
  0 0
  评论

• 

  monkeyWie 会员

  2022年5月26日 11:29
  上 es 分词也难搞定，例如搜索一个字的时候
  0 0
  评论

• 

  nox42 会员

  2022年5月26日 11:29
  lucene
  0 0
  评论

• 

  yufeng0681 会员

  2022年5月26日 13:59
  产品要快速出效果，3 小时的编码， 就只能用 like ，解决业务功能有无的问题； 和项目经理说，后续肯定有性能问题，要解决就得技术 leader 上方案，给你们写业务代码的人用，或者单独给时间做这个性能需求。 至于做不做，那就是项目经理决定。
  0 0
  评论

• 

  makdon 会员

  2022年5月26日 14:29
  看起来开发地位非常工具人呐，代码跟人有一个能跑就行
  0 0
  评论

• 

  westoy 会员

  2022年5月26日 14:29
  跑不动再说吧, like 至少能找到啊.....你分词+fulltext 调教不好， 很多词分错了找都找不到， 更麻烦.......
  0 0
  评论

• 

  lizy0329 会员

  2022年5月27日 07:25
  后端弄个缓存，前端一拉就拉 1w 条数据，应该可以吧
  0 0
  评论

• 

  aikilan 会员

  2022年5月27日 08:25
  你就在群里告诉产品这样会越来越慢呗，产品要是没意见，后果他就自己承担。
  0 0
  评论

• 

  Features 会员

  2022年5月27日 08:25
  啊？ 老版 discuz 不是有完善的方案吗？ 1.限制字数 2.限制搜索频率 3.必须登录后搜索 还有很多我都忘记了
  0 0
  评论

• 

  zhangwugui 会员

  2022年5月27日 08:25
  mysql5.7 的 ngram 尝试过，我记得是有点问题的： 1 ）有些高频数据可能搜不到； 2 ）搜索时间可能时快时慢， 3 ）查询条件过长，还可能触发 cache limit ；
  0 0
  评论

• 

  raptor 会员

  2022年5月27日 08:25
  30 楼正解，得让产品知道每个需求都是有成本的，实现模糊查询是一个成本，实现高性能的模糊查询是另一个成本。
  0 0
  评论

• 

  hatsuyuki 会员

  2022年5月27日 08:25
  小规模数据 meilisearch 最合适，性能高，消耗少
  0 0
  评论

• 

  dog82 会员

  2022年5月27日 09:25
  这个帖子有营养，大家思路好广
  0 0
  评论

• 

  donfisher 会员

  2022年5月27日 09:25
  1. mysql 做全文索引 2. 果断上 es
  0 0
  评论

• 

  brader 会员 (楼主)

  2022年5月27日 09:25
  请问下你这个迅搜项目，可以有自带组件解决 mysql 表数据的全量同步和增量同步的增删改 同步方案吗？还是要自己通过代码进行推送
  0 0
  评论