【数据库研究前沿】多模态数据库：文本、向量、图、张量的统一存储

过去十年数据库按数据类型划分出了多条支线：关系数据库管表、文档数据库管 JSON、时序数据库管度量、图数据库管关系、向量数据库管 embedding、对象存储管二进制 blob。一个 LLM 应用如果同时要存原文、embedding、知识图谱、模型 checkpoint、图片，通常要接四到五个系统。这种碎片化导致的问题是众所周知的：跨系统事务缺失、元数据漂移、查询需要应用层做 join、运维成本被放大。

多模态数据库（Multi-modal Database）是这一轮合并浪潮的产物。LanceDB、Chroma、Weaviate、SurrealDB 等系统都把”原生支持多种数据形态”作为核心卖点。但它们的架构起点很不相同：有的从列存文件格式做起（LanceDB），有的从向量库扩展到文档和图（Weaviate），有的从文档数据库吸收图和向量（SurrealDB）。这决定了它们各自的优势区间。

本文上半部分讨论为什么”多模态一体化”是真实需求而不是营销概念、几类主流多模态数据库的架构差异、以及列存格式（Lance、Parquet）对张量数据的支持现状。下半部分给出一份选型矩阵和实操建议，并把多模态存储和仓库已有的 Parquet 、Apache Arrow 、数据湖表格式 文章串起来。

系列上一篇是 GraphRAG：图增强检索的理论与工程 ，讨论了图 + 向量的结合；本文把视角扩展到更广的数据形态。

一、为什么需要多模态一体化

1.1 AI 应用的数据实际形态

一个典型的检索增强生成（RAG）系统的数据构成：

传统做法是每一类接一个后端，用应用层 ID 做 join。这在数据规模小时可以，但随着数据量增长暴露出几个问题：

• 数据一致性：新写入的 chunk 和它的 embedding、图抽取结果之间没有事务边界，出错很难修。
• schema 漂移：chunk 字段增删，对应的向量库、图库表结构都要同步修改，容易遗漏。
• 查询复合性：想写”最近三天、属于社区 C0、向量相似度 top-10 的 chunk”这样的查询，需要在应用层做三次查询再合并，代码复杂且性能差。
• 运维多样：多个独立系统各有部署、监控、备份、升级流程。

这些问题不一定要靠”一库多模”解决（也可以用 Data Lakehouse 架构用一个表格式承载，见 数据湖表格式），但多模态数据库给出了另一条路：在一个引擎里原生表达所有数据类型。

1.2 多模态不是”一库通吃”

必须先说清边界。今天的多模态数据库有两种不同承诺：

• AI 应用级多模态：文本、向量、少量标量、有限图结构。这是 LanceDB、Chroma、Weaviate 的主战场。它们的目标是让 RAG / 特征检索的数据栈变薄。
• 通用多模态：所有数据类型都视为一等公民，包括 OLTP 关系、OLAP 列存、图、时序。SurrealDB、ArangoDB 走这条路。它们的承诺更宏大，但在每个单一维度上通常不如专用系统。

业界尚无成功的”全模态通用数据库”，对 OLTP 高并发 + OLAP 高并发 + 图遍历 + 向量索引同时 top 的单机系统。多模态并不意味着放弃专用系统。

1.3 列存 + 张量作为技术地基

多模态数据库能同时处理这些类型，核心依托是现代列存格式。传统关系数据库的行存布局对变长、嵌套、高维数据天生不友好。Parquet、ORC 等列存格式能压缩相似值、跳过不相关列、做向量化执行；新一代的 Lance、Nimble（Meta 2024）进一步考虑了张量（tensor）和向量的原生表达。

把 embedding、图像特征、音频 MFCC 当作”张量列”存进列式文件，就不需要为每种模态单独做存储引擎——它们只是同一张表的不同列。这是 LanceDB 最核心的技术思路。

二、四个代表系统的架构对比

2.1 LanceDB：基于 Lance 列式格式的嵌入式多模态库

