一、现象75MB 的表吃掉了 48.6GB 磁盘先交代背景这个问题是我在给一款本地化部署的微信自动回复工具做知识库支撑时踩到的向量存储选了 LanceDB——一个嵌入式向量数据库数据直接落在本机的文件目录里不需要额外部署任何服务进程对单机场景刚刚好。表结构也不复杂文档切片后的文本列、向量化后的向量列再加几个元数据列因为检索场景既要求语义检索又要求关键词检索文本列上还建了一个 FTS 全文索引。出事那天的现象非常直接项目上线跑了两天磁盘可用空间告警掉了将近五十个 GB。第一反应是日志或者缓存写疯了逐层排查后却发现日志目录一切正常空间几乎全部集中在那张知识库表的_indices目录里——索引目录。更麻烦的是增长看不到头报警之后的几个小时内这个目录还在以每次启动几十 MB 的速度往上爬。这不是一次性的异常写入更像是有某个循环在持续制造垃圾而且制造出来的垃圾永远不会被清扫。先把基准数据交代清楚后面所有结论都建立在这组数字上这张表一共 13263 行数据本体约 75MB。而_indices目录占掉的空间是 48.6GB。也就是说索引体积做到了数据体积的约 648 倍。75MB 的文本膨胀出 48.6GB 的索引这个比例已经完全不能用索引本身有开销来解释——再重的倒排结构对 75MB 文本也不该放大到这个量级。一定有什么东西在持续制造索引文件而且从来没有被回收过。二、排查先怀疑向量索引走了一段弯路2.1 弯路第一个嫌疑人是向量索引排查直觉先入为主了向量数据库嘛膨胀八成出在向量索引上。我当时押注两个方向一是向量索引的构建参数没调好导致单个索引文件异常巨大二是建索引的代码被并发重复执行磁盘上写出了多份向量索引副本。沿着这两个方向折腾了一阵把建索引的代码翻了个底朝天向量索引确实只在首次初始化时创建一次参数也正常不存在重复构建再看向量索引文件的体积一直稳定不变没有增长迹象。向量索引这条路走死了但排查没有白费——翻代码的过程顺手确认了一件重要的事项目里显式建过的索引只有两个一个向量索引、一个 FTS 索引。既然元数据层面的索引只有两个那磁盘上多出来的东西就必然来自别处。2.2 换个角度从目录树和修改时间入手换个思路不再猜哪种索引有问题直接看磁盘上到底多了什么、什么时候多出来的。# 逐层看磁盘占用从库根目录往下钻du-shdata/lancedb/*du-shdata/lancedb/kb_table.lance/*du-shdata/lancedb/kb_table.lance/_indices结果非常刺眼数据目录体积正常_indices目录异常。接着看文件的修改时间发现索引目录下大量文件的时间戳精准地落在项目每次启动的时间点上。这就诡异了——向量索引只在第一次初始化时建过之后每次启动都有新文件写进索引目录写的到底是什么把_indices的目录树完整列出来答案的轮廓出现了索引目录下有 1492 个子目录。一张只显式建过两个索引的表索引目录里躺着将近一千五百个快照目录这绝不是正常状态。这里插一句排查方法论当代码看起来没问题和磁盘持续增长同时成立时最有价值的信息往往不在代码里而在文件系统层面——哪些目录在涨、涨的时间点分布是什么。这次时间戳分布直接把排查范围从通读全部代码收窄到只看启动链路后面所有的定位都是沿着这条线索走完的。先看证据再看代码顺序反了就是在原地打转。2.3 版本数与目录数对上了LanceDB 是版本化存储表有版本号的概念每提交一次写入版本号就前进一格。查这张表的版本列表写版本累积到了 1517 个。1492 个索引子目录对 1517 个写入版本两个数字的量级严丝合缝。随机打开几个不同时间段的索引子目录对比内部结构完全一致都是一份完整的 FTS 倒排索引体积都在 33MB 上下。结论基本清晰了几乎每个写入版本都随身携带一份全量的 FTS 索引快照旧版本不被清理每份快照就一直占着磁盘。2.4 谁在批量制造写入版本接下来的问题是这张表两天里哪来的一千五百多个写入版本线索其实早就摆在眼前——大量索引文件的时间戳集中在每次启动。打开初始化脚本问题找到了脚本在每次启动时都会调用 createIndex 给文本列建 FTS 索引没有做任何索引是否已存在的检查。而这里暴露出本次事故最核心的一个坑createIndex 不幂等。索引已经存在时再次调用它不报错、不跳过而是老老实实重新构建一遍。实测每次重复调用都会新增约 33MB 的索引文件并提交一个新的写入版本。那两天正处于密集开发期改代码、重启服务的频率非常高每次重启都触发一次重复建索引。算一笔账1492 份快照每份约 33MB合计接近 48GB与实测的 48.6GB 基本吻合差值来自数据写入产生的少量额外版本和索引元信息文件。数字对上了链条闭合了。最后一环为什么这些旧快照没有被自动回收全项目搜索了一遍从初始化脚本到定时任务没有任何地方调用过 optimize。垃圾从产生的那一刻起就被判了无限期留存。三、根因分析MVCC 版本化存储的三个效应叠加单看每一环都不致命叠在一起就是 48.6GB。把原理拆开讲清楚。3.1 MVCC一切写入都是新版本旧文件一个不删LanceDB 底层是一种 MVCC多版本并发控制的版本化列式存储磁盘布局大致是这样kb_table.lance/ ├── data/ # 数据文件按 fragment 切分 ├── _indices/ # 索引文件快照 └── _versions/ # 每个版本的 manifest清单它的核心设计是不原地修改。任何一次写入——追加数据、更新、建索引、删索引——都不会改动已有文件而是生成一份新的 manifest作为一个新版本原子提交。manifest 记录的是这个版本引用了哪些数据文件、哪些索引文件引用关系靠文件 UUID 建立。这套设计换来的好处非常实在读者读到的任何一个版本永远是完整且一致的快照写操作不需要加锁去阻塞读同时天然获得时间旅行能力只要旧版本还在就能把表回滚到任意历史时刻。对分析型负载和需要一致性读的场景这是非常舒服的语义。但代价同样明确旧文件不删。只要还有任何一个版本引用某个文件这个文件就必须留在磁盘上。空间回收在这类存储里被设计成一个显式动作而不是写操作的自动副作用。换句话说在这套模型里写只管前进删历史是另一件必须有人负责的事——本案例里没有人负责。再把成本模型说透。每次提交生成的 manifest 本身很小真正占空间的是它背后引用的文件集合新版本会带来新的数据文件或索引文件而旧版本引用的旧文件因为仍被引用而全部保留。于是磁盘占用不再等于数据有多大而等于所有存活版本引用的文件总和。版本数越多、每个版本携带的新文件越多这个总和涨得越快。理解了这一点索引膨胀就从一个玄学问题变成了一个可以精确计算的算术问题总膨胀量约等于新增版本数乘以每个版本新增的索引体积。本案例里就是一千五百多次构建乘以每份 33MB。3.2 为什么每个写入版本都带一份全量 FTS 索引快照传统数据库的二级索引比如 B 树可以在原文件上做原地修改插入一行顺手在索引树上改几个页旧页直接被覆盖索引体积不会随写入次数膨胀。Lance 这类基于不可变文件加 manifest 引用的格式走了另一条路索引文件本身也是不可变对象。一份 FTS 倒排索引一旦生成就是一组只读文件当表产生新的写入版本时新版本需要一份属于自己的索引状态索引就被整体物化成一份新的快照文件集挂在新版本的 manifest 上。旧版本的那份快照继续被旧版本引用着一个字节都不动。所以在这个模型里“建索引不是给现有数据打一个标记而是为当前版本物化出一整份索引”。FTS 索引要对文本列的每一行建立倒排项75MB 文本对应的倒排结构约 33MB量级完全合理。于是每次 createIndex 都意味着三件事同时发生新写约 33MB 索引文件提交一个新版本旧版本的 33MB 快照继续留存。更隐蔽的是即便两次调用之间数据一行都没变createIndex 本身也是一次写操作照样产生新版本和新快照——这正是本案例的膨胀引擎。为什么索引不能像数据那样做成小粒度增量可以对比两类对象在写入时的处境。数据侧的追加天然是增量的新来一批文档就写一个新 fragment旧 fragment 原封不动manifest 把新旧 fragment 一起列为引用即可代价很小。而 FTS 倒排索引的结构是全局性的一个词项的倒排列表横跨全表所有行新增几行文档意味着大量词项的倒排列表都要变化很难只追加几个小文件就把变化表达清楚。实现上选择每个版本物化一份完整索引本质是用空间换正确性和简单性。这个选择单看每一次都没有问题问题出在它和不幂等的调用方组合在一起构建一次复制一份构建一千次复制一千份。3.3 createIndex 为什么不幂等从 API 语义上讲createIndex 的职责是执行一次索引构建并提交新版本它不负责检查并跳过已存在的索引。是否重复构建被设计为调用方的责任。这个语义本身未必算缺陷——确实存在需要主动重建索引的场景——但它把一个关键判断留给了调用方而初始化脚本恰恰没有接住这个责任每次启动无脑调一次 createIndex每次调用等于新版本 新快照 旧快照继续留存三连击。重启二十次就是六十份 33MB 的垃圾重启七十次就是近 5GB两天重启七百多次就是 48.6GB。3.4 cleanup 的默认保留期7 天的安全默认与本案例的死结MVCC 存储为什么不自动清理旧版本因为清理必须回答一个问题还有没有人可能正在使用旧版本某个长时间运行的查询可能还挂在十分钟前的版本上后台如果按超过一分钟就删的激进策略清理读者会直接崩溃。进程之间无法可靠地互相回答你还在用哪个版本于是工程上用时间兜底只清理超过保留期的版本默认保留期是 7 天。这个默认值在长期运行的生产服务上是偏保守的安全选择但对我们这个场景恰好构成死结所有垃圾都是最近 48 小时内产生的离 7 天的保留期还远得很。实测在默认参数下调用清理返回的 bytesRemoved 是 0——等于什么都没做。这是从没调过 optimize之外的第二层坑就算有人调了 optimize不显式修改保留期参数也收不回一个字节。换个角度理解保留期本质上是一个租约存储假设七天之前的旧版本已经不太可能还有读者挂着才放心回收。这个假设在长周期服务里成立在重启频繁的开发机上完全失效——垃圾产生的速度远快于租约到期的速度清理永远在空转。所以默认参数安全和默认参数有效是两回事动手之前必须先想清楚自己的时间尺度属于哪一种是周级长跑还是分钟级高频迭代。参数没有对错只有和场景匹不匹配。3.5 compaction 与 cleanupoptimize 到底管两件什么事optimize 实际覆盖两类维护动作必须分清楚。一类是 compaction碎片合并把高频写入产生的小数据碎片合并成大文件降低读放大解决的是碎片多、读得慢的性能问题另一类是 cleanup版本清理把超过保留期的旧版本从版本链上摘除再物理删除所有不再被任何存活版本引用的文件解决的是磁盘被历史版本吃掉的空间问题。本案例只需要 cleanup但两者共用 optimize 这个入口。这里有个容易踩的认知误区值得单独提醒如果误以为 compaction 能省空间很可能白忙一场——它合并的是数据碎片动不了索引快照的历史对_indices目录的膨胀无能为力。动手之前先想清楚自己要的是性能还是空间参数完全不同。四、修复一条 optimize两个必须绕开的坑修复的核心代码只有一行// 回收历史版本占用的空间awaittable.optimize({cleanupOlderThan:newDate(),// 保留期设为当前时间现存旧版本全部视为可清理deleteUnverified:true,// 顺带回收未被 manifest 验证的孤儿文件});实测这一次调用回收了 48.5GB48.6GB 的膨胀几乎全部消失。但这一行代码能一次写对靠的是先踩了两个坑。坑一默认参数下 cleanup 实测 bytesRemoved0修复前我先跑了一次不带参数的 optimize结果返回的 bytesRemoved 是 0磁盘纹丝不动一度让人怀疑这条 API 路线根本不通。原因就是 3.4 节讲的默认保留期默认只清理 7 天之前的旧版本而我们的垃圾全部产生在两天之内全部躺在保护窗口里。必须显式把 cleanupOlderThan 设为当前时间语义才变成现在之前的所有历史版本都可以清。坑二保留期参数必须设到分钟级第二个坑在参数粒度上。保留期参数的默认值太宽是天级思维而我们的实际问题是分钟级的——重启频繁的开发机上几分钟就能堆出几十个版本。清理参数必须给到分钟级精度要么直接取当前时刻要么按最后写入时间加若干分钟来算。否则清理节奏永远追不上垃圾产生的速度这次清完下次重启又开始膨胀治标不治本。红线绝不能手动删除 _indices 目录排查过程中我一度动过最直接的念头把_indices下的旧目录手动删掉不就行了。这条路是绝对红线千万不能走。原因在 manifest 的引用机制上每个版本的 manifest 按它引用的索引文件 UUID 来管理索引磁盘目录名就对应这些 UUID。手动删除目录之后manifest 里引用的 UUID 与磁盘上的目录对不上数据一致性无法验证——这不是删掉了一些文件而是把版本链人为打断制造出无法自证完整性的状态而且没有受支持的修复路径。换句话说手动删除把空间问题升级成了一致性事故。空间回收只有一条正路走 optimize由它来统一更新版本链、解除旧引用、再删除已解绑的文件全程保证 manifest 与磁盘的对应关系不被破坏。事后想想这条红线其实是所有版本化存储的通用守则凡是引用关系记录在元数据里的系统文件和元数据就必须一起变更任何只动文件不动元数据的操作都是在制造系统无法自知的损坏。删除永远应该元数据先行——先让清单不再引用再让文件消失顺序反了就是事故。五、验证空间回收类操作数据一个都不能少清理历史版本最大的风险是顺手把活数据也清了——保留期给错、引用判断出错都可能让当前版本的数据文件被误删。所以验证做了三个层面一个都不能省。验证的顺序也有讲究FTS 检索的基线必须在 optimize 之前采集。如果先清理再补基线命中结果一旦出现差异你将无法判断到底是清理误删了索引内容还是前后两次查询本来就有环境差异——基线的全部价值就在于它锚定的是清理前这个时点时点错了基线就失去了对照意义。第一层行数与内容完整性constrowCountawaittable.countRows();console.log(rowCount);// 13263与修复前完全一致第二层检索功能基线对比。optimize 之前先用同一批关键词跑了一轮 FTS 全文检索把每次命中的文档列表存成基线optimize 之后用同样的关键词重跑逐条比对命中结果——与基线完全一致。这说明被回收的是旧版本的索引快照当前版本引用的那份 FTS 索引完好无损检索行为没有任何变化。第三层回归测试。项目里覆盖入库、检索、初始化幂等性的 288 个测试用例全部通过同时确认 git 工作区干净不存在改一半的代码状态干扰验证结论。三层全绿修复才算坐实48.5GB 回收13263 行数据零损失FTS 全文检索命中与基线一致。六、长效预防幂等化 带三道闸的周期维护事故修完只是止损让它永远不再发生才是闭环。落地了两件事。6.1 初始化脚本幂等化先查再建把每次启动都 createIndex改成先 listIndices 查询再决定是否建索引asyncfunctionensureFtsIndex(table:Table){constindicesawaittable.listIndices();constftsExistsindices.some((idx)idx.columns.includes(content));if(!ftsExists){awaittable.createIndex(content,{config:lancedb.Index.fts()});}}createIndex 不幂等是 API 的既有语义那幂等性就由调用方补齐启动时先查索引清单存在即跳过。这一改每次重启新增 33MB的源头被直接掐断初始化脚本无论被调用多少次都只会在索引真正缺失时写一次盘。6.2 六小时周期维护三道闸 短重试第二件事是新增一个 6 小时周期的定时维护任务来执行 optimize。但 optimize 不能裸跑——cleanupOlderThan 给得太激进可能清掉仍有读者挂着的版本。所以触发前设了三道闸全部满足才动手无灌库进程在写当前没有任何导入、同步任务持有这张表的写句柄确保清理不与写入并发库静默超过 30 分钟最后一次写入距现在超过 30 分钟确保没有在途操作挂在近期版本上给清理留出安全边界索引/数据体积比 ≥ 3索引体积超过数据体积 3 倍才认定确实积累了值得清理的快照避免无意义的空转清理。前两道闸看起来有重叠为什么缺一不可写句柄检查拦住的是此刻正在写的并发冲突但它拦不住刚结束的写入一次导入刚提交完写句柄已经释放可新提交的版本号是最高的此时立刻清理旧版本仍可能干扰依赖近期版本的一致性读。静默窗口兜住的正是这层刚写完不久的残余风险。第三道闸则是成本控制索引体积没有异常时清理没有收益跑了也是白跑还白白制造一轮 IO。三道闸分别回答能不能清、清了安不安全、值不值得清三个问题各自独立互不可替代。asyncfunctionmaintenanceTick(table:Table){constgatesawaitcheckGates(table);// 三道闸无写入进程 / 静默超 30 分钟 / 索引数据体积比 ≥ 3if(!gates.allPassed){scheduleShortRetry();// 闸门不满足进入分钟级短重试而不是等满 6 小时return;}awaittable.optimize({cleanupOlderThan:newDate(),deleteUnverified:true,});}短重试这个细节值得单独强调。最初版本里闸门不满足就直接跳过本轮任务要再等 6 小时才有下一次机会如果闸门恰好在周期开始后五分钟才满足等于白等了近 6 小时。改成闸门不满足时进入分钟级的短重试循环条件一满足立刻补跑维护的及时性就不再被周期长度绑架。写在最后复盘下来这 48.6GB 不是某一个 bug 造成的而是三个设计事实的乘积MVCC 版本化存储让旧版本天然留存索引快照随版本全量复制写一次索引就多一份createIndex 把幂等性责任留给调用方。三个环节任何一个有防御事故都不会发生三个环节同时失守就是 648 倍的膨胀、两天 48.6GB 的账单。这套先查再建、带闸门周期清理的治理思路后来也被我们顺手复用到了微信自动回复工具的其他存储组件上算是这次事故唯一的意外收获。最后留一个开放问题这类存储的清理策略用时间兜底来规避读者冲突代价是垃圾必须躺满保留期。如果把策略改成引用计数 读者心跳上报理论上可以做到近实时的空间回收但每个读者都要维护心跳进程异常退出还可能泄漏计数。你在维护嵌入式向量库或版本化存储时会更倾向时间兜底的保守策略还是愿意为实时回收承担引用追踪的复杂度欢迎在评论区聊聊各自的取舍。