公司新闻

AVB通过Amazon OpenSearch Service加速LINQ搜索 大数据博客

2026-01-27 11:44:45



AVB 利用 Amazon OpenSearch Service 加速 LINQ 搜索

作者:Patick Duffy,2024年5月21日发布于 Amazon OpenSearch Service、Customer Solutions永久链接 评论

主要要点

AVB 将搜索时间从 3 秒减少到 300 毫秒,通过使用 Amazon OpenSearch Service 来处理每日 1450 万条数据更新。解决方案的目标是支持超过 6000 万条产品数据的检索,同时降低运营成本和管理开销。采用分步实施方法并聚焦于数据平整化,以提高搜索性能和响应速度。

AVB Marketing 提供定制的数字解决方案,帮助其成员管理各类产品的资讯。LINQ 是 AVB 自有的产品信息管理系统,使其家电、消费电子和家具零售商成员能够简化产品目录的管理。

对 AVB 成员来说,能够检索、排序和搜索产品数据是销售活动的关键。店内销售依赖于 AVB 的 Hub,这是一款客制化的店内客户关系管理CRM产品,基于 LINQ。最初,Hub 向 LINQ 的 Microsoft SQL Server 数据库发出搜索请求,而该数据库托管于 Amazon Elastic Compute CloudAmazon EC2,搜索耗时平均为 3 秒,这导致采用度降低和负面反馈。

在这篇文章中,我们分享了 AVB 如何通过采用 Amazon OpenSearch Service 将其在 LINQ 中的平均搜索时间从 3 秒降低至 300 毫秒,同时处理每日 1450 万条记录更新。

解决方案概述

为了满足用户需求,LINQ 团队设定了将搜索响应时间降低至 2 秒以内的目标,同时支持检索超过 6000 万条产品数据记录。此外,该团队还希望降低运营成本、减少管理开销,并针对需求进行扩展,尤其是在零售高峰期。在 6 个月内,团队评估了多种架构选项,最终选择了使用 OpenSearch Service、Amazon EventBridge、AWS Lambda、Amazon Simple Queue ServiceAmazon SQS和 AWS Step Functions 的解决方案。

在实施过程中,LINQ 团队与 OpenSearch Service 专家合作,以优化 OpenSearch Service 集群配置以最大化性能和成本效益。根据 OpenSearch Service 开发者指南的 最佳实践 部分,AVB 选择了最佳集群配置,包括 3 个专用集群管理节点和 6 个数据节点,分布在三个 可用区域,同时保持分片大小在 1030 GiB 之间。

LINQ 资料库的更新来自各个来源,包括制造商元数据更新的合作伙伴 API、LINQ 的前端以及 LINQ PowerTools。Lambda 函数定期从变更数据捕获CDC表中读取更新,并将更新的记录发送至 Step Functions 工作流程。该工作流程将记录准备和索引到 OpenSearch Service,以 JSON 格式呈现,允许根据每个客户的基础上进行单独定制。LINQ 团队通过托管在 Amazon EC2 上的搜索 API 暴露对 OpenSearch Service 索引的访问。以下是解决方案的概述图。

AVB 团队利用软件工程师和数据库管理员的专业知识开发了 LINQ 产品数据搜索解决方案。尽管他们在 AWS 方面的经验有限,但他们设定了 6 个月完成项目的时间表。AVB 对这个新工作负载有几个目标,包括支持店内销售地板员工快速根据客户需求查找产品的搜索 API、支持未来增长的可扩展性以及支持 AVB 在理解其数据上的即时分析需求。

印尼节点加速器

AVB 将这一项目分为三个关键阶段:

AVB通过Amazon OpenSearch Service加速LINQ搜索 大数据博客研究与开发概念验证实施与迭代

研究与开发

AVB 的 LINQ 团队的任务是确定最有效的解决方案,以加速 AVB 各类软件产品中的产品搜索。该团队对多种技术和方法进行了彻底的评估,包括仔细检查各种 NoSQL 数据库和缓存机制。在这次探索之后,AVB 选择了 OpenSearch Service 作为概念验证的基础,这是一套开源的分布式搜索与分析套件,具有强大的搜索功能,包括全文搜索和复杂查询支持,并能与其他 AWS 服务无缝集成。

概念验证

