HubSpot 如何将语义搜索扩展至 200 亿个向量

SaaS 软件供应商

HubSpot 网站上的这篇

HubSpot 还表示，该公司选择在内部运行 Qdrant，是因为这样既能与内部的追踪、成本监控、速率限制、扩展和安全工具集成，又能对客户数据保持控制权。该公司称，当前的平台涵盖 200 多个索引、140 多个集群、5 个区域和 2 个环境，峰值写入流量可达每秒 10 万次请求。

在该博文中，Oleg Tereshin 和 Xin Liu 写道，早期的架构是基于 Helm 构建的，而且消费者数量比较少，但随着集群规模的扩大，手动管理变得越来越困难。他们表示，团队转而采用内部的 Kubernetes Operator 框架，因为 Helm 无法进行 API 调用以及根据外部指标自动扩展，也无法处理更复杂的、具有状态感知能力的生命周期任务。

手动运维无法适应业务增长。

—— Oleg Tereshin 和 Xin Liu

这一举措将集群管理转移到了 HubSpot 所称的 Translators 上。该组件每 60 秒会将系统目标状态与实际状态进行一次同步。该文指出，如今这种方法已经实现了集群创建与退役、分片迁移以及复制恢复的自动化，减轻了团队的运维负担。

其他向量搜索系统也面临着同样的压力。Qdrant 自身的

其他从业者也得出了类似的经验教训。在 LinkedIn 上的一篇博文中，Pinecone

召回率至上。

——Pinecone 发表在 LinkedIn 的博文

这些主题与 HubSpot 所强调的平衡分片放置、避免内存偏斜以及利用自动化控制运维工具相契合。该公司表示，某些数据集包含数十亿个数据点，即使只有一个分片失衡，也可能迫使集群在真正需要之前就进行扩展。

HubSpot 还表示，这一转变将集群启动时间从数小时缩短至数分钟，并消除了对备用集群的需求。该公司补充道，如今，同一套对账模型可以同时处理水平扩展、分片再平衡和复制恢复，这使得平台在需求增长时更易于运维。

在向量搜索市场中，这种趋势广泛存在：各团队正越来越多地设法在不牺牲性能的前提下简化检索系统。InfoQ 最近报道了

对于 HubSpot 而言，关键不在于向量技术本身是个新事物，而在于其周边基础设施现在必须像一个成熟的平台服务那样运行。该文明确指出，一旦检索成为多种 AI 产品的核心，数据库本身就只是问题的一部分。更艰巨的任务是围绕它构建足够的自动化机制，确保在需求持续增长的情况下保持系统稳定。