LanceDB 由 Eto AI 团队推出，技术核心是自研的 Lance 列存格式（Rust 实现，提供 Python、JS 绑定）。Lance 相对 Parquet 的几个差异：

• 支持随机访问：Parquet 的行组（row group）必须整块读取，Lance 支持按行 ID 的高效点读。这让 ANN 索引在 Lance 文件上可以直接做”读向量 + 读元数据”的单次 I/O。
• 原生张量类型：Lance 原生支持 FixedSizeList、变长 List、多维张量作为列类型，不用像 Parquet 那样靠 BYTE_ARRAY 包装序列化。
• 分片级别的零拷贝版本化：Lance 支持 Git-style 版本树，每个 commit 只追加新分片，回滚不需要复制数据。这是为”数据集像代码一样版本管理”的 ML 工作流设计的。
• 内置向量索引：Lance 内置 IVF-PQ 和 HNSW，索引作为 Lance 文件的元数据管理。

LanceDB 的定位是嵌入式（embedded）：无服务器进程，类似 SQLite 或 DuckDB 的使用方式。适合场景：

• 中小规模 RAG（<1 亿向量）；
• 笔记本 / 单机 notebook 开发；
• 需要和 Pandas / Polars 数据管线无缝衔接。

不适合：

• 多客户端高并发写入；
• 跨机器分布式扩展。

典型用法：

import lancedb

db = lancedb.connect("./data.lance")
table = db.create_table("docs", data=[
    {"id": 1, "text": "hello", "vector": [0.1, 0.2, 0.3, 0.4]},
    {"id": 2, "text": "world", "vector": [0.5, 0.6, 0.7, 0.8]},
])
table.create_index(metric="cosine", num_partitions=64, num_sub_vectors=16)
res = table.search([0.1, 0.2, 0.3, 0.4]).where("id > 0").limit(5).to_list()

2.2 Chroma：开发者友好的嵌入式向量库

Chroma 定位比 LanceDB 更窄：它本质上是一个向量库 + 元数据过滤，把”最小 RAG 栈”做到开发体验极佳。底层存储用 DuckDB / SQLite + 自研向量索引（HNSW）。

Chroma 的取舍：

• 优点：API 极简、Python 开箱即用、本地持久化默认开启。
• 限制：不原生支持图、不支持复杂 JOIN、不支持张量作为一等列。它的”多模态”能力主要靠元数据字段和应用层组织。

在”我只想把 embedding 快速存起来、支持简单过滤”场景下 Chroma 是合理起点。但数据规模过千万或需要图结构时，需要换后端。

2.3 Weaviate：Schema + 向量 + 图的混合

Weaviate（Go 实现，SemiTechnologies 出品）是较早把 Schema、向量检索、图关联都内置的系统。核心概念：

• Class：类似关系表，每个 Class 有 Schema 和可选的 vectorizer。
• Reference：Class 之间可以定义引用，形成类似图的结构，支持一跳扩展。
• Modules：向量化、rerank、QA 等功能作为可插拔模块（OpenAI、Cohere、HuggingFace 等）。

Weaviate 的查询语言是 GraphQL，语义上既能做 ANN 搜索也能做关系展开：

{
  Get {
    Document(
      nearVector: { vector: [0.1, 0.2, ...], distance: 0.3 }
      where: { path: ["year"], operator: Equal, valueInt: 2024 }
      limit: 10
    ) {
      title
      year
      _additional { distance }
      author { ... on Author { name affiliation } }
    }
  }
}

Weaviate 的优势在”中等规模 + 业务 schema 固定”的生产场景；限制在于：图能力仅限于 Reference 扩展，没有完整的图遍历算法；水平扩展在 v1.x 需要手工规划分片。

2.4 SurrealDB：文档 + 图 + 向量的全栈尝试

SurrealDB（Rust 实现）把多模态做得最激进：关系表、文档、图、向量、时序都以一等公民形式存在于单一查询语言 SurrealQL 中。

