索引漏洞正悄悄拖垮你的搜索体验

　　索引漏洞正悄悄拖垮你的搜索体验

　　去年12月，我在给“华东医疗影像云平台”做第二批历史胶片元数据补录时——整整37万条DICOM文件路径，带嵌套目录结构和12位医院编码前缀——突然发现：用平台内置搜索框查“上海仁济东院_202111_CT”，返回结果缺了2019年11月混入的436条急诊加扫数据。不是没录入，是索引层根本没抓取那批带下划线+空格+中文括号的原始文件名。

　　我调出ES 7.10集群日志，发现index_refresh_interval设成了30s，但实际refresh耗时波动在12~47秒之间——其中23%的refresh请求因“nested field depth limit exceeded”被静默丢弃，连错误计数器都没触发。更荒谬的是，运维给我的截图里，/health接口返回“green”，可真实分片状态却是yellow，因为17个副本分片里有5个卡在“searching”而非“done”。

　　新技术？对。但去年12月那会儿，他们连字段映射都没做动态模板校验，直接把OCR识别结果（含换行符、全角空格、GB2312乱码）原样塞进keyword类型字段。我亲眼看见一条“心电图_报告-2021-12-08.docx（存档）”被截断成“心电图_报告-2021-12-08.docx（存档”，末尾右括号丢了，导致整个前缀匹配失效。这哪是新技术？这是拿新瓶装漏筛的米。

　　上个月帮某省疾控中心清理2019–2023年传染病上报数据，发现他们用Logstash管道处理XML转JSON时，对发热、咳嗽这类含顿号的节点，自动生成的索引字段名居然是symptom_0、symptom_1——因为默认分隔符设成了中文顿号。结果所有症状组合查询都得靠脚本暴力遍历12个字段。我当场导出mapping配置，发现type字段赫然写着text而不是keyword，连模糊搜索都打不中精确值。谁干的？不知道。问三个对接人，说法都不一样。

　　失败案例？去年12月那次，我就重跑了19次索引重建任务。第一次用bulk API失败；第二次关掉refresh后仍卡死在shard relocation；第三次被迫手动删除4个corrupted segment——删完才发现，那些段里藏着2018年某地市上报的狂犬病暴露处置记录，因字段长度超限被截断成“暴露部位：左__”，后面“手背”两字永远消失了。现在再搜“狂犬病+左”，0结果。它没丢，只是索引看不见。

　　我说它优点在“新技术”，纯属反讽。新是新，可连基础schema校验都绕开。像某家叫“智搜芯”的SaaS厂，2023年Q3上线的“语义增强索引引擎”，实际只改了Query DSL语法糖，底层还是用旧版Lucene 8.6硬扛——而他们宣传页写的可是“全栈自研向量索引”。我试过上传同一份PDF，让他们的API跑三次：第一次返回7条相关，第二次12条，第三次只有3条。三次request_id不同，但trace_id都指向同一个分片——那个分片正在执行forceMerge，却谎报“ready”。

文章配图，仅供参考

　　我今天上午刚收到客户邮件，说要上线新版OCR识别服务，对接现有检索模块。附件里没提mapping变更说明，也没给字段样例。我打算先抓包看POST payload，再查下他们Kibana里最近7天的query error rate直方图——但说实话，我不确定会不会又撞上那种“日志显示成功，结果页面空白”的经典索引失联。

　　这活我干了15年。录入没错，归档没错，校验也没错。错的是，有人把索引当成开关按钮，一按就亮。它不是灯，是漏水的水管。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!