V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
drymonfidelia
V2EX  ›  数据库

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

  •  
  •   drymonfidelia · 18 天前 · 8253 次点击
    第 1 条附言  ·  17 天前
    这套系统是给其它网店用的 SaaS ,总订单量有几亿条,需求是各店需要能模糊搜索自己店的物流追踪号。各店的订单量不固定,有的店有几千万条,有的店是来测试系统的只有几条
    因为用户经常反馈问题的时候是直接扔张截图甚至模糊不清的照片,OCR 也不太好处理,所以需要模糊搜索追踪号

    详细细节补充见 /t/1086471
    106 条回复    2024-11-13 15:08:47 +08:00
    1  2  
    laminux29
        101
    laminux29  
       16 天前
    @iseki
    你这个例子,假阴性不就出来了:

    4 、5 、
    1234 、12345 、
    2 、23 、2345 、
    3 、34 、
    4 、
    5

    这些都缺失。
    iseki
        102
    iseki  
       16 天前 via Android
    @laminux29 …你要不自己下载个 pg 试一下
    我这个例子只是告诉你 k-gram 是个啥东西,不是说 pg 只会从这几个值里挑一个去找索引。
    iseki
        103
    iseki  
       16 天前 via Android
    @dejavuwind 对的,similarity 就是明确的模糊查询,这个 case 显然要求的是精确查询
    iseki
        104
    iseki  
       16 天前 via Android   ❤️ 1
    @laminux29 pg 的实际做法,可以看做(我没读代码,只说等效结果),按 3gram 输出的所有条目去查 gin 索引,对结果 recheck 。这种做法不可能出现漏掉数据的情况。
    cz5424
        105
    cz5424  
       15 天前 via iPhone
    @julyclyde 我们是这样做的哈哈哈哈
    zzmark06
        106
    zzmark06  
       8 天前
    问题不是一个。
    1. like 优化的问题,上 ngram 分词索引,限制最短 like 字符串长度,n 越大效果越好,能效很强,n=4 情况下索引大概是 5 倍存储
    楼上有 pgtrgm ,这个也是种 ngram 分词索引。
    #86 说分词无法解决这种精确问题的,ngram 这种暴力分词手段专门破这种局面,

    至于,ocr 的结果要模糊,记得一点,like 不是搜索,搜索要多关键词权重匹配,上 es 最简单

    2. 归档数据也要查,这个自己业务上区分查询口,长期的数据归档到列存,clickhouse/doris/hive/iceberg 都行,主要是查询引擎用啥。至于速度,看表设计
    哪怕用列存,like 这种场景,该上 ngram 也是要分的,无索引速度上不来必须要成为基础认知
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3430 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 11:06 · PVG 19:06 · LAX 03:06 · JFK 06:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.