在概念验证阶段,AVB 团队专注于验证所选技术堆栈的有效性,特别是在数据加载和同步过程中的重点。这对实现实时数据的一致性至关重要,旨在为地板销售代理提供正确和最新的信息。这一阶段的一个重要部分是创新的数据平整化过程,这对于管理复杂产品数据至关重要。

例如,让我们探讨一个在 SQL Server 数据库中列出的冰箱的用例。该产品与几个相关表相关联:一个是基本详情,比如型号和制造商,另一个是定价,还有一个是能效和容量等特征。原始数据库将这些元素分开存储,但通过关联键相连。下图提供了 SQL Server 数据库的示例数据架构。

为了增强 OpenSearch Service 中的搜索功能,团队将所有这些不同的数据元素合并为一个综合的 JSON 文档。这个文档包括标准制造商详细信息和成员特定的定制,例如特殊定价或附加功能。这样,每个产品就生成了一个经过优化的记录,以便在 OpenSearch Service 中快速高效地搜索。下图显示了 OpenSearch Service 的数据架构。

将关系数据转换为综合的可搜索格式,使 LINQ 团队得以将数据引入 OpenSearch Service。在概念验证中,AVB 通过使用参考 ID 来更新数据,这些 ID 与 SQL 数据库中产品记录的主 ID 或其关联实体直接关联。这种方法允许独立且异步地执行更新。关键是,它支持非先进先出FIFO处理模型,这在面临高规模环境时尤为重要,因为这些环境容易出现数据不一致,如丢失或重播。使用参考 ID 时,系统会在更改发生时获取每个实体的最新数据,以确保处理时始终使用最新数据。这种方法通过防止过时数据超越更新信息来保持数据完整性,从而保持数据库的准确性和及时性。在概念验证中使用的一个重要技术是索引别名,这允许零停机时间重建索引,以添加新字段或修复错误。AVB 利用 Amazon CloudWatch 和 Splunk 建立了强大的性能监控和警报系统,使问题能迅速被识别。

概念验证通过平整关系数据来改善搜索相关性,改进了索引和查询性能。结构调整将搜索响应延迟降低至 300 毫秒,显著低于设定的 2 秒目标。随著这一成功的概念验证展示出架构方法的有效性,AVB 进入了实施与迭代的下一阶段。

实施与迭代

在 AVB 超出了将搜索延迟降低至 2 秒的初始目标后,团队随即采取迭代方法来实施完整解决方案,通过一系列部署将数据从不同业务垂直整合进入 OpenSearch Service。每个业务垂直拥有由不同属性组成的记录,这种增量方法使 AVB 可以引入和检查数据,以确保 OpenSearch Service 中的文档符合预期。每次部署集中于特定的数据类别,并根据之前部署中学到的经验对索引过程进行改进。AVB 也强调了成本优化及解决方案的安全性,并将 OpenSearch Service 部署到私有 VPC 中,以实现严格的访问控制。对新搜索功能的访问是通过他们的 Hub 产品控制的,使用 LINQ 提供的中介服务。AVB 使用强大的 API 密钥和令牌为新搜索产品提供 API 安全。这一系统性的过程意味著最终完成的 LINQ 产品数据搜索目录满足了 AVB 的速度和准确性需求。

结论

在这篇文章中,您了解了 AVB 如何通过采用 OpenSearch Service 将其平均搜索时间从 3 秒降低至 300 毫秒,同时每日处理 1450 万条记录更新,从而使 AVB 的内部团队采用率提高了 500。AVB Marketing 的工程副总裁 Tim Hatfield 反思该项目时表示:“通过与 AWS 的合作,我们不仅超级提升了 Hub 的搜索速度,还为 LINQ 的未来奠定了一个具有成本效益的基础,迅速的搜索转化为降低的运营成本,保持了在零售技术中的竞争优势。”

欲了解 OpenSearch Service 的更多信息,请查看 快速入门 Amazon OpenSearch Service。

作者介绍

Mike Russo 是 AVB Marketing 的软件工程总监,负责 AVB 的电子商务和产品目录解决方案的软件交付。工作之余,Mike 喜欢和家人共度时光以及打篮球。

Patrick Duffy 是 AWS 的高级解决方案架构师,热衷于提高人们对 AWS 工作负载的安全意识。工作之外,他喜欢旅行,试验各种新美食,也许你会在玩 Magic Arena 的时候遇到他。

标签:Amazon OpenSearch

读取评论