有赞搜索系统的技术内幕

标签: 程序员 工具 后端 | 发表时间:2018-09-18 15:37 | 作者:有赞技术
出处:https://segmentfault.com/blogs

上文说到有赞搜索系统的架构演进,为了支撑不断演进的技术架构,除了 Elasticsearch 的维护优化之外,我们也开发了上层的中间件来应对不断提高的稳定性和性能要求。

Elasticsearch 的检索执行效率可以表示为:
O(num_of_files logN)*

其中 num_of_files 表示索引文件段的个数,N 表示需要遍历的数据量,从这里我们可以总结出提升查询性能可以考虑的两点:

  1. 减少遍历的索引文件数量
  2. 减少遍历的索引文档总数

从 Elasticsearch 自身来说,减少索引文件数量方面可以参考几点:

  1. 通过 optimize 接口强制合并段
  2. 增大 index buffer/refresh_interval,减少小段生成,控制相同数量的文档生成的新段个数

不论是强制合并或者 index buffer/refresh_interval,都有其应用场景的限制,比如调整 index buffer / refresh_interval 会相应的延长数据可见时间;optimize 对冷数据集比较适用,如果数据在不断变化过程中,除了新段的生成,老数据可能因为旧段过大而得不到物理删除,反而造成较大的负担。

而减少文档总数方面,也可以做相应的优化:

  1. 减少文档更新
  2. 指定 _routing 来路由查询到指定的 shard
  3. 通过 rollover 接口进行冷热隔离

这里尤其需要注意的是减少文档更新,由于 LSM 追加写的数据组织方式,更新数据其实是新增数据+标记老数据为删除状态的组合,真实参与计算的数据量是有效数据和标记删除的数据量之和,减少文档更新次数除了减少标记删除数据之外,还可以降低段 merge 以及索引刷新的消耗。

考虑到实际的业务场景,如果将海量数据存储于单个索引,由于 shard 个数不可变,一方面会使得索引分配大量的 shard,数据量持续增长会逐渐拖慢索引访问性能,另一方面想要通过扩展 shard 提高读写性能需要重建海量数据,成本相当高昂。

索引拆分

为了增强索引的横向扩容能力,我们在中间件层面进行了索引拆分,参考实际的业务场景将大索引拆分为若干个小索引。
在索引拆分前,首先需要检查索引对应业务是否满足拆分的三个必要条件:

  1. 读写操作必定会带入固定条件
  2. 读写操作维度唯一
  3. 用户不关心全局的搜索结果

比较典型的比如店铺内商品搜索,不论买卖家都只关心固定店铺内的商品检索结果,没有跨店铺检索需求,后台店铺与商品也有固定的映射关系,这样就可以在中间件层面对读写请求进行解析,并路由到对应的子索引中,减少遍历的文档总量,可以在性能上获得明显的提升。

图片描述

相对 Elasticsearch 自带的 _routing,这个方案具备更加灵活的控制粒度,比如可以配置白名单,将部分店铺数据路由到其他不同 SLA 级别的索引或集群,当然可以配合 _routing 以获得更好的表现。

索引拆分首先会带来全局索引文件数据上升的问题,不过因为没有全局搜索需求,所以不会带来实质的影响;其次比较需要注意的是数据倾斜问题,在拆分前需要先通过离线计算模拟索引拆分效果,如果发现数据倾斜严重,就可以考虑将子索引数据进行重平衡。

图片描述

如图所示,数据重平衡在原有的拆分基础上加入一个逻辑拆分步骤:

  1. 数据首先拆分为 5 个逻辑索引
  2. 设定重平衡因子,假设为 N
  3. 根据重平衡因子将逻辑索引数据顺序哈希到N个连续的物理索引中

图片描述

如图,按平衡因子3重平衡之后文档数据量的最大差值从 510 降为了 160,单索引占全局数据量比例从之前的 53% 降低为 26%,能够起到不错的数据平衡效果。

冷热隔离

在查询维度不唯一的场景下,索引拆分就不适用了,为了解决此类场景下的性能问题,可以考虑对索引进行冷热隔离。
比如日志/订单类型的数据,具备比较明显的时间特征,大量的操作都集中在近期的一段时间内,这时就可以考虑依据时间字段对其拆分为冷热索引。

图片描述

Elasticsearch 自带有 rollover 接口供索引进行自动轮转,通过索引存活时间和保存的文档数量作为轮转条件,满足其中之一即可创建一个新索引并将其作为当前的活跃索引。
在实际应用过程中,rollover 接口需要用户感知活跃索引的变更,且自行计算查询需要访问的索引范围,为了对用户屏蔽底层这些复杂操作的细节,我们在中间件封装了索引的冷热隔离特性,从用户视角只须访问固定索引并带入固定字段即可。

