🚀 “Vector Sharding”：如何组织一个没有字母表的图书馆 📚🧩

Source: Dev.to

欢迎回到我们的 AI at Scale 系列！🚀
在上一篇文章中我们探讨了 Semantic Caching——一种通过记住已经向 AI 提问的内容来省钱省时的“聪明”方式。随着你的应用从几千用户增长到数百万用户，你会碰到一个巨大的障碍：内存限制。

向量数据库的挑战

想象一下，你是全球最先进图书馆的馆长。图书不再按标题排列，而是按“氛围”（向量）排列。如果有人想找一本关于 “孤独机器人在太空中” 的书，你必须在整个图书馆中搜索最相近的匹配。

• 内存：无法在单台服务器的 RAM 中容纳 10 亿个“氛围”的索引。
• 速度：为每个用户请求在十亿条记录中搜索非常慢——即使是电脑也如此。

分片：把图书馆拆开

当一台机器太小而无法胜任时，我们 分片（sharding）。

Sharding 是将一个庞大的数据库拆分为更小、易于管理的块（称为 shards）的过程。每个 shard 运行在不同的服务器上。

传统分片 vs. 向量分片

两种主要方法

1. 均匀分布

1. 将 10 亿向量 分散 到 10 台服务器上（≈每台 1 亿）。
2. 聚合器 同时向所有 10 台服务器发送查询。
3. 合并：每台服务器返回其前 5 条匹配（共 50 条），聚合器挑选出最好的结果。

2. 基于元数据的分片

如果你的数据拥有明确的类别（例如 “语言” 或 “产品类别”），可以基于这些元数据标签进行分片。

• 好处：如果用户只在 “医学研究” 中搜索，你只查询 “医学” 分片，其他如 “体育” 与 “烹饪” 分片则保持空闲，供其他流量使用。

HNSW 与内存约束

大多数现代向量数据库使用 HNSW（Hierarchical Navigable Small World），这是一张针对高维数据的“六度分隔”地图。

• RAM 要求：HNSW 必须驻留在 RAM 中才能保持高速。
• 问题：在只有 128 GB RAM 的服务器上放置 500 GB 的索引会导致交换到磁盘，使原本 50 ms 的搜索耗时变为数秒。

分片 能让每个 HNSW 索引保持足够小，从而完整驻留在高速内存中。

权衡与工程考量

• 复制：如果某个 shard 服务器宕机，你会失去该部分内存。为实现弹性，需要为每个 shard 配置副本。
• 再平衡：随着数据增长，部分 shard 会变得“更热”。在系统在线的情况下将数百万向量在服务器之间迁移，是一项巨大的工程挑战。

为什么向量分片重要

向量分片是 酷炫 AI 演示 与 顶级 AI 平台 之间的区别。它迫使高维数学在硬件的物理限制内运行。

下一篇 “AI at Scale” 系列：LLM API 的速率限制 — 如何防止你的 API 密钥在高并发下“熔化”。