随着 LLM 和多模态 AI 的兴起，非结构化数据的规模呈指数级增长，这对数据存储、检索和分析提出了更高的要求。LanceDB 是 AI 原生多模态数据湖产品，采用自研的开源数据格式 Lance，以解决传统数据格式在大规模非结构化数据场景中的局限性，已被多家 AI 公司，如 Runway 和 Midjourney 等采纳。
LanceDB 在存储后端方面提供了多种选择，以满足用户在成本、延迟、可扩展性和可靠性方面的不同需求。近期，我们对 LanceDB 在不同存储方案中的性能进行了测试，测试涵盖 JuiceFS、本地 NVMe、AWS EBS、EFS、FSx for Lustre 等方案。结果表明，JuiceFS 在性能上优于 AWS EFS 和 FSx for Lustre，接近 EBS，能够稳定支持 LanceDB 的查询。
LanceDB 概述
LanceDB 是一个专为多模态数据设计的高性能向量数据库，旨在高效管理和搜索大规模的向量数据，特别适合用于 AI/ML 等应用场景，尤其是在多模态数据（如图像与文本嵌入）场景。
![]()
JuiceFS 概述
JuiceFS 是一个为云原生环境设计的分布式 POSIX 文件系统。它采用元数据与数据分离架构，从而实现了对跨多个存储后端的大型数据集的高效管理。JuiceFS 提供了极高的可扩展性，适用于需要多个节点并行访问数据的场景，如大规模的 AI/ML 工作负载。
![]()
02 多模态数据集测试
在本次测试中，我们的主要评估 JuiceFS 与多种存储介质，在性能上的差异。我们所使用的 multimodal_clip_diffusiondb 数据集包含大约 5.8GB 的多模态数据（例如图像和文本嵌入）。测试通过运行 100 条不同的查询请求，比较在不同存储方案下的查询性能。测试代码和数据可以在此链接中找到。
数据表模式如下：
prompt: string
seed: uint32
step: uint16
cfg: float
sampler: string
width: uint16
height: uint16
timestamp: timestamp[s]
image_nsfw: float
prompt_nsfw: float
vector: fixed_size_list<item: float>[512]
child 0, item: float
image: binary
测试步骤如下：
- 将数据集位置更新为测试目标的本地路径（例如，JuiceFS 的挂载路径，或 EFS 或 FSx for Lustre）。
- 启动
multimodal_clip_diffusiondb 作为 HTTP 服务，获取来自服务器的100 个不同提示词，并将其保存为 JSON 文件。
以下是一个 JSON 文件示例：
$ cat close.json
{
"data": [
"close"
],
"event_data": null,
"fn_index": 0,
"session_hash": "ejnrxozcc9l"
}
- 使用脚本并行调用全文搜索 API，执行 100 个不同关键词的查询请求。实际效果等同于运行下方代码中的逻辑。
$ cat run.sh:
#!/bin/bash
for i in data/*.json
do
curl 'http://127.0.0.1:7860/run/predict' -X POST -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0' -H 'Accept: */*' -H 'Accept-Language: en-CA,en-US;q=0.7,en;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'Referer: http://127.0.0.1:7860/' -H 'Content-Type: application/json' -H 'Origin: http://127.0.0.1:7860' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Priority: u=0' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data @$i
done
查询服务背后的访问代码：
import lancedb
db = lancedb.connect('~/datasets/demo')
tbl = db.open_table('diffusiondb')
tbl.search('{query}').limit(9).to_df()
03 测试结果
我们将 LanceDB 数据集复制到多个存储位置进行测试：
- 本地 NVMe 存储：数据存储在本地 PCIe 4.0x4 NVMe SSD 上。
- EBS（弹性块存储）
- JuiceFS
- AWS EFS（Elastic File System）
- AWS FSx for Lustre：1.2TB、3000MB/s 规格。
以下是使用不同存储配置下查询完成所需时间：
![]()
- 本地 NVMe 性能最佳，为 129 秒。
- JuiceFS 性能接近 EBS：JuiceFS 的查询耗时为 177 秒，略高于 EBS 的 176 秒。
- EFS 和 FSx for Lustre 的查询耗时分别为 194 秒和 195 秒，明显高于 JuiceFS 和 EBS。
04 小结
通过本次测试，我们验证了 LanceDB 在结合不同存储方案下的实际查询性能表现。JuiceFS 相比 AWS EFS 和 FSx for Lustre 有更好的性能。
JuiceFS 提供了出色的可扩展性和云原生适应性，满足分布式 AI/ML 应用对高效存储和数据访问的需求。对于大规模数据集、跨多个节点共享数据以及进行高并发查询的应用，JuiceFS + LanceDB 是一个值得探索的解决方案。
