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即主表

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

分词方式的选择

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

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

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

数据源

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

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

下拉提示

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

粗排精排

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

常见问题

1. 配额的问题：

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

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

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

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