开发者社区> 蓝鲸人> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

OpenSearch 最佳实践

简介: OpenSearch 最佳实践 OpenSearch : 是一款结构化数据搜索托管服务,为移动应用开发者和网站站长提供简单、高效、稳定、低成本(?)和可扩展的搜索解决方案。 低成本:相对“低成本”,当文档数量到了一定量级后,实例租用等费用也不便宜。
+关注继续查看

OpenSearch 最佳实践

OpenSearch : 是一款结构化数据搜索托管服务,为移动应用开发者和网站站长提供简单、高效、稳定、低成本(?)和可扩展的搜索解决方案。

低成本:相对“低成本”,当文档数量到了一定量级后,实例租用等费用也不便宜。。。。大家从自身业务能力及成本综合考虑,到底要不要上opensearch还是另走他法

OpenSearch的产品架构在官方文档处可以查阅

https://help.aliyun.com/document_detail/29108.html?spm=5176.doc29104.6.540.0YyjoL

今天我们不谈架构层面的问题,单从使用者的角度来和大家分享下使用OpenSearch的一些值得注意的点,忝为最佳实践:)

前提

假设你已经接触过opensearch, 有了一定的opensearch的概念及使用基础,那么这篇分享很适合你

版本的选择

opensearch有2个版本应用可创建,大家应根据业务场景进行选择

标准版 做搜索加速,实时,仅支持单表,不支持下拉提示,部分区域不支持标准版。

高级版 多表联合检索,且对实时性要求不是非常高(以我们的使用情形看,阿里云保证的准实时还是有保障的)

主表与附表

当用到高级版opensearch并且需要多表联合检索时,其中一个很重要的概念就是主表与附表,按照官方解释:主表与附表仅支持 N : 1的关系,打个比方,如果主表是商品,附表是商铺,那么多个商品可以属于一个商铺,但是反过来却不行;那么在业务开发中,如何更加快速的确定哪个表是主表呢?我的常用做法是:

假设有表A、B、C,A与B通过字段x_id关联;A与C通过y_id关联;那么基本可以确定A作为主表,验证的方法是,假定A中有一条记录rowA,通过这条记录的x_id能不能找到唯一的一条B记录,通过y_id能不能找到唯一的一条C记录,如果均可以,那么,A即主表

明确了主附表后,我们定义完应用结构后,可以看一看是否设置正确,所有表是否都关联上了。如下图:灰色底的表为主表,白色底的表为附表

1

分词方式的选择

opensearch中另一个很重要的概念就是分词,分词方式决定了你检索时opensearch如何召回文档。目前常用的中文分词为模糊分词与中文基础分词。

模糊分词: 仅支持short_text类型, 支持拼音、前后缀、单数字、单字母方式检索,召回量大,因此性能有损失。如果文档量非常大,建议慎用。

基础分词:适合语义化的场景搜索,比较适合文档的标题,正文检索。

数据源

创建好应用结构后,需要选择数据源,告诉opensearch从哪获取数据进行文档的索引重建。这里有个小tip,如果在创建应用结构时,字段名与数据源中的字段名一致,那么选择好rds或者odps后,opensearch可以自动映射好各个字段。

在创建应用时,建议事先多想想需要哪些字段;否则,后期重新添加字段,修改数据源并重建索引的话,往往耗时较久

下拉提示

opensearch一个很方便的功能就是下拉提示,下拉提示的索引重建是不支持增量数据的,而且后台没有提供明显的入口让用户去重建下拉提示的索引,那么当业务经过一段时间的发展,需要重建下拉提示索引,如何做呢?有个方法就是在如图处,叉掉之前的来源字段,然后重新选择一下这个字段,点击保存,然后你就会发现“生效下拉提示”这个按钮可以点了,点击即可重建下拉提示的索引。(不知道是阿里云遗留的bug还是故意做的不明显。。。)ps: 重建下拉提示索引是不收费的:)

2

粗排精排

这个在官方文档里有比较详细的解释,这里就不赘述了。只说一点,粗排尽量选择筛选性好的字段或者方法,如果召回的文档依旧非常多,那么可以将条件放在filter字句中,提高检索效率;否则容易遇到检索超时的错误。

常见问题

  1. 配额的问题:

以实际业务来说,opensearch在配额使用率达到80%时会报一次警,此后就再无报警;如果运维人员或者开发人员疏忽没有注意到报警,那么在配额耗尽时,opensearch更新文档会直接失败,导致搜索结果不准确。而且这个失败也不会触发报警,除非人为去查看错误日志。。。

因此在业务迅速发展时期,应当定期查看opensearch的配额,购买配额时还需注意,要稍微多购买一点,略微大于主附表的有效数据容量和,否则在重建索引时也有可能遇到空间不足的错误而失败。个人猜测是重建索引时的中间文件或者临时文件会额外占据一些空间,因此配额要稍大一点

  1. 排序不符合业务需求的问题

这个建议多查阅官方文档,熟悉每种排序方法的使用场景,并进行合理的搭配使用。实际使用中,粗排与精排可能会需要较长的时间去不断调整反馈,耐心与科学的排序方法需兼顾,当然了,也可以咨询阿里云的技术专家:)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云S级新游上云最佳实践
本篇通过S级新游案例介绍弹性计算上云的过程。
321 0
阿里云PAI解决方案最佳实践
阿里云PAI解决方案最佳实践 PAI 是阿里云推出的人工智能平台,提供一站式的 机器学习解决方案。本最佳实践利用 PAI 平台结合 阿里云 RDS for MySQL 版、对象存储 OSS 和云数 据库 Redis 版等产品构建一个高效的离线训练+在 线推理的推荐业务系统。
88 0
OSS加速器最佳实践-总述篇
OSS加速器最佳实践(总述篇)本最佳实践提供OSS加速器相关的信息和适合的场景,面向对oss和数据湖相关技术有一定了解的开发者。     大家可以通过这俩篇先做一些了解相关文档:《配置OSS加速器》https://help.aliyun.com/document_detail/190726.html《OSS加速器介绍》https://developer.aliyun.com/article/780
116 0
SLS告警的分组评估最佳实践
监控系统一般包括监控目标(监控实体),监控条件,告警通知,自动修复等系模块,SLS作为云原生观测与分析平台,为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务;SLS也提供了丰富的监控告警功能,可以针对在日志/时序/Trace数据中进行配置异常告警,比如在Nginx日志中500错误过多,主机时序数据中CPU超过90%需要告警,在告警发出时,往往需要对问题发生的原因进行追溯,需要知道哪些实体在出现了异常,比如哪个域名500错误过多,哪台主机CPU过高等。本文将介绍通过SLS告警监控中的分组评估功能找出异常的实体。
158 0
阿里云SLB最佳实践
一、SLB概念 负载均衡(Server Load Balancer)是将访问流量根据转发策略分发到后端多台云服务器(Elastic Compute Service,简称 ECS)的流量分发控制服务。
7169 0
【OSS 最佳实践】OSS 操作权限控制
用户操作 OSS 时是需要根据账号的 AccessKeyId 和 AccessKeySecret (后续简称 AK 和 SK )进行权限验证的,这里的 AK 和 SK 包括有多种类型:主账号的 AK 和 SK 、子账号的 AK 和 SK 以及 STS 生成的临时 AK 、 SK 和 Token 。
7426 0
+关注
7
文章
2
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载