DEFINE TABLE doc SCHEMAFULL;
DEFINE FIELD text ON doc TYPE string;
DEFINE FIELD embedding ON doc TYPE array<float>;
DEFINE INDEX doc_vec ON doc FIELDS embedding MTREE DIMENSION 768;

-- 图关系
RELATE alice->likes->bob;

-- 混合查询
SELECT *, vector::distance::euclidean(embedding, $q) AS d
FROM doc
WHERE year = 2024 AND ->likes->person[?name = "Bob"]
ORDER BY d LIMIT 10;

SurrealDB 的野心很大，但也相应面临质疑：全栈意味着没有任何模态做到业界顶尖。ANN 索引能力对比 Milvus、图遍历对比 Neo4j、关系能力对比 PG 都有明显差距。目前更合适的定位是”中小型一体化应用”的简化方案。

2.5 其他值得了解的系统

• Milvus：虽被归类为向量库，但 2.x 已经支持标量过滤、动态 schema、部分 JSON 查询，在 “AI 为主、其他模态为辅” 的场景下常是默认选项。参考 向量索引深度对比 和 混合过滤检索 。
• DuckDB + VSS：DuckDB 通过扩展支持向量检索（vss extension）、全文索引、JSON，在”嵌入式分析 + 少量 AI 工作负载”场景里越来越常见。
• Neo4j 5.x：已加入原生向量索引，让图 + 向量在同一引擎里成为现实。
• TileDB：不那么广为人知，但把”多维稀疏数组 / 张量”作为核心数据模型，是科研、基因组学等领域的另一种多模态选择。

2.6 架构对比速览

✅ 原生完整；⚠️ 部分支持；❌ 无。

2.5 Qdrant、Chroma 与更广的谱系

本节聚焦四个架构差异最明显的系统，但多模态数据库的谱系远不止于此：

• Qdrant（Rust）：专攻向量 + 标量，过滤策略做得特别扎实（见上一篇 混合过滤检索 ）。不强调”多模态”，但 payload 可以非常丰富，单机性能在开源阵营中领先。
• Chroma（Python / Rust 重写中）：极简设计，embedding + metadata 两栏，开箱即用。适合 RAG 原型和教学场景，生产规模下会遇到性能边界。
• Vespa（Java + C++）：Yahoo 系，搜索引擎出身，结构化 + 向量 + 全文在同一查询引擎里组合。学习曲线陡，但在推荐/搜索等复杂打分场景下表达力无人能敌。
• Marqo / Jina：“embedding as a service + storage”，把模型推理和存储打包。开发效率高，但绑定生态会带来迁移成本。
• PostgreSQL + pgvector + 其他扩展（pg_embedding、pgvectorscale、Apache AGE）：保持关系库的所有事务、SQL、生态优势，逐项叠加多模态能力。对已有 PG 基础设施的团队，这是最务实的路径。

“多模态数据库”这个概念本身正在被稀释——传统关系库、搜索引擎、KV 存储都在向多模态扩展。五年后可能不再需要一个独立的”多模态数据库”品类，因为每个成熟系统都会是某种意义上的多模态。

3.1 Parquet 的张量表达

Parquet 自身没有张量类型。常见做法是把张量展平成 LIST<FLOAT> 或 FIXED_LEN_BYTE_ARRAY。这样做的问题：

• 读回来要应用层 reshape；
• 多维边界信息不在 schema 里，跨工具时易丢；
• 编码层（Dictionary、RLE）对连续浮点张量的压缩效率不如专用方案。

实践中常用的 workaround：

• 在 schema 里用 FixedSizeList<Float32, N> 表达定长向量（Arrow 中是 FixedSizeList 类型）；
• 把 shape 信息放进列的元数据（Metadata）字段；
• 大张量（图像、特征图）直接存路径，二进制放对象存储。

这些都能工作，但不优雅。参考仓库的 Parquet 深入 、Apache Arrow 两篇文章里对 list/嵌套类型的详细讨论。

3.2 Lance：为 AI 设计的列存

Lance（lancedb 的底层格式）对张量做了原生支持：

