商城首页欢迎来到中国正版软件门户

您的位置: 首页 > 文章列表 > 硬件相关 > Ring 采用 Amazon RDS 进行 Billow 规模的语义视频搜索,适用于 PostgreSQL 和 pgvector

Ring 采用 Amazon RDS 进行 Billow 规模的语义视频搜索,适用于 PostgreSQL 和 pgvector

  发布于2026-05-28 阅读(0)

扫一扫,手机访问

当你用Ring的语义视频搜索功能,想找某个特定瞬间——比如“我家后院的狗”、“包裹递送”或是“穿蓝色衬衫的人”——你期待的是什么?你希望系统能立刻从几天甚至几周的录像里,精准地找出符合时间、地点和事件描述的片段。这种基于语义的搜索,核心在于理解查询的意图,而不是死板地匹配关键词。为了实现它,Ring采用了一种新方法:在PostgreSQL上,借助pgvector扩展,来存储和检索规模达数十亿的视频数据向量。

今天,我们就来深入聊聊Ring在Amazon RDS for PostgreSQL上构建这套十亿级语义视频搜索系统的幕后故事。这不仅仅是一个技术选型的结果,更是一系列关于架构权衡、成本控制和工程现实的深度思考。我们会对比他们评估过的其他方案,拆解其中的性能与性价比挑战,并分享那些从实战中得来的关键经验。对于任何正在设计大规模AI搜索架构的团队来说,这些 insights 都值得一听。

全球范围内的视频搜索挑战

Ring的使命很清晰:让社区更安全。过去十多年,他们一直在打磨视频技术的清晰度和可靠性,让用户能随时关注对他们最重要的事。为了实现这个目标,Ring每天都需要处理来自全球数百万台设备产生的海量视频数据。

这就对搜索系统提出了极高的要求。这套方案需要覆盖四大洲、9个AWS区域,每天处理数十亿的读取请求,同时对数百万用户保持苛刻的低延迟承诺。传统的、依赖标签或时间戳的元数据搜索,根本无法支撑这种用自然语言进行的模糊查询。Ring需要的,是一种能大规模进行相似性搜索、支持实时数据写入、确保用户数据严格隔离、并且具备跨区域弹性能力的技术架构——尤其是在万圣节这类门铃活动激增的特殊时刻。

十字路口的评估:三种路径的权衡

在敲定最终的生产架构之前,Ring的工程团队进行了一次结构化的评估,核心围绕三个维度展开:成本、查询延迟,以及运维复杂性。

路径一:专用向量数据库

市面上不乏专为向量搜索设计的解决方案。乍看之下,它们很有吸引力:专用的索引、高效的近似最近邻(ANN)算法、原生的嵌入工作流支持。然而,当把这些方案放到Ring的实际业务场景中衡量时,问题就暴露了。

在Ring每天数十亿的查询量和千亿级别的数据规模下,专用向量数据库的成本结构变得难以承受。更重要的是,这些系统往往为混合搜索(关键词+向量)优化,而Ring的工作负载几乎全是密集的向量检索,引入额外的复杂性显得并不划算。据估算,如果采用专用方案,每天新增约20亿个嵌入向量的成本将高得惊人。相比之下,基于Amazon RDS for PostgreSQL和pgvector的方案,不仅避免了高昂的基础设施开销,还大幅降低了持续的索引维护成本,让团队能更专注于功能开发而非运维救火。

路径二:基于S3的ANN原型

团队还尝试过另一种思路:用亚马逊简单存储服务(Amazon S3)作为向量存储,自建一套ANN查询流程。架构很直观——把高维向量存到S3,查询时拉到计算层,在内存里做最近邻搜索。实验证明,这条路走得通,但不够快。从对象存储获取数据产生的往返延迟,始终无法满足Ring“端到端响应低于2秒”的硬性服务等级协议(SLA)。

但这个探索非常有价值,因为它验证了一个关键的架构约束:向量数据必须与查询执行共置。试图通过缓存或预取来抽象这层距离,在如此严格的延迟要求面前是行不通的。

最终的胜出者:为什么是 pgvector + PostgreSQL RDS?

既然专用方案因成本和契合度被排除,S3原型又卡在延迟上,那么整合了pgvector扩展的Amazon RDS for PostgreSQL,就成了一个务实且理由充分的选择。

首先,是团队的“操作熟悉度”。工程师们对PostgreSQL的架构设计、查询调优、复制和可观测性早已驾轻就熟。引入一个全新的专用向量数据库,意味着要面对一套完全陌生的系统:新的故障模式、新的运维手册、新的监控盲区。而使用pgvector,团队可以直接在他们信任的数据库引擎内,利用HNSW或IVFFlat等成熟索引进行向量搜索。

用Ring工程师自己的话说:“我们就是把PostgreSQL当作向量数据库来用。”这绝非将就,而是一种深思熟虑的架构策略。它将关系型工作负载和向量工作负载整合进一个统一、熟知的技术栈,在满足所有生产需求的同时,没有增加任何额外的运维负担。

最终,选择Amazon RDS for PostgreSQL搭配pgvector,让Ring把一项可能耗资巨大的基础设施扩展,转变为了平滑的功能扩展。这个架构成功地将关系数据和向量数据统一管理,无需引入新的故障模式或独立的基础设施,就满足了成本、延迟和可靠性的全部要求。事实证明,有时候最合适的选择,恰恰是最贴合你运维现实的那个。它让系统在无需重构的情况下,就平滑支撑了超过千亿级别的嵌入向量规模。

本文转载于:https://www.php.cn/faq/2463697.html?uid=1242473 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

热门关注