搜索引擎与宝贝搜索不得不说的故事
认识淘宝宝贝搜索 连衣裙包邮!! 买个iphone5! 送女朋友什么裙子好呢? 手机大甩卖!! 宝贝搜索 牛仔裤清仓买一送一!! …… ……
宝贝搜索的特点 数据量大: 8亿 数据更新量大: 2亿/天 查询量大: 3-4亿PV/天 查询准确率要求高——对买家负责,降低查找成本 查询召回率要求高——对卖家负责,让每个宝贝搜 索可达 业务逻辑复杂:属性信息远大于倒排信息
宝贝搜发展史——数据量
宝贝搜发展史——查询量
宝贝搜索发展史——大事记 淘宝网 2003年 商城 2008年 一淘网 2012年 未来 C2C宝贝 C2C宝贝 B2C宝贝 C2C宝贝 全网购物搜索 一站式购物体验 发现 比较 优惠券 C2C宝贝 B2C宝贝 全网购物搜索 一站式购物体验 发现 比较 优惠券 个性化 协同搜索
淘宝搜索架构演变 引擎平台统一 业务引擎分离 业务逻辑分离 解决容量速度 解决搜索功能
搜索引擎面临的技术挑战 不断增长的搜索 复杂多变的业务 数据量日益增长 庞大的属性信息 频繁地数据更新 灵活的运帷平台 每年痛并快乐着的大促(1111/1212) ——爆发式流量增长和更新量增长
解决之道——数据聚合层(SP/Agg) 关联非引擎服务(UPS、QP、Forest etc.) 多路数据混排(同构数据、异构数据) 搜索结果Rerank 其他各种“异想天开”的业务逻辑 统一服务入口
解决之道——灵活的配置/插件接口 Build插件:允许对建索引的原始文档进行加工 分词插件: 控制检索粒度 QRS插件:改写Query定制业务逻辑、改写结果满 足业务需求 属性信息定制化:直接使用Attr(price)、简单表达 式(price+postage)、插件化(lib.so) Scorer插件:特殊的属性信息定制化功能 丰富的配置接口
解决之道——减肥是永恒的主题 高召回率、低响应延时 内存引擎 数据量的增长、属性信息的增多带来挑战 根据业务需求不断对引擎进行瘦身 倒排信息压缩(P4Delta等) 正排信息精确存储(xBits, int8, int16, int32, …) 正排信息压缩(GroupVariInt等) 正排信息去重(偏移存储) 属性信息编码压缩 ……
解决之道——性能优化 神级性能优化之道——Cache 奇迹般近乎无损的截断——深入理解业务 对付频繁更新带来的性能衰减——UPI(运维支撑) 商品搜索性能杀手——正排信息的访问(L1/L2 Cache与RAM的博弈) 业务发展永远都是粗旷型的——定期Review业务实 现常常会有意想不到的收获 数据分层
解决之道——一体化运维体系 伟大的Admin——集中式管理 故障自动恢复 多集群管理 按需索引分发 索引自动切换和更新 集群拓扑动态发现
解决之道——OpenSearch 解决中小商业搜索 应用 核心技术 大量小应用运维 Search as a service 自助式使用搜索 在线修改schema 全流程索引自描述 核心技术 HBase Free schema Rank formular
解决之道——回到原点 业务的发展让一起问题回到原点:性能、容量、业 务灵活性、集群运维能力等等 譬如个性化。。。(TO BE Continue) 搜索问题永无止境,谢谢!