• FixedShapeTensor 类型：定义固定形状（如 [3, 224, 224]）的浮点张量；
• VariableShapeTensor：变形状张量，附带 shape 数组；
• 编码层针对浮点序列做量化（可选 PQ / SQ8）；
• 按行 ID 的随机读：一次请求就能从巨大文件里拿出单个样本及其所有字段。

Lance 格式规范见 github.com/lancedb/lance。Arrow 社区本身也在推进 FixedShapeTensor canonical extension，Lance 是早期采用者之一。

3.3 Nimble：Meta 的下一代列存

Nimble（Meta 2024 年在 VLDB 发表，原名 Alpha）是 Meta 内部替换 ORC 的新列存格式。关键设计点：

• 单一文件格式代替 Parquet / ORC 的多家分立状态；
• 统一的编码框架，可插拔（基本编码、字典、RLE、FFL、ANS）；
• 一等支持嵌套、张量、稀疏编码；
• 面向列向量化执行和 GPU 读取优化。

Nimble 是否会在开源社区成为主流尚待观察，但”列存格式需要为 AI 多模态做一次大升级”是业界共识。

3.4 Arrow 的角色

Apache Arrow 是跨系统内存格式。多模态数据库底层几乎无一例外用 Arrow 作为：

• 跨语言数据交换（Python / Rust / Go 之间零拷贝传递批次）；
• 与 DuckDB / Polars / Pandas 无缝衔接；
• 作为新列存格式的”基线”——Lance、Nimble 的内存表示都和 Arrow 一致。

对 Arrow 本身的详细讨论见 Apache Arrow 内存格式 。一个常被忽视的事实：多模态数据库的真正互通不是查询语言层面，而是 Arrow 批次层面。你可以把 LanceDB 读出的 Arrow 批次直接交给 DuckDB 做 SQL 聚合、再传给 Polars 做特征工程，全程零拷贝。

四、选型矩阵

根据数据规模、模态组合、部署约束，给一个决策矩阵：

关键判断点：

1. 数据规模超过单机能力？ 是 → 分布式专用系统（Milvus、Neo4j Enterprise、NebulaGraph）；否 → 嵌入式方案优先。
2. 是否需要 ACID 事务？ 多数多模态库在向量索引层做不到严格 ACID。若必需强事务，选 PG + 扩展。
3. 未来演进方向：要不要上 OLAP？要不要接 GPU？这些会影响格式选择——Lance 在 GPU 读取友好度上优于 Parquet。

4.1 多模态 + Lakehouse 的组合

一种经常被低估的架构是：用 Data Lakehouse（Iceberg / Delta / Hudi） + 多模态库做分层：

热数据 & 在线查询 → LanceDB / Milvus / Weaviate
    ↑ 批量同步
冷数据 / 历史版本 → Iceberg / Delta (Parquet)

Lakehouse 负责长期存储、版本化、大规模批处理；多模态数据库负责在线向量检索、实时读写。两者通过 Arrow 批次交换。这种架构让成本和性能都不至于失控，是很多生产系统的真实形态。Lakehouse 本身见 数据湖表格式 。

五、特征平台与多模态数据库的关系

在 AI 工程语境下，Feature Store（特征平台）与多模态数据库的边界经常模糊。两者都处理”向量 + 标量 + 时间戳”，但设计目标完全不同。

5.1 Feature Store 的核心问题

机器学习工程里的特征平台（如 Feast、Tecton、Hopsworks）要解决的问题是：

• 训练/服务一致性：训练时从离线批量计算的特征表读，线上推理时从毫秒级 KV 读，但二者的特征定义必须严格一致（point-in-time correctness）。
• 特征版本化：模型 A 依赖特征版本 v1，模型 B 依赖 v2，两者可能同时在线。
• 特征计算 DAG：许多特征由上游特征派生，要管理依赖和回填（backfill）。

多模态数据库原则上能存向量，但通常没有点时间正确性（point-in-time joins）、训练数据集生成、离线/线上一致性保证等 feature store 的关键能力。它们解决的是在线检索问题，不是特征工程问题。

