LanceDB Blob 存储演进实战 — 从 27GB 到 4.7GB 的优化之旅 400 首歌的音频存进 LanceDB 后，数据库膨胀到了 27GB，查询延迟飙升到 10 秒以上。 从 blob v1 到 blob v2，从上游 issue 到 fork 修复，这篇文章记录了整个优化过程中 对 LanceDB blob 存储内部原理的理解和工程实践。 Blob v2 设计文档（参考）：Blob v2 Design Doc导言：StaticFlow 与这次优化的起因 StaticFlow 是我的个人项目 —— 一个本地优先（local-first）的 Rust 全栈内容平台。前端用 Yew 编译成 WASM 跑在浏览器里，后端是 Axum，所有数据存储统一使用 LanceDB（一个基于 Lance 列式格式的嵌入式向量数据库）。平台涵盖文章发布、知识管理、评论审核、音乐播放等多个模块。整套服务跑在我本机的 WSL2（Ubuntu 24.04）上，通过 pb-mapper 做公网映射对外提供访问。 音乐模块是最后一个加进来的功能。它的需求很直接：存储歌曲元数据（标题、歌手、专辑、歌词、语义向量等）和音频文件本身（mp3/flac，单文件 3-15MB），通过浏览器播放。 我选择把音频二进制直接存进 LanceDB —— 一个存储引擎解决结构化数据、向量索引和二进制文件，不需要额外的对象存储或文件路径映射。逻辑上很优雅，但存储层面很快就出了问题。 导航：本文共八章，按时间线展开。如果只关心最终方案，可以 ⏭️ 跳到第三章和第四章。第一章：问题 — 音频数据膨胀之痛最初的 Schema 最初的 songs 表 schema 很简单 —— 音频二进制和元数据在同一张表里：// shared/src/music_store.rs — 初始 schema（简化） fn songs_schema() -> Arc<Schema> { Arc::new(Schema::new(vec![ Field::new("id", DataType::Utf8, false), Field::new("title", DataType::Utf8, false), Field::new("artist", DataType::Utf8, false), // ... 元数据字段 ... Field::new("audio_data", DataType::LargeBinary, false), // 音频原始二进制 Field::new("searchable_text", DataType::Utf8, false), // ... 向量字段 ... ])) } 400 首歌，原始音频总量大约 4GB。但 songs.lance 目录膨胀到了 27GB —— 足足 6.7 倍。根因：Copy-on-Write 与大型 Binary 的致命组合 LanceDB 底层的 Lance 格式采用 copy-on-write（写时复制）语义：每次写入/更新都会创建一个新的版本快照。这对元数据更新来说没问题 —— 原子性、可回溯、无锁。但对大型二进制数据来说，它引发了一个恶性循环： Compaction 重写整个 fragment：Lance 的 compaction 把多个小 fragment 合并为大 fragment。audio_data 和元数据在同一个 fragment 里，即使只是合并元数据，也要把几 MB 的音频数据一起搬运。 版本链不断增长：每次 compaction 都产生新版本。旧版本引用的 data file 不会自动释放 —— 这是 MVCC 的代价。 Prune 也不彻底：即使执行 prune 清理旧 manifest，底层 .lance 数据文件可能仍被多个 fragment 交叉引用，无法全部释放。 元数据更新触发全行重写：更新一首歌的标题？整行包括 10MB 的 audio_data 都要写一份新副本。graph TD A["📝 写入/更新操作"] B["📋 创建新版本 Manifest"] C["💾 旧版本 data file 保留"] D["🔄 Compaction 重写 fragment"] E["🎵 audio_data 被完整复制"] F["📈 产生更多旧版本"] A --> B --> C --> D --> E --> F --> C style A fill:#0984E3,stroke:#0770C2,color:#fff,stroke-width:2px style B fill:#00B894,stroke:#009D7E,color:#fff,stroke-width:2px style C fill…