【向量检索引擎】Lance / LanceDB 对照：格式还是服务

lakehouse/21 已用本机实测说明：同一批 768 维向量，Parquet 随机取 100 行与全扫同量级，Lance take 低三个数量级。该篇把「专用向量引擎」留给本系列。本文回答：Lance / LanceDB 与 Milvus 差在哪一层，以及架构上如何并存。

本文是「向量检索引擎」系列第 16 篇（共 18 篇）。→ 系列目录

版本锚定：湖侧数字引用 lakehouse/21（PyArrow 24 / Lance 7.0.0 本机中位数）；Lance 能力叙述对齐该文所引官方 File Format / Vector Search 文档（A 级）。不在此重跑实验，除非主版本跨越需更新 lakehouse/21。

一、三层不要混叫「向量库」

Lance 首先是 存储格式（可对标 Parquet 的定位差异），不是「另一个 Milvus」。LanceDB 把检索 API 叠在格式上，仍通常假设 数据以数据集文件为中心，而不是 Proxy–Worker–对象段状态机。

二、lakehouse/21 已钉住的结构性事实

环境与口径见原文；此处只复述结论骨架：

原文要点：

1. Lance 用稳定行寻址，使 take(row_ids) 接近点查而非扫滤。
2. 可原生挂 IVF-PQ / HNSW 等 ANN，索引随数据集管理。
3. 自带 dataset versioning；与 Iceberg 主数据湖可并存，用 id + snapshot 对齐。
4. 湖上 ANN 与表格式元数据如何统一 仍是开放问题（Iceberg Puffin 等装不下完整图索引）。

这些数字是 微基准、本地盘、随机向量，不代表生产对象存储吞吐；结构性差异（随机点取）由格式设计决定。

三、与 Milvus 引擎的边界

架构上常见分层（lakehouse/21 已写）：

Iceberg/Parquet：主表与特征
Lance：需随机访问 / 湖上 ANN 的向量子集
Milvus/Qdrant：在线低延迟检索与强过滤
用同一业务 id + snapshot 对齐版本

四、何时可以「不上向量集群」

同时满足时，优先考虑 Lance（± LanceDB）而不是先上 Milvus：

1. 向量主要服务 训练、批推理、离线召回评测，不是高并发在线；
2. 已有湖仓治理，要 同一 snapshot 复现；
3. 访问模式以 按 id 取向量 或中小规模 ANN 为主；
4. 团队运维预算不允许 etcd/对象段/多 Worker。

一旦出现：多租户在线 QPS、强 Session/Strong 可见性、独立建索队列与读写隔离——回到 Milvus/Qdrant（第 15、18 篇）。

五、开放问题

1. Lance 索引与 Iceberg 事务提交如何原子对齐？
2. 对象存储上 Lance 随机 take 的 API 次数与缓存策略（对照第 6 篇寻址代价）？
3. 从 Lance 增量同步到 Milvus 的 exactly-once 边界？

六、小结

Lance 补的是 湖侧随机访问与可选 ANN；Milvus 补的是 在线引擎生命周期。实测口径以 lakehouse/21 为准。下一篇：生产排障。

参考资料

1. lakehouse/21 湖上 AI 与向量（本机 Lance vs Parquet 实测）。
2. Lance / LanceDB 官方 File Format 与 Vector Search（经 lakehouse/21 引用）。
3. 本系列第 1、6 篇；系列 index。

返回 系列目录 ｜ 上一篇：Qdrant 对照 ｜ 下一篇：生产排障