5.2 组合使用

比较常见的生产形态：

Feature Store（Feast/Tecton/Hopsworks） → 训练/评估
           ↓ 特征向量化/embedding
Multi-modal DB（LanceDB/Milvus）      → 在线检索

Feature Store 负责特征的一致性与血缘；多模态库负责在线的 ANN 检索与多模态组合。两者通过离线批量同步或实时 CDC 衔接。

六、时序、事件日志与多模态库

很多 AI 应用都有”事件流”维度：用户行为日志、模型推理日志、系统 telemetry。这类数据的核心需求是高吞吐写入 + 时间范围扫描，正是 ClickHouse / InfluxDB / TimescaleDB 的主场。

多模态数据库在”事件流 + 向量”场景下有两种态度：

• 集成为原生类型：SurrealDB 将时序列表作为文档的一等字段；ClickHouse 通过向量扩展能做”最近 1 小时行为的相似检索”。
• 保持分离：多模态库只管向量 + 标量，事件流留在 ClickHouse 等专用系统。

在”事件量每天数百亿”的场景下，通常选后者。ClickHouse 有成熟的 MergeTree 分区、压缩、sampling；在它基础上加 vector 扩展比反向把向量库改造成高吞吐事件存储更务实。

七、Arrow Flight 与跨系统互通

多模态数据库能”组合”的关键是跨系统的数据交换协议。Apache Arrow Flight（基于 gRPC）正在成为事实标准：

• 零拷贝列式数据传输，带宽接近网络极限；
• DuckDB、Polars、LanceDB、Dremio、BigQuery、Snowflake（部分）都支持；
• Arrow Flight SQL 作为跨引擎 SQL 查询协议也在演进。

一个现代的数据管线可以是：

LanceDB 取向量 → Arrow batch → DuckDB 做 SQL 聚合
                       → Polars 做特征工程
                       → 直接喂给 PyTorch DataLoader

整条链路零拷贝、零序列化。这比”先导出 CSV / Parquet 再重新加载”快一到两个数量级。对多模态数据库选型的一个实用建议是：优先选 Arrow-native 的系统。这让未来更容易换单点组件、也更容易接入 Lakehouse 生态。

八、一个真实演进案例

以一个中等规模（团队 10 人、数据量月增百万 chunk）的 RAG 产品为例，架构演进通常是：

阶段 1：单体 pgvector（0–3 个月）。所有东西塞进 PG，embedding 作为 vector 列，业务表和向量同表。优点：快速启动、无额外依赖。问题出现在数据量过 500 万行后——HNSW 建索引 2 小时、磁盘增长快、UPDATE embedding 触发索引重建。

阶段 2：pgvector + 专用向量库（3–9 个月）。把 embedding 搬到 Milvus / LanceDB，PG 继续管业务 + 元数据。问题：两边要同步（双写或 CDC），数据一致性需要应用层处理；跨系统 JOIN 变成 N+1 查询。

阶段 3：加入图（9 个月 +）。业务侧希望多跳问答，引入 Neo4j 跑 GraphRAG。现在同一个 chunk 的元数据存在于三个系统。团队开始讨论”是否用 SurrealDB 或 Weaviate 合并两个”。

阶段 4：落到 Lakehouse（1 年 +）。历史 chunk + embedding + 图数据全部落到 Iceberg，热数据保留在 Milvus + Neo4j，后台按日同步。批量训练、大数据分析都走 Lakehouse 路径。

这个演进在不少团队重复过。关键教训：

• 第一阶段不要过度设计；pgvector 或 Chroma 足够。
• 拆系统的时机是被迫的——当某个指标（索引构建时间、查询延迟、成本）越过阈值时才拆。
• 数据模型不要提前适配未来系统；做好当下的模型，未来迁移时再调。

多模态数据库”一库通吃”是否能终结这个演进循环，目前还没有确定答案。但可以肯定：碎片化比过早统一更容易应对。

九、几个容易踩的坑

9.1 把”多模态”当成银弹

