探索 YugabyteDB 的向量索引架构
Sandeep Lingam
2025 年 6 月 5 日
随着向量搜索成为现代 AI 工作负载的基础设施——从语义搜索和推荐到检索增强生成 (RAG)，数据库必须重新思考其架构，以大规模处理高维向量数据。
在本文中，我们将探讨 YugabyteDB 如何集成由 USearch 驱动的分布式 向量索引 引擎，通过兼容 PostgreSQL 的 SQL 接口原生地提供快速、可扩展且高韧性的向量搜索。
兼容 PostgreSQL、SQL 优先的接口、搜索优化的内部实现
由于完全 兼容 PostgreSQL，YugabyteDB 给用户带来即刻熟悉的使用体验。用户可以通过 pgvector 扩展定义向量列、创建向量索引，并使用标准 SQL 进行查询。
CREATE TABLE docs (id BIGSERIAL PRIMARY KEY, embedding VECTOR(1536));
CREATE INDEX ON docs USING hnsw (embedding vector_l2_ops) WITH (m=16, ef_construction=64);
SELECT * FROM docs ORDER BY embedding <-> '[0.1, 0.3, ...]' LIMIT 10;
在这个熟悉的接口之下，是一个深度优化的分布式向量存储引擎，专为全局分布式数据库的横向扩展性能而构建。
Vector LSM：专为近似最近邻搜索而设计
YugabyteDB 向量支持的一项关键创新是通过 Vector LSM 抽象实现的解耦、可插拔的索引层。这种模块化架构将向量搜索逻辑与数据库引擎的其余部分分离，便于与多种 ANN（近似最近邻）后端集成。
YugabyteDB 的 Vector LSM 工作方式类似于 LSM 树，但专为向量索引而构建：
- 数据写入： 向量首先插入内存缓冲区，并使用基于 HNSW 的库（如 USearch）进行索引。
- 持久化： 当内存索引填满后，会作为不可变的向量块刷新到磁盘。
- 查询： 搜索会扇出到所有内存和磁盘向量索引中。结果通过 MVCC 规则进行过滤以确保一致性，并合并生成最终结果。
这种分层架构高度可并行化，与 YugabyteDB 的分布式分片和复制模型高度契合。
每个 tablet 副本都运行自己的 Vector LSM 实例。这种设计使得每个工作负载可以灵活选择算法级别，并为每个部署的特定需求解锁优化机会。
已支持和未来的后端
- USearch — 轻量级、高性能的 C++ HNSW 引擎
- Hnswlib — 广泛采用的 HNSW 实现，具有经过验证的稳健性
- 未来选项 — FAISS、DiskANN 或自定义 GPU 支持的索引
与主表共置：低延迟的局部感知索引
YugabyteDB 的一个突出设计选择是其共分区的向量索引布局。向量索引与对应的表行存储在同一 tablet 中，确保了紧密的数据局部性和单体向量数据库无法提供的运维优势。
为什么共置很重要
- 快速的本地连接 (join)：嵌入向量及其关联元数据在同一 tablet 中访问，消除了昂贵的跨分片查找需求。
- 高效的谓词下推：SQL 谓词和向量搜索可以联合评估，减少不必要的计算和网络 I/O。
- 简化的事务：索引和表更新位于同一 Raft 日志中，确保原子更新并简化一致性管理。
- 区域感知放置：索引可以与用户或推理服务放置在一起，将地理分布式 AI 用例的跨区域延迟降至最低。
分布式索引实现最大并行度
YugabyteDB 的底层架构为向量查询实现了大规模并行处理。每个 tablet 都包含索引的一个分片，并参与查询执行。
扇出 + 本地过滤 = 可扩展的 Top-K
- 扇出读取：向量查询并行扇出到所有 tablet。
- 本地 top-K 评估：每个 tablet 使用其嵌入式索引在本地计算 top-K 结果。
- 全局聚合：收集并合并部分结果，返回最终的 top-K 匹配。
这种架构最大限度地减少了瓶颈，最大化了吞吐量，并将计算分布到整个集群——非常适合大规模向量工作负载。
天生水平可扩展且自平衡
YugabyteDB 从设计之初就具备水平可扩展性。向量工作负载增长迅速，YugabyteDB 轻松跟上——无论您是跨区域扩展还是仅仅增加计算资源。
如何扩展
- 基于 tablet 的分片：数据（和向量索引）自动分区为 tablet，这是分布和复制的基本单元。
- 弹性重新平衡：添加新节点时，tablet 会自动重新分配，以平衡整个集群的负载和存储。
- 自动 tablet 分裂：如果单个 tablet 因行数、向量等增长过大，它会自动分裂为更小的 tablet 并重新分配，以持续保持性能。
这种弹性确保性能与数据大小和硬件规模呈线性扩展，无需人工干预。
基于 MVCC 和 WAL 恢复的超高韧性索引
与大多数独立向量库不同，YugabyteDB 通过其事务存储引擎和分布式共识协议，为向量搜索带来企业级韧性。
韧性特性
- MVCC 过滤：所有向量写入都带有时间戳，支持多版本一致读取——这对分析和长时间运行的查询至关重要。
- 双向向量 ID 映射：向量 ID 在 RocksDB 中进行版本控制，即使在更新和删除期间也能保持稳定的键查找。
- Raft 一致性恢复：Vector LSM 跟踪持久化状态。崩溃后，基于 WAL 的重放确保一致性，不会丢失数据或搜索完整性。
## 为什么 USearch 为 YugabyteDB 的向量索引提供动力
YugabyteDB 集成 USearch 作为核心向量索引后端，得益于其底层效率、磁盘支持的架构以及对谓词感知搜索的原生支持。这些特性满足了分布式、基于 MVCC 的存储引擎对性能和并发性的要求。
紧凑且快速的设计
USearch 是一个现代化的极简 HNSW 实现，在许多基准测试中比 FAISS 快 10 倍。它采用 SIMD 优化的单头文件 C++ 库，实现了闪电般的搜索速度，非常适合嵌入 Vector LSM 的关键读写路径中。
磁盘支持的索引
与许多内存库不同，USearch 支持内存映射文件访问，使 YugabyteDB 能够高效持久化向量索引，而无需将它们全部加载到 RAM 中。这对于支持包含数十亿向量的大规模部署并降低内存压力至关重要。
谓词下推实现高效过滤
USearch 支持图内过滤，允许 YugabyteDB 将 MVCC 感知谓词（如时间戳或删除过滤器）直接推入 ANN 遍历中。这大幅减少了后处理开销并改善了查询延迟。
用户自定义指标的灵活性
虽然 YugabyteDB 目前专注于 L2 和余弦距离，但 USearch 通过支持自定义距离函数（甚至是编译后的函数）实现了未来的可扩展性。这为未来 YugabyteDB 工作负载中特定领域的指标（如 GIS 的 Haversine 或分子化学的 Tanimoto）铺平了道路。
结论：在云规模上构建 AI 原生应用
通过结合：
- 兼容 PostgreSQL、SQL 优先的用户体验
- 分布式、水平可扩展的 ANN 索引
- 通过 USearch 实现的高性能 HNSW
- Raft 支持的韧性和 MVCC 一致性
- 模块化、可插拔的架构
YugabyteDB 不仅仅是在添加向量支持——它正在重新定义生产级向量数据库的标准。
对于正在构建 检索增强生成 (RAG)、语义搜索、推荐引擎或任何规模与智能相遇的应用的团队来说，搭载 USearch 的 YugabyteDB 提供了无与伦比的性能和灵活性。
了解更多关于 YugabyteDB 向量索引架构的信息，以及如何使用 YugabyteDB 构建 RAG 和 Gen-AI 应用，请参阅这篇 最新文章。
