摘要：业务挑战大，自建搜索平台耗时耗力，OpenSearch是帮助您快速上线搜索业务的利器。下面是某电商企业基于OpenSearch搭建电商搜索业务的实践，供大家参考。

上海服务节点已上线，点击了解OpenSearch产品详情

需求分析

某企业搭建电商平台，有一个重要的业务要求是可通过关键字搜索的方式对商品信息中不同属性进行搜索，同时可对搜索出的商品列表进行分类的过滤查看、统计和结果展示，实现的效果很像淘宝的电商平台。PC端的产品原型如下图所示：

移动端的需求主要是三个场景，如下图所示，分别是搜索下拉功能、条件筛选和瀑布流结果展示、历史搜索记录和个性化的搜索推荐。

确定了需要实现的搜索效果，接下来是要分析商品在数据库中的结构，与搜索相关的几张数据库表主要表结构如下图所示。最终实现的搜索功能支持对商品中各属性进行关键字搜索，并对搜索出的商品结果列表中商品所包含的属性或规格进行分类查看。

技术选型：开源系统 VS OpenSearch

做好需求分析，接下我们进行技术选型。我们面临两种选择，采用开源系统自建搜索平台，还是借助成熟搜索云服务搭建搜索业务。

我们先来看看自建搜索平台开发团队配置：自建或开源系统开发、机器维护（2人）、搜索相关性算法（online1人）、索引相关（offline1人）、搜索周边功能（下拉提示、拼音搜索等）。对初创公司产品是业务重点，搜索平台搭建占用大量技术开发和算法资源。再计算机器成本：数据存储和备份，至少1台ECS。另外，未来对海量数据性能也有要求：业务发展数据量1亿，QPS10，平台实时性在1分钟以上，遭遇搜索性能瓶颈。运维成本也是不小的投入：以700G数据空间为例，自建平台使用elasticsearch，6台服务器一个集群，每台8核32G，1年1台6000-7000元，1台服务器1T数据，3个备份，共有4台服务器用于数据存储，一年折后成本在5w以上，数据增量出现延迟，数据量增长运维人员成本增长还未核算。

接下来，我们来评估OpenSearch提供的功能是否能实现项目的需要。整个原型的系统架构如下图所示。通过将商品中心中的商品相关数据同步到OpenSearch服务后，通过OpenSearch提供的搜索API进行商品的搜索。

方案实现

一、创建索引结构

索引结构的创建是为了最终满足业务上对于搜索的要求，在尽量减少对数据库表结构字段修改的前提下，完全可以在遵循OpenSearch索引结构规则前提下，进行索引结构的创建，完全不必担心会有冗余索引数据的产生。最终，我们采用以下方式创建了索引表结构：
1、商品属性表为索引的主表，商品表为辅表的方式，将实际数据库中规格表和属性表的数据均同步到索引的主表商品属性表中；
2、因为最终搜索出的结果均是以商品的形态展现，不会出现单独单品的结果。所以采用在规格表中添加商品的id信息，直接建立规格表与商品表间的关联关系，省去单品表在其中的关联映射；
原型所用的索引结构如下图：

二、配置数据源

重点是将属性表和规格表中的数据均同步到索引的主表中，如下图所示：

三、原型开发

在了解了OpenSearch的搜索URL语法后，开始原型的开发，在其中主要用到了以下几个关键的语句和函数实现了相应的搜索功能：

对索引字段进行全文检索

通过将商品表、属性表、规格表、品牌表等索引表中需要搜索的相关字段添加到索引列表“default”中，见下图：

这样就能通过query:’搜索关键字’，对商品进行搜索操作了。

对搜索结果进行去重

因为我们采用属性表作为索引主表，而一件商品会包含多个不同的属性和规格信息，这样就会出现同一件商品会多次出现在商品的搜索结果中，则需要采用distinct子句对搜索结果进行去重操作，相关代码如下：

这样就能通过query:’搜索关键字’，对商品进行搜索操作了。
第二行设置kvpairs为duniqfield:product_id，是为了从结果中去重后，结果数量也能正常显示。

获取分类列表

为了实现在商品结果中将商品包含的所有分类信息都能获取到，需要使用aggregate子句对property进行聚合操作，以获取搜索结果中不同的属性名，代码如下：

即在搜索结果中同时获取品牌和属性的聚合列表。

按价格进行过滤

业务上还支持按价格区间进行结果的查看，需要采用filter子句，对价格字段进行过滤操作，相关代码如下：

三、原型效果

经过几天的调测，最终实现了商品搜索的原型如下：

搜索结果如下：

搜索结果分类过滤结果

点击了解更多产品详情。