不是所有 AI 应用都需要多模态数据库。如果你只存 embedding + 一两个标量，pgvector 或 Chroma 就够。引入 SurrealDB 这种全栈系统反而带来运维负担和性能天花板。先问”现有系统哪个接不动？“再选。

9.2 向量索引的代价被低估

多模态数据库卖点是”一库通吃”，但向量索引本身是资源大户。在同一节点上跑 HNSW + 图遍历 + 关系查询，容易互相抢内存和 CPU。生产部署时要有明确的资源隔离或分库策略。

9.3 张量列不等于原生张量语义

多数系统所谓”支持张量”只是能存 LIST<FLOAT>，但查询层没有 reshape、slice、broadcast 等张量操作。真正的张量数据库（TileDB）有专用 API；用通用多模态库做特征存储，还是要靠应用层处理张量逻辑。

9.4 数据一致性

跨模态写入（chunk + vector + graph 三份）在多数多模态库里还不是强事务。LanceDB 有版本化但不是 MVCC；Weaviate 默认异步索引构建；SurrealDB 的多表事务在向量索引路径上有限制。设计时要把”部分写入成功”作为必须考虑的错误场景。

9.5 数据迁移成本

一旦选定某个多模态库，迁移成本比想象高：向量索引需要重建（可能几小时到几天）、Schema 可能不能直接映射、图模型难以互译。选型时要评估未来 2–3 年的数据增长和可能的架构切换代价。

十、小结与展望

到 2024 年底，多模态数据库的格局还远未收敛。几条可观测的趋势：

• AI-native 格式扩张：Lance、Nimble 等新列存格式推动”张量 / 向量作为一等列”成为标配，Parquet 生态也在追赶（Arrow FixedShapeTensor canonical extension）。
• 向量+图融合：Neo4j 加向量、图数据库加向量正在常态化。GraphRAG 是最直接的驱动力。
• 嵌入式优先：LanceDB、DuckDB+VSS、KuzuDB 等嵌入式多模态引擎的普及度在快速上升，AI 应用的”本地优先”部署模式重新流行。
• Lakehouse 扩展到 AI：Iceberg、Delta 社区在推进对向量、张量的原生支持，未来的”AI Lakehouse” 可能成为新的分层架构。

没有银弹。选型的正确方式仍是：先澄清数据和查询模式，再匹配工具，而不是反过来。系列下一篇 HTAP：混合事务分析处理的现实 会从另一个角度讨论”不同负载在同一系统共存”的话题，和多模态问题在架构哲学上遥相呼应。

参考文献

1. LanceDB, “Lance: modern columnar data format for ML”, https://github.com/lancedb/lance
2. Weaviate Documentation, https://weaviate.io/developers/weaviate
3. Chroma Documentation, https://docs.trychroma.com/
4. SurrealDB Documentation, https://surrealdb.com/docs
5. TileDB, “The Universal Storage Engine for Arrays”, https://tiledb.com/
6. Meta Engineering. “Nimble: A Next-Generation Columnar File Format.” VLDB, 2024. https://github.com/facebookincubator/nimble
7. Apache Arrow, “Canonical Extension Types: FixedShapeTensor”, https://arrow.apache.org/docs/format/CanonicalExtensions.html
8. Apache Parquet Format, https://parquet.apache.org/docs/file-format/
9. Apache Iceberg, https://iceberg.apache.org/
10. Delta Lake, https://delta.io/
11. Feng, X., et al. “KuzuDB: An Embeddable Graph Database Management System for Query Composability.” CIDR, 2023.
12. DuckDB VSS Extension, https://duckdb.org/community_extensions/extensions/vss.html
13. Neo4j Vector Search, https://neo4j.com/docs/cypher-manual/current/indexes/semantic-indexes/vector-indexes/
14. Milvus Documentation, https://milvus.io/docs
15. pgvector, https://github.com/pgvector/pgvector

上一篇：GraphRAG：图增强检索的理论与工程 下一篇：HTAP：混合事务分析处理的现实