图片描述

首先配置路由表,根据不同的时间跨度划定不同的路由规则,比如业务初期数据增量并不大,可以用50的时间跨度创建子索引,后期业务增量变大后逐渐缩短时间跨度至 10 来创建子索引。
通过查询条件的起止时间点分别从路由表中计算对应的子索引偏移量,得到起止范围,以上图为例,连续的子索引范围为 index2~index14,也就是该条件将命中此区间内的全部子索引,写操作也类似,区别在于写数据只会落到一个子索引,一般是当前的活跃索引。
这样冷热隔离的方式拆分可以兼容多维度的查询需求,比如订单的买卖家查询维度,而且拆分规则比较灵活,可以动态调整,另外删除数据只需要删除整个过期索引,而不必通过 delete_by_query 的方式缓慢删除索引数据。
除此之外,为了更好的配合用户使用,我们还对此开发了索引的自动轮转/定时清理等辅助功能。

HA

随着搜索系统的广泛使用,用户对系统的稳定性也提出了更高的要求,比如在机房发生断电等故障情况下,依然能够保证服务可用,这就需要我们能够将数据进行跨机房复制同步。
首先考虑的方案是跨机房组建 Elasticsearch 集群,这样实现非常简单,但是问题是机房的网络交互是走专线的,在集群宕机恢复数据过程中会有很大的带宽消耗,可能引起机房间的网络拥堵,因此这个方案并不可行。
Elasticsearch 本身也在开发 Changes API 特性,可以用于跨集群的数据同步,但可惜的是该特性仍然在开发中,在参考了主流的数据同步方法后,我们在中间件层开发了一套异步数据复制系统。

图片描述

在确认索引开启多机房复制后,首先在 proxy 侧启动增量同步,发送同步消息给 mq 作为同步程序 clones 的增量数据源,然后通过 reindex 功能从主索引全量复制数据到从索引。

在跨机房同步过程中,数据容易因为 MQ、proxy 异步发送等影响而乱序,Elasticsearch 可以通过乐观锁来保证数据变更的一致性,避免乱序的影响,前提是 version 能够一直保持在索引中。
但是在物理删除模式下,由于数据被物理清理,无法继续保持版本号的延续,这就有可能导致跨机房数据同步的脏写。

图片描述

为了避免乐观锁失效,我们的解决方法是软删除的方式:

  1. delete 操作在中间件转换为 index 操作,文档内容仅包含一个特殊字段,不会命中正常的搜索条件,也就是正常情况下无法搜索得到该文档,达到实际的删除效果
  2. 在中间件将 create/get/update/delete 等操作转换为 script 请求,保持原有语义不变
  3. 通过软删除文档中特殊字段记录的时间戳定时清理数据(可选)

为了能够感知到主从索引间的数据一致性和同步延迟,还有一套辅助的数据对账系统实时运行,可以用于主从索引数据的校验、修复并通过 MQ 消费延时计算主从数据的延迟。

小结

到这里有赞搜索系统的大致框架已经介绍完毕,因为篇幅的原因还有很多细节的功能设计并没有完整表述,也欢迎有兴趣的同学联系我们一起探讨,有表述错误的地方也欢迎大家联系我们纠正。
关于 Elasticsearch 方面本次的两篇文章都没有太多涉及,后续待我们整理完善之后会作为一个扩展阅读奉送给大家。

图片描述

相关 [搜索 系统 技术] 推荐:

有赞搜索系统的技术内幕

- - SegmentFault 最新的文章
上文说到有赞搜索系统的架构演进,为了支撑不断演进的技术架构,除了 Elasticsearch 的维护优化之外,我们也开发了上层的中间件来应对不断提高的稳定性和性能要求. Elasticsearch 的检索执行效率可以表示为:. 其中 num_of_files 表示索引文件段的个数,N 表示需要遍历的数据量,从这里我们可以总结出提升查询性能可以考虑的两点:.

从未降级的搜索技术-Hippo在线服务调度系统

- - 搜索技术博客-淘宝
          很久很久以前,有一个PE叫川小生,有一个开发叫子小嘉. 双11前,他们按照业务的要求给天猫准备了14倍余量,给主 搜准备了1倍余量. 结果11号上午流量涨势喜人啊,嗖嗖往上涨. 川小生和子小嘉说不对啊,怎么主搜涨这么厉害天猫只涨4倍呢,川小生掐指一 算,干,到 晚上主搜就挂了啊.

