Elasticsearch 在商品中台的落地实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 微盟 Elasticsearch 在商品中台的落地实践
张金榜 - 微盟技术专家
2023 Weimob Technical Salon
2. 讲师介绍
张金榜
微盟技术专家. 商品域中台负责人，深耕商品领域多
年，主要负责商品域中台的后端技术架构设计、业务
架构设计、底层通用能力建设、线上稳定性建设。专
注于商品中台的高扩展、高性能的架构设计，并在商
品搜索领域内，有较深入的研究和实践
3. 目
录
01. ES 在商品中台的业务场景
02. 基于业务场景下的使用建议
03. 基于业务场景下的 ES 优化策略
4. 01.
ES 在商品中台的业务场景
简介：ES 在商品中台业务使用场景，具备怎么
样的规模体量，在使用过程中，具备怎么样的
一些落地实践
5. 商品搜索在电商中的核心场景
购物习惯
6. ES 在商品中台的业务场景
商品搜索
强意图
人
货
用户意图明确，要买，想买，想看
搜索在商品中台
就是解决这样的核心痛点
并为转化带来增长
场
商品量大 ‘场地’ 有限
商品数量多，类目多，sku多 电商平台 ‘场地’ 有限，商品难露出
7. ES 在商品中台的业务场景
B/C端多条件混合检索
B/C 端主要针对商品上的一系列特征描述: 名称、属性、分组、条码… 来进行各
种混合联动检索过滤以及特征排序推荐
方便商户便利的进行B端商品管理和C端快速的商品露出，实现搜索的业务价值
8. ES 在商品中台的业务场景
模式及规模介绍
商品中台业务 ES 的承载了TB级别的数据, 支撑日均亿级别的高频查询和写入，平均耗时也控制在20ms
内。
系统持续稳健的为业务提供着高效的检索能力与实时的写入同步能力
9. 抛几个问题
01.
在使用 ES 的过程中，最重要的环节是什么呢？
02.
当业务需求和底层限制约束出现冲突时，如何做权衡
呢？
03.
在过程中遇到的不少问题，逐个击破，并沉淀下
了一些思维模式和方法论
作为业务研发，我们要从哪些方面关注和着力，来保障
我们的系统持续稳健呢？
10. 02.
基于业务场景下的使用建议
简介：本章节会从 ES 在整个业务迭代生命周期着手，从过程
中沉淀的一些思路、方法论来展开：ES 建模与设计、技术限
制与业务边界、业务监控体系、检索准入条件、业务的可扩展
设计等
11. 数据建模
现实
世界
数字
世界
?
概念建模
逻辑建模
建模
物理建模
12. 建模
技术层出不穷，工具更新换代，都有其
特定的名词和形态。
幸运的是，在技术迅速变化的背后，总
是存在一些持续成立的原则，这些原则
就是被验证，稳固的底层架构
抽象谓之模型
“吾生也有涯，而知也无涯。
以有涯随无涯，殆已”
13. ES建模
数学建模 ES 建模
调查研究 需求分析，性能分析，场景明确
模型假设 业务限界，ES 限制
模型建立 方案设计，详细设计，业务索引设计，ES 物理实体设计
模型求解 开发，测试，验证
模型检验 测试验证，性能压测
模型应用 上线交付
14. 模型调研-业务分析与评估
数据规模
数据分布特点 场景特点
健壮容忍度
近期数据规模 时间维度 读多写少 是否可降级
远期数据规模 商户维度 写多读少 SLI/延迟
是否具备生命周期 用户维度 时效性 多久时间恢复
hot、warm、clod、delete 扩散维度 读写QPS ...
... ... ...
15. 模型调研-业务限界评估
性能限
界
• 峰值
QPS
• RT
业务规
模体量
业务是
否允许
一定的
延迟
是否接
受暂时
不一致，
最终一
致
极端情
况数据
丢失？
宕机？
成本限
制？
16. 模型假设-容量评估
容量影响因素
副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。
数据膨胀：除原始数据外，ES 需要存储索引、列存数据等，在应用编码压缩等技术后，一般膨胀10%。
内部任务开销：ES 占用约20%的磁盘空间，用于 segment 合并、ES Translog、日志等。
操作系统预留：Linux 操作系统默认为 root 用户预留5%的磁盘空间，用于关键流程处理、系统恢复、防止磁盘碎片化问题等
不谋万世者，不足某一时；不谋全局者，不足谋一域
17. 模型设计- 索引设计
ES 是基于 Lucene 以倒排索引为基础实现的存储体系，不遵循关系型数据库中的范式约定，也
不会被约束, 很灵活强大，往往会有一些出其不意的惊喜，尤其当开启了一些自动映射的时候。
所以，需要在业务层面做好约束
索引
字段
仅存检索
字段
不做过多
冗余
数据
结构
异构只能
打平？
指数级的
扩散
索引
拆分
大索引、
多个索引
多索引配
合
业务
变更
字段合并
提前预设
吝啬式设计，若非必要，勿增实体
18. 模型建立- 分片
分片大小
分片越大，故障恢复影响越大
• 单分片经验：20G-50G
• 文档上限
分片个数
分片个数越多，遍历分片越多
• 远期index大小/ 最大分片大小 + 节点个数 == 分片数
• 远期文档数/ 单分片个数 == 分片数
• 分片越多，查询性能越差，适当注意指定路由 + 防止数据倾斜
• 修改成本很高
副本数
• 默认1个
副本越多，写入性能越差
19. 模型建立- Mapping设计
字段类型
• keyword、number、text
• 使用场景（仅检索、排序、聚合、模糊/精确匹配）
善用二级类型 • 通过巧妙的设计相同字段的不同类型
• 高性能的满足业务诉求
警惕默认类型 • dynamic 尽量不要开启，ES的数据模型保证强约束
• 开启的前提下，需要做好一些默认映射的约束
熟悉高级特性 • _source、doc_values、store、norms ...
• 自定义的分词器
拆解业务，熟悉底层，巧妙设计
20. 模型建立-多租户隔离
帕累托法则：
80%的高频流量、压力和数据 往往来自于20%租户
数据倾
斜
极端
慢查
多租户隔离
读/写隔离
均衡压力
节点压
力过大
局部影
响全站
合理分配，适当抢占，合理隔离
21. 业务监控
业务监控
系统监控
集群、节点 性能指标监控
（cpu、内存，带宽，磁
盘...）
Index 监控，文档、搜索、
删除、线程池等
慢DSL监控
在一起，才是完整的监控
业务检索指标体系，良好的指标
体系，是优化性能的前提条件
端到端的延迟监控体系(读写)
特殊异常码监控体系
读写场景下的业务监控
...
22. 业务监控-业务指标监控体系
搜索行为
好度量是优化的指标和基础
搜索类型精细化，警惕平均值 基于业务场景，制定指标: 商品名称模糊检索、c
端分类页搜索、大批量的in查询、
搜索行为监控 B端搜索、C端搜索、其余业务场景,
搜索模板 --> 业务场景
命中数量区间监控 ES 如同MYSQL，要关注其扫描行数，命中条数
越多，很容易发生深度分页，造成的cpu飙升
敏感异常码 比如搜索和写入的 4xx rejected 信息
scroll 上下文等
...
通过主动监控发现潜在问题，过高耗时查询，在突发流量下，往往会带来突发性能问题
23. 业务监控-端到端的延迟体系
ES 在一些非日志场景的检索中，对时效性的要求会比较高，从变更到写入，在到查询
端到端的监控，可以更敏感的发现一些问题
写延迟
写延迟：大多属于binlog 触发，监听
转换，写入 ES ，每个步骤的业务延迟
db --> binlog --> mq --> ES
读延迟体系
读延迟 ：端到端的检索延迟 ，慢查询日志
客户端 --> 网络 --> ES 实际执行
24. 检索准入条件
常用字段
Keywords
Data
Object、Nested
Arrays
Numbers
Text
常用检索条件
terms
wildcard
match_phrase
range
aggregations
业务场景
模糊查询
多值in查询（精确、模糊）
区间筛选
聚合统计
分页查询
层级嵌套
因为 ES 天生的强大，就导致了一些自身的强约束条件会更少一些，业务需要基于场景，结合特
定的查询需求、字段类型，来做拦截。 ----御敌于国门之外
25. 检索准入条件
模糊匹配类
精确匹配 分页查询类 聚合类
terms
term from size
scroll
search-after aggregation
长度限制 数量一定要限制 单页条数
分页* 页码 条件范围
数量限制 拒绝为空 条件下总数量
wildcard
match_phrase
...
26. 模型建立-业务索引设计
多
业
务
通用+扩展
控成
本
设计
稳定少变动
防
腐
化
多
需
求
通用类型 + 扩展控制
极大便利的为不同业务方提供了通用的检索能力
27. 03.
基于业务场景下的 ES 优化策略
简介：在商品中台沉淀的一些 ES 优化策略和
发方法论，如何更好，更快更省的解决问题
28. ES优化 - 优化理论
整体：客户端、业务服务、DSL、ES缓存、ES-Server、 Lucene
ROI
层次 业务层 物理层 优化策略
第一层 查询需求 DSL层 减少查询
第二层 查询语句 ES层 查询路径优化
第三层 搜索引擎 Lucene 索引优化、底层修改
第四层 底层资源 硬件层 硬件优化,扩容
ES模型机制与底层知识的熟知和了解
花最核心的精力，用最少的成本，做最大收益的事情
成本
29. ES 优化 - 优化方法论
1. 上层异常
是否是入口没有做好拦截，导致了异常查询透传了。是否是瞬时相同的请求流量的透传
业务这样调用是否合理，是否可以优化，是否业务上有可可规避的方式
2. 减少查询
思考是否不必要的查询落到了 ES 中，能否减少？
3. 查询路径优化
ES 的嵌套层级是否太深？是否存在不合理的字段设置，导致了性能过差，索引、字段 是否设置合理
ES 查询三阶段，是发生在那一阶段
4. ES底层相关逻辑优化
是否可以通过 ES 底层的一些方式优化呢？是否需要调整缓存呢
比如，分词器的修改 ngram-> edge_ngram、docvalue_filed、forcemerge 内核升级优等
5. 硬件优化
优化硬件设置（操作系统层参数）或者硬件本身，扩容资源（cpu，内存，IO等）
投入
成本
30. ES 优化方法论
案例一: 一个高频次查询的API场景，必须由异构的 ES 提供查询能力 （DB还不具备查询条件），QPS一直居高不下，
随着业务发展，吞吐量已经逐步不能满足业务场景，接口频频限流，为了保护全栈系统，限流也不能放开
分析
通过分析此业务场景在的高频DSL模板
top高流量租户的查询行为
发现在5h内相同请求调用了8k+,且每晚都需要执行
且此数据在其删除之前，都是不会发生变更的
优化
针对此场景，添加一个时间较长缓存，拦截流量持续透传到ES
效果
峰值QPS 下降至原来的1/6 ES 平均耗时下降至原来的1/2
思考: 这个 ES 优化是在那个层
次？
31. ES 优化方法论
案例二 : 一个场景中，存在多个Terms 查询（上限50个），但是性能不是很好，压测场景下QPS只能达到50
且ES CPU负载已经到了50%，会严重影响业务
分析
TermInSetQuery 耗时占比高
1. 是否可以优化？
2. 是否可以不用到TermInSetQuery
3. 假设验证: 数量少一点试试
4. 求助源码
32. ES 优化方法论
1。terms 10个一批进行拆分
2。should 进行组装
效果
QPS为原来10倍，CPU稳定在20%
思考: 这个 ES 优化是在那个层
次？
33. ES 优化方法论 - 不要陷入底层陷阱，适当也得跳出来
案例三: 存在一个场景：某天商户的数据超过了1w多条，跳转最后一页进行一些数据操作，跳转不了，异常了
分析
优化
ES 默认 max_result_window: 10000 。from size 超过了固定页数，导致被ES限制了，上限可以调整。
要考虑搜索请求占用堆内存和时间与from + size成正比，且用户的数据也是持续增长的。此场景还无法接受用
滚动分页
页面展示有限，每次翻页跳页在上下5页左右
逆序二分
顺序的排序处于最后一页，把顺序翻转，是否就出现在第一页了呢？
针对输入页码跳页，做下限制，固定窗口范围之内。
34. ES 优化方法论 - 不要陷入底层陷阱，适当也得跳出来
案例四: 存在一个场景：需要支持模糊检索，但是最匹配符合的要出现在第一位
用电商规格尺码来举例： L XL/L LLL
为了支持模糊检索，分词也用了ngram分词器，步长为1
现在要用L来搜索， 出现在第一个的会是那个？
分析
ES机制分析:
ES的打分机制为 TF/IDF，然后求所有的和 。导致了出现在第一个的就是LLL
TF = (词频 / 文档中所有词的总频次)
IDF = log(语料库中文档总数 / 包含该词的文档数 + 1)
业务分析：
该索引体量不大，且数据写入和查询qps都较低
既然是所有总分的合计，是否可以冗余精确查询呢，来增强评分呢？
了解特性，应用特性，在合适的场景下，取得良好的收益
35. 小结：遇到 ES 响应慢，负载突增怎么解决？
并不是一上来就考虑资源不足、考虑扩容，也不仅仅是考虑DSL和索引、底层优化
整体分析
首先从整体分析：
• 整个链路其他环节是否有异常
• 从用户发起请求到收到返回结
果，整体耗时，在哪些地方慢
• 优先解决上层问题，比如恶意的
传参与拦截等
层次分析
其次层次分析:
• 确定其他层次没有问题，在回到DSL
层
• 优化策略是考虑减少查询（DSL层）
增加前置缓存拦截
• 再考虑DSL 优化和索引优化，最后才
是考虑硬件优或者扩容，增加资源投
入
案例复盘
最后案例复盘:
• 沉淀为我们各自系统中的方
法论和案例库和指导意见
• 作为后续的一些限制条件或
约束条件，在做设计与优化
的时候
36. ES 使用与优化，拆解业务，顶层建模
整体思考，逐层下推
熟悉架构，理解原理
关注行业
37. THANK YOU
谢谢你的观看
张金榜 - 高级技术专家
2023 Weimob Technical Salon