当处理包含数十亿向量 (vector)的数据集或需要高查询吞吐量 (throughput)（QPS）时，向量搜索的扩展在单机上会遇到限制。仅仅依靠垂直扩展（使用更强大的单机）最终会达到物理和成本的边界。解决方案在于水平扩展，即将数据和工作负载分布到机器集群中。分布式向量数据库中常用的架构模式将得到分析，以实现这种伸缩性并维持其性能。
分布式向量搜索的核心难点在于管理多个节点上的索引和查询执行，同时尽量减少延迟并确保一致性。不同的架构以各自的方式平衡这些考量。
协调器/工作器架构
一种常见的模式涉及一个协调器节点（有时称为主节点或网关）和多个工作器节点。
- **协调器节点：**该节点接收来自客户端的请求（包括索引和搜索）。它通常不存储向量 (vector)数据或索引分段本身。其主要职责包括：
- 查询规划：确定哪些工作器节点存有所需查询的相关数据。
- 查询分发：将查询（或子查询）转发到相应的工作器节点。
- 结果聚合：从工作器收集结果并在返回最终响应给客户端之前合并它们。
- 元数据管理：维护有关数据分布（分片）和节点状态的信息。
- 集群管理：处理节点的添加/删除，并可能协调索引更新。
- **工作器节点：**这些节点存储向量索引的分区（分片）和相关的元数据。它们执行实际的计算：
- 本地索引：为其分配的数据分区构建和维护ANN索引。
- 本地搜索：根据协调器的指令，在其本地索引分片上执行搜索操作（例如，ANN图遍历、距离计算）。
- 返回结果：将本地搜索结果发送回协调器。
分布式向量搜索中典型的协调器/工作器架构。客户端仅与协调器交互，协调器协调管理索引分片的多个工作器节点上的工作。
优点：
- 简化的客户端交互：客户端只需知道协调器的地址。
- 集中控制：更易于管理集群状态并实现复杂的查询规划或聚合逻辑。
缺点：
- 协调器瓶颈：在非常高的查询负载下或如果聚合计算成本高昂时，协调器可能成为性能瓶颈。
- 单点故障 (SPOF)：协调器角色需要高可用性机制（例如，备用协调器、主节点选举）以确保系统弹性。
点对点 (P2P) 或去中心化架构
与协调器模型相反，一些架构采用更去中心化的方式，其中节点拥有更大的自主权并直接或半直接地交互。
- **节点角色：**节点可能承担多种角色或作为对等方交互。客户端请求可能会被路由到任意节点，该节点随后与其他相关节点协调以完成请求。
- **分布式协调：**协调逻辑（如查询路由和结果聚合）分布在节点之间。这通常依赖于分布式哈希表（DHT）或流言协议，以便节点互相发现并理解数据放置情况。
- **数据分布：**分片仍然存在，但数据到节点的映射以及查询执行计划可能由参与查询的节点协同确定。
优点：
- 无单点瓶颈：负载分布可以更均匀，可能带来更高的吞吐量 (throughput)。
- 改进的容错能力：单个节点故障不太可能导致整个系统崩溃，尽管它可能影响特定的数据分片。
缺点：
- 复杂度增加：以去中心化方式实现发现、路由和聚合要复杂得多。
- 网络开销：与协调器模型相比，点对点通信可能增加网络流量。
- 一致性挑战：确保所有节点对集群状态和数据分布保持一致的视图可能很困难。
面向服务/微服务架构
现代向量 (vector)数据库常采用受微服务启发而设计的架构，将功能分解为独立、可单独扩展的组件。这并非严格意义上的拓扑结构，如协调器/工作器或P2P，而是一种设计理念。
常见组件可能包括：
- **查询节点/服务：**负责接收客户端查询，执行初步解析/验证，并协调数据节点间的搜索。类似于协调器，但可能更专业化且可独立扩展。
- **数据节点/服务：**存储向量嵌入 (embedding)以及可能的关联元数据。负责管理本地存储和持久化。
- **索引节点/服务：**负责构建和维护ANN索引结构。它们可能从数据节点读取数据，并将构建好的索引提供给查询节点，或执行本地搜索操作。
- **根协调器/元服务：**管理集群元数据、模式信息、节点健康，并可能处理数据平衡或索引重建等协调任务。
一种微服务架构，将查询处理、索引、数据存储和元数据管理分离为不同的服务。
优点：
- 独立扩展：每个组件（查询、索引、存储）都可以根据其具体负载进行扩展。
- 技术灵活性：不同组件可能采用最适合其任务的不同技术。
- 改进的弹性：一种服务类型的故障可能对其他服务影响有限（例如，索引问题可能不会停止对现有数据的查询）。
缺点：
- 操作复杂度：管理多个不同服务、它们之间的交互、网络和部署会增加操作开销。
- 服务间通信延迟：与单体或紧密耦合的设计相比，服务间的网络调用会增加延迟。
分布式架构的考量
无论具体的模式如何，设计一个分布式向量 (vector)数据库都涉及几个重要的考量：
- **一致性：**大多数大型向量数据库倾向于最终一致性，尤其对于索引更新。在高吞吐量 (throughput)写入期间，在分布式ANN索引中实现强一致性通常成本过高。这意味着数据写入和在所有节点上变为可搜索之间可能存在轻微延迟。
- **容错能力：**系统必须能够优雅地处理节点故障。这通常包括数据复制（在后续章节中讨论）以及检测故障节点并重新分配其工作负载或提升副本的机制。
- **数据分区（分片）：**数据如何在节点间分割直接影响负载均衡和查询效率。分片策略将在下一节介绍。
- **查询路由和聚合：**高效地将查询定向到正确的节点并准确合并结果（考量来自不同分片的分数和排名）对性能表现非常重要。
选择合适的架构取决于应用的具体需求，包括规模、查询模式、更新频率、一致性要求和操作能力。许多生产系统通常会混合这些模式的元素，例如，采用协调器模型，但将协调器和工作器角色设计为可扩展的微服务。理解这些基本模式为评估不同的向量数据库解决方案和设计自定义分布式搜索系统提供了依据。
