探索 LanceDB 在多种存储方案下的查询效率

随着 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 的查询。

01 项目简介

LanceDB 概述

LanceDB 是一个专为多模态数据设计的高性能向量数据库，旨在高效管理和搜索大规模的向量数据，特别适合用于 AI/ML 等应用场景，尤其是在多模态数据（如图像与文本嵌入）场景。

JuiceFS 概述

JuiceFS 是一个为云原生环境设计的分布式 POSIX 文件系统。它采用元数据与数据分离架构，从而实现了对跨多个存储后端的大型数据集的高效管理。JuiceFS 提供了极高的可扩展性，适用于需要多个节点并行访问数据的场景，如大规模的 AI/ML 工作负载。

02 多模态数据集测试

在本次测试中，我们的主要评估 JuiceFS 与多种存储介质，在性能上的差异。我们所使用的 multimodal_clip_diffusiondb 数据集包含大约 5.8GB 的多模态数据（例如图像和文本嵌入）。测试通过运行 100 条不同的查询请求，比较在不同存储方案下的查询性能。测试代码和数据可以在此链接中找到。

数据表模式如下：

bash 复制代码

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 文件示例：

json 复制代码

$ cat close.json
{
  "data": [
	"close"
  ],
  "event_data": null,
  "fn_index": 0,
  "session_hash": "ejnrxozcc9l"
}

使用脚本并行调用全文搜索 API，执行 100 个不同关键词的查询请求。实际效果等同于运行下方代码中的逻辑。

bash 复制代码

$ 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

查询服务背后的访问代码：

bash 复制代码

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 是一个值得探索的解决方案。