如何为技术博客设计一个推荐系统(中):基于 Google 搜索的半自动推荐

- - Blog | Phodal - A Growth Engineer
与统计学相比,基于内容来向用户推荐相似的内容,往往更容易获得. 在技术领域,作者通常比大多数读者更专业,他们往往知道什么是读者需要的. 如,你看了一个 React 相关的文章,你可能会需要 Redux 相关的内容. 需要一些前提条件:融合现有系统的数据信息,获取一些用户的信息. 随后,再计算出相关的内容,最后返回给读者.

从未降级的搜索技术

- - 搜索技术博客-淘宝
在搜索我经历过全部的双11,12年和13年这2次大促,GN是开发总指挥,我是在礼台上看各种新武器实弹表演. 过去6年里,我们的引擎体系每年做到100%的性能提升,以淘系搜索为例,从最初3000台机器翻倍到现在区区6000台,但搜索服务却从6千qps增长了40倍到现在的32万qps,同时还填补了算法欲壑(算法数据占用内存从最初的10%到了现在的50%),转化率持续攀升,目前大搜索GMV已经是全网的主体了.

Twitter实时搜索系统EarlyBird

- - CSDN博客互联网推荐文章
twitter对存档的tweet使用lucene做全量索引,新发的推文则是实时索引,实时检索(10秒之内索引). 实时索引和检索系统叫EarlyBird. 感觉写得比较清楚简洁,只要这些信息足够真实可信,完全可以做实现参考. 1)基于lucene + java,michael busch是lucene committer.

4个步骤,小结搜索系统

- - 人人都是产品经理
搜索系统作为用户自行使用的引导工具,重要程度不言而喻;本文主要从4步:需求识别、检索、排序、展现来总结搜索系统的工作机制. 搜索是一个比较有年份的功能,他不是一个简单的搜索框,毕竟搜索造就了一个百度帝国. 搜索系统在产品架构中是帮助用户搜索到他们想要的内容,当用户不知道如何通过其他路径直接获取特定内容的时候才会使用,也就是说搜索是用户自行使用最后的一个引导工具,重要程度不言而喻.

从未降级的搜索技术-天猫SKU搜索

- - 搜索技术博客-淘宝
前些天,五福老大的文章《 从未降级的搜索技术》介绍了搜索双11的5件新式武器,其中就包括天猫SKU搜索. 本文就对此做一些更详细的介绍:. SKU,Stock Keeping Unit,库存单元,是商品库存的最小单位. 通俗的讲,一种商品可能有各种规格的货,每一种货就是一个SKU. 比如,iphone6有白色16G、金色16G、白色64G、金色64G、等多种SKU;再比如商家售卖的某款T恤有白色S码、黑色S码、白色M码、黑色S码、等等SKU.

从图谱搜索看搜索技术的发展趋势

- - 微软亚洲研究院
编者按:图谱搜索(Graph Search)是基于社交图谱构建起来的搜索服务,与基于关键词匹配的传统网络搜索引擎相比,图谱搜索能够支持更自然、复杂的查询输入,并针对查询直接给出答案. 在微软亚洲研究院副研究员段楠眼中,这样的高效个性化搜索会越来越多. 文章中,他从基础架构、自然语言接口、相关研究、发展趋势等几个方面,对计算搜索的现在和未来进行了总结和展望.

遗留系统的技术栈迁移

- - 博客园_知识库
  什么是遗留系统(Legacy System). 根据维基百科的定义,遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序[ 1]. 这一定义事实上并没有很好地揭露遗留系统的本质. 我认为,遗留系统首先是一个还在运行和使用,但已步入软件生命周期衰老期的软件系统. 它符合所谓的“奶牛规则”:奶牛逐渐衰老,最终无奶可挤;然而与此同时,饲养成本却在上升.

豌豆荚工程师谈其新版应用搜索技术

- - InfoQ cn
豌豆荚近日发布了应用搜索的新版本,主要针对安全、隐私等问题做出了改善,InfoQ就相关技术问题对其工程师进行了采访. InfoQ:首先请二位做下自我介绍. 陈兴润:我叫陈兴润,是豌豆荚的后台工程师,和吉昌一样也是早期的团队成员,主要负责应用搜索. 丁吉昌:我叫丁吉昌,我跟兴润是同期来豌豆荚的,现在我们也在一个团队,我现在算是应用搜索的负责人.