1. 项目缘起为什么召回系统需要“四库全书”做搜索和推荐的朋友尤其是最近在折腾RAG检索增强生成架构的肯定对“召回”这个词不陌生。简单说召回就是从海量数据里快速、准确地捞出一小撮最相关的候选集交给后面的精排或生成模型去处理。这就像你去一个超大的图书馆找书第一步不是逐本精读而是根据书名、作者、分类号这些线索先拉出一个可能相关的书单。很多人一提到召回脑子里蹦出来的就是向量数据库觉得把数据向量化一存用个近似最近邻ANN算法一搜齐活了。但真干过这活儿的都知道事情没这么简单。一个能扛住线上流量的召回系统背后往往不是一个数据库而是一个协同作战的“数据库舰队”。我最近在重构一个内容平台的召回模块核心目标是把用户查询的召回相关性和效率提上去。经过几轮踩坑和方案迭代我最终敲定了四个数据库各司其职的架构MySQL、Elasticsearch、Qdrant外加一个常被忽略但至关重要的Redis。这不是炫技堆砌技术栈而是每种数据库都解决了召回链路中一个特定的、用其他工具会非常别扭的问题。今天这篇我就来拆解一下为什么是这四个它们各自扮演什么角色以及如何把它们像搭积木一样严丝合缝地组装起来为你的召回系统提供一个坚实、高效且灵活的前置数据层。无论你是正在设计一个新的召回系统还是对现有单一向量检索的方案感到力不从心相信这套“四库”思路都能给你带来一些启发。2. 召回流程拆解四类数据与四种查询需求在动手建库之前我们得先想清楚召回到底需要处理哪些数据响应哪些查询。不能手里拿着锤子比如只会用ES就看什么都像钉子。一个典型的融合召回流程面对一次用户查询比如“2024年性价比高的轻薄笔记本电脑推荐”可能会触发以下几类检索关键词精确匹配与属性过滤需要找出所有标题、标签里含有“笔记本电脑”、“轻薄”、“性价比”这些词的文章并且过滤出“品类电脑”、“发布时间2023年”的商品。这要求数据库具备强大的倒排索引和结构化查询能力。语义向量相似度检索用户query“性价比高的轻薄本”和文章内容“经济实惠的便携式计算机”虽然字面不同但意思高度相关。这就需要将查询和文档都转化为向量在高维向量空间中计算相似度。这要求数据库具备高效的向量索引和近似最近邻搜索能力。实时、高频的元数据读取与缓存在召回后精排或重排阶段往往需要快速获取候选物品的详细属性如价格、销量、作者、状态等进行打分或过滤。这些属性可能存储在别处需要毫秒级获取。这要求一个超低延迟的缓存。关系型数据与事务性支撑物品的元数据如ID、标题、类目、上下架状态、用户行为日志点击、购买、以及各种配置信息召回策略开关、权重参数的持久化存储与管理需要强一致性和复杂关系查询支持。看到这里你应该明白了没有一种数据库能同时完美满足以上四点。MySQL擅长4Elasticsearch是1的王者Qdrant专精于2而Redis则是解决3的不二之选。它们的分工正是基于数据特性和访问模式的最优解。注意这里提到的“四库”是一种逻辑架构。在实际中如果数据量小或场景简单ES的向量检索功能8.x后的dense_vector或MySQLRedis也能组合应对。但一旦面临高并发、多模态、复杂过滤的召回场景专业化分工的优势就会非常明显。3. 核心数据库一MySQL - 召回系统的“定海神针”把MySQL放在第一个讲是因为它是整个数据生态的“源”和“锚”。所有需要长期保存、关系复杂、且对一致性要求高的数据都应该放在这里。3.1 在召回中MySQL具体存什么物品Item元数据主表这是核心。每一条待召回的内容商品、文章、视频都在这里有一条记录。包含item_id(主键)title,description(文本用于后续的ES索引和向量化)结构化属性category_id,price,brand,status(上架/下架),publish_time等。统计字段view_count,sales_count(这些可能由其他系统更新)。关系表item_category: 物品与类目的多对多关系。item_tag: 物品与标签的关系。user_behavior(可选): 用户历史行为日志的原始存储清洗和聚合后可能会进入ES或Redis用于召回。系统配置表recall_config: 存储不同召回通道如“热门召回”、“协同过滤召回”、“向量召回”的开关、权重、参数等。这允许我们动态调整召回策略无需发版。3.2 表结构设计与优化要点对于物品主表设计时要充分考虑后续的查询和更新模式。CREATE TABLE items ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 主键ID, item_id varchar(64) NOT NULL COMMENT 业务唯一ID, title varchar(255) NOT NULL DEFAULT COMMENT 标题, description text COMMENT 描述, category_id int(11) NOT NULL DEFAULT 0 COMMENT 类目ID, price decimal(10,2) DEFAULT NULL COMMENT 价格, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态:1-上架,0-下架, publish_time datetime NOT NULL COMMENT 发布时间, ext_json json DEFAULT NULL COMMENT 扩展属性(JSON格式), created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_item_id (item_id), KEY idx_category_status (category_id,status), KEY idx_publish_time (publish_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT物品主表;设计思考与避坑指南主键选择使用自增id作为InnoDB主键有利于顺序写入和聚集索引性能。item_id作为业务唯一键用于外部系统引用。索引策略idx_category_status是一个联合索引专门服务于“按类目筛选且状态为上架”的常见查询场景。idx_publish_time则用于按时间排序的召回如“最新内容”。扩展字段ext_json字段非常重要。召回系统经常需要增加新的过滤维度如“是否包邮”、“屏幕尺寸”。如果每个新属性都加一列表结构变更会非常频繁且影响性能。使用JSON字段可以灵活存储这些扩展属性虽然查询效率不如原生列但结合MySQL的JSON函数和生成列功能可以在灵活性和性能间取得平衡。“软删除”与状态使用status字段标记上下架而不是物理删除记录。这样能保证下游的ES、Qdrant中的数据ID与MySQL始终有映射关系避免出现“幽灵数据”。3.3 如何为其他数据库提供数据源MySQL的角色是源数据仓。我们需要建立可靠的数据同步机制将变更增、删、改实时或近实时地同步到ES和Qdrant。方案一监听Binlog推荐使用Canal、Debezium或MaxWell等工具订阅MySQL的binlog将数据变更解析成事件发送到消息队列如Kafka然后由消费者写入ES和Qdrant。这是对业务代码无侵入的通用解法。方案二双写在业务代码中写入MySQL后同步或异步地调用ES和Qdrant的写入接口。这种方式逻辑简单但需要处理好写入失败的事务补偿和一致性代码耦合度高。方案三基于更新时间戳的定时扫描适用于对实时性要求不高分钟级的场景。定时任务扫描updated_at字段有变化的记录进行同步。在我们的实践中Binlog Kafka的方案是最稳健的它将数据同步解耦为一个独立的基础设施层业务方无需关心。4. 核心数据库二Elasticsearch - 关键词与复杂过滤的“引擎”当召回条件包含明确的关键词、需要复杂的布尔逻辑AND/OR/NOT、范围查询、或需要按照相关性评分排序时Elasticsearch就是你的主力引擎。4.1 ES索引Mapping设计为召回而生在ES中我们通常为“物品”创建一个索引例如items_index。Mapping的设计直接决定召回的能力和性能。PUT /items_index { settings: { number_of_shards: 3, number_of_replicas: 1, analysis: { analyzer: { ik_smart_pinyin: { type: custom, tokenizer: ik_smart, filter: [pinyin_filter] } }, filter: { pinyin_filter: { type: pinyin, keep_first_letter: false, keep_full_pinyin: true, keep_original: true } } } }, mappings: { properties: { item_id: {type: keyword}, title: { type: text, analyzer: ik_smart_pinyin, // 使用IK拼音分词器 fields: { keyword: {type: keyword} // 用于精确匹配 } }, description: {type: text, analyzer: ik_smart}, category_id: {type: integer}, price: {type: float}, status: {type: keyword}, publish_time: {type: date}, tags: {type: keyword}, // 标签字段用于精确过滤 view_count: {type: long} } } }设计核心点分词器是灵魂对于中文场景ik_smart或ik_max_word分词器必不可少。我们额外集成了pinyin插件创建了ik_smart_pinyin分析器这样用户搜索“pingguo”也能匹配到“苹果”极大提升召回率。多字段Multi-fieldstitle字段同时拥有text类型用于分词搜索和keyword类型用于精确匹配或聚合。这非常实用。字段类型选择用于过滤的字段如category_id,status,tags通常设为keyword或integer利用倒排索引实现高效过滤。数值型范围过滤用float/long日期用date。4.2 构建召回查询DSL一个典型的融合了关键词搜索和属性过滤的召回DSL如下POST /items_index/_search { query: { bool: { must: [ { multi_match: { query: 轻薄 笔记本电脑 性价比, fields: [title^3, description^1], // title权重更高 type: best_fields } } ], filter: [ {term: {status: 1}}, {term: {category_id: 101}}, {range: {price: {gte: 3000, lte: 8000}}}, {range: {publish_time: {gte: now-1y/d}}} ] } }, size: 100, // 召回数量 _source: [item_id, title, price], // 只返回必要字段减少网络开销 sort: [ {_score: {order: desc}}, // 按相关性分排序 {view_count: {order: desc}} // 次要排序 ] }这个查询完成了在“电脑”类目下找出过去一年内发布的、价格在3000-8000元、状态为上架的并且在标题和描述中与“轻薄 笔记本电脑 性价比”相关的商品按相关性和浏览量排序返回100条。实操心得must用于影响相关性算分filter用于不影响算分的精确过滤性能更好。_source过滤非常重要在召回阶段往往只需要物品ID和一些核心字段全量返回会浪费大量网络和序列化资源。复杂的过滤条件特别是多个range查询可能会影响性能需要监控慢查询。4.3 性能调优与陷阱分片数分片数在创建索引时设定后期修改成本极高。一个分片是一个独立的Lucene索引。分片过多会增加管理开销和查询聚合成本过少则无法利用水平扩展。通常建议每个分片数据量在20GB-50GB之间。对于召回索引如果数据量不大比如千万级3-5个分片起步是常见选择。避免深度分页召回查询的size不应过大通常不超过1000。如果需要大量数据使用search_after参数而不是from/size做深度分页。冷热数据分离对于时间序列明显的物品如新闻、短视频可以将新数据写入“热”索引配置在SSD磁盘上旧数据定期迁移到“冷”索引配置在HDD磁盘上。查询时使用索引别名同时查询热索引和冷索引。5. 核心数据库三Qdrant - 向量语义召回的“专业选手”当你的召回需要理解语义而不仅仅是关键词匹配时向量数据库就该上场了。在众多选手中Qdrant因其性能、丰富的过滤支持和友好的API脱颖而出。5.1 Qdrant的核心概念与集合创建在Qdrant中数据存储在“集合”Collection中。创建一个集合需要定义向量的维度、距离度量方式以及可选的Payload结构。假设我们使用BERT模型生成768维的向量使用余弦相似度Cosine进行度量。# 使用Qdrant Python客户端 from qdrant_client import QdrantClient from qdrant_client.http import models client QdrantClient(hostlocalhost, port6333) client.create_collection( collection_nameitem_vectors, vectors_configmodels.VectorParams( size768, # 向量维度 distancemodels.Distance.COSINE # 距离度量方式 ) )Payload是Qdrant的精华。它允许你为每个向量点存储结构化的元数据类似于MySQL或ES中的字段并且可以在向量搜索的同时对这些元数据进行高效的过滤。# 定义Payload的结构在插入数据时体现 payload { item_id: 12345, category_id: 101, price: 5999.99, status: online, publish_time: 2024-01-15T10:30:00Z }5.2 插入向量与Payload数据数据同步服务从Kafka消费到物品变更事件后需要调用嵌入模型如BERT、OpenAI text-embedding将文本title description转化为向量然后连同Payload一起插入Qdrant。import numpy as np from your_embedding_model import get_embedding # 假设从数据变更事件中获取到物品信息 item_data { item_id: 12345, title: 高性能轻薄笔记本电脑..., description: ..., category_id: 101, price: 5999.99, status: online, publish_time: 2024-01-15T10:30:00Z } # 1. 生成文本向量 text_to_embed f{item_data[title]} {item_data[description]} vector get_embedding(text_to_embed) # 返回一个768维的numpy数组 # 2. 准备Payload payload { item_id: item_data[item_id], category_id: item_data[category_id], price: item_data[price], status: item_data[status], publish_time: item_data[publish_time] } # 3. 插入Qdrant (使用item_id作为点的id) point_id int(item_data[item_id]) # Qdrant的id需要是整数或UUID client.upsert( collection_nameitem_vectors, points[ models.PointStruct( idpoint_id, vectorvector.tolist(), payloadpayload ) ] )5.3 执行带过滤的向量检索这是Qdrant最强大的地方之一你可以在向量相似度搜索的基础上施加复杂的过滤条件。from qdrant_client.http import models # 用户查询向量化 query_vector get_embedding(2024年性价比高的轻薄本) # 构建搜索请求 search_result client.search( collection_nameitem_vectors, query_vectorquery_vector, query_filtermodels.Filter( must[ # 必须满足的条件 models.FieldCondition( keystatus, matchmodels.MatchValue(valueonline) ), models.FieldCondition( keycategory_id, matchmodels.MatchValue(value101) ), models.FieldCondition( keyprice, rangemodels.Range( gte3000, lte8000 ) ) ] ), limit100 # 召回数量 ) # 返回结果包含点ID、相似度分数和Payload for hit in search_result: print(fID: {hit.id}, Score: {hit.score}, Payload: {hit.payload})这个查询实现了在“状态为上架、类目为101、价格在3000-8000元”的所有物品中找出向量与查询向量最相似的100个。它完美融合了语义理解和属性过滤。踩坑实录Payload过滤的性能Qdrant的过滤是在向量搜索之前执行的。如果过滤条件过于宽泛比如只过滤statusonline它仍然需要扫描大量点。为了极致性能可以考虑建立Payload索引对频繁过滤的字段如category_id,status创建Payload索引。client.create_payload_index( collection_nameitem_vectors, field_namecategory_id, field_schemamodels.PayloadSchemaType.INTEGER )使用预过滤Pre-filter对于可以明确划分的维度可以创建多个集合如item_vectors_category_101,item_vectors_category_102直接查询目标集合避免过滤开销。但这会增加数据管理的复杂度。6. 核心数据库四Redis - 召回链路的“高速缓存”Redis在召回系统中扮演的是“加速器”和“粘合剂”的角色。它不持久化核心数据但解决了两个关键问题降低延迟和存储中间状态。6.1 缓存热点物品的详细元数据从ES或Qdrant召回得到的是物品ID列表。精排模型通常需要更丰富的特征如近7日销量、实时点击率、库存状态。这些特征可能来自MySQL或其他实时计算系统。直接频繁查询MySQL会给数据库带来巨大压力。解决方案使用Redis哈希Hash结构缓存物品的详细元数据。Key设计item:meta:{item_id}Value一个Hash字段包括price,brand,sales_7d,ctr,stock等。# 写入缓存 HSET item:meta:12345 price 5999.99 brand Apple sales_7d 1500 ctr 0.05 stock 100 # 批量读取 (在精排服务中) MGET item:meta:12345 item:meta:67890 ...缓存策略写入物品信息变更时通过监听Binlog主动更新Redis缓存Cache-Aside模式。过期设置合理的TTL如5-10分钟防止脏数据长期存在。即使缓存失效回源到MySQL查询也能保证最终正确。批量操作精排时需要获取上百个物品的特征务必使用MGET或Pipeline批量操作避免网络往返开销。6.2 存储用户实时行为与Session数据一些召回策略依赖于用户的实时行为比如“看了又看”、“实时热门”。这些数据需要极低的读写延迟。用户最近点击序列# Key: user:recent_click:{user_id} 使用List结构维护固定长度如50 LPUSH user:recent_click:1001 item:12345 LTRIM user:recent_click:1001 0 49物品实时统计# Key: item:stats:{item_id} 使用Hash结构存储实时计数 HINCRBY item:stats:12345 click_count 1 HINCRBY item:stats:12345 impression_count 1 # 可以设置定时任务将Redis中的实时计数同步到MySQL或ES6.3 作为多路召回结果的融合暂存地在“多路召回重排序”的架构中召回阶段可能并行发起多个查询如ES关键词召回、Qdrant向量召回、基于协同过滤的召回。这些召回结果需要汇集到一起进行去重、粗排或直接送入精排。Redis的有序集合Sorted Set非常适合这个场景。我们可以为每个召回请求创建一个临时的Sorted Set。import redis import uuid r redis.Redis(hostlocalhost, port6379, db0) def merge_recall_results(request_id, recall_channel, item_score_list): request_id: 本次请求的唯一ID recall_channel: 召回通道名如 es_keyword, qdrant_vector item_score_list: [(item_id, score), ...] temp_key frecall:temp:{request_id}:{recall_channel} # 将本路召回结果存入一个临时有序集合score就是召回分数 pipe r.pipeline() for item_id, score in item_score_list: pipe.zadd(temp_key, {item_id: score}) pipe.expire(temp_key, 300) # 设置5分钟过期防止内存泄漏 pipe.execute() # 假设三路召回并行完成结果已存入三个临时key # 然后进行融合例如取并集按分数排序 union_key frecall:union:{request_id} r.zunionstore(union_key, [temp_key1, temp_key2, temp_key3], aggregateMAX) # 按最大分数聚合 top_200_items r.zrevrange(union_key, 0, 199, withscoresTrue) # 取Top 200 # 最后清理临时key这种方式将复杂的多路结果融合逻辑变成了高效的Redis原子操作性能远超在应用内存中处理。7. 四库协同从数据同步到服务化查询数据库建好了但它们是孤岛。我们需要让数据流动起来并对外提供统一的召回服务。7.1 数据同步架构设计我们采用基于Binlog的最终一致性同步方案确保数据从MySQL源头有序地流向ES和Qdrant。[MySQL] - (Binlog) - [Canal/Debezium] - [Kafka Topic: mysql.item_changes] - [Sync Consumer Group] | |- [ES Sync Consumer] - [Elasticsearch] |- [Qdrant Sync Consumer] - [Qdrant] |- [Redis Cache Updater] - [Redis]Kafka Topic按表拆分例如db_name.table_name。对于items表Topic就是mydb.items。同步消费者ES Sync Consumer解析INSERT/UPDATE/DELETE事件转换为ES的index/update/deleteAPI调用。对于UPDATE可能需要回查MySQL获取完整数据。Qdrant Sync Consumer同样解析事件。对于INSERT/UPDATE需要调用嵌入模型API生成新的向量然后upsert到Qdrant。这里有个关键点向量生成比较耗时是同步流程的瓶颈。必须做好异步化和批处理可以考虑将需要向量化的数据推送到另一个队列由专门的向量化Worker处理后再写入Qdrant。Redis Cache Updater监听items表的更新直接更新或失效对应的item:meta:{id}缓存。7.2 构建统一的召回服务Recall Service这是面向业务方的统一入口。它接收一个查询请求包含关键词、过滤条件、用户上下文等内部协调调用ES、Qdrant等多个召回源进行结果融合并可能从Redis获取补充特征。服务接口设计class RecallRequest: query: str # 用户查询文本 user_id: Optional[str] filters: Dict # 过滤条件如 {category_id: 101, min_price: 3000} recall_strategies: List[str] # 指定使用的召回通道如 [es_keyword, qdrant_vector] size: int 200 # 每路召回数量 fusion_method: str union # 融合方式union, rrf(Reciprocal Rank Fusion)等 class RecallResponse: request_id: str items: List[RecallItem] # 物品ID、分数、来源通道等 class RecallService: def recall(self, request: RecallRequest) - RecallResponse: # 1. 并行发起多路召回 futures [] if es_keyword in request.recall_strategies: futures.append(self._recall_by_es(request)) if qdrant_vector in request.recall_strategies: futures.append(self._recall_by_qdrant(request)) # ... 其他召回策略 # 2. 等待所有召回结果 all_results [] for future in futures: try: all_results.extend(future.result()) except Exception as e: logger.error(fRecall channel failed: {e}) # 降级处理例如忽略该路结果 # 3. 结果融合与去重 fused_items self._fusion_and_dedup(all_results, request.fusion_method) # 4. 获取物品元数据从Redis缓存 item_ids [item.id for item in fused_items[:request.size]] item_metas self._get_item_metas_from_cache(item_ids) # 5. 组装响应 return RecallResponse(itemsfused_items_with_meta)融合策略Fusion并集Union最简单的去重合并。轮询Round Robin从各路结果中轮流取一个保证多样性。分数标准化后加权将各路召回分数归一化到同一尺度如0-1然后加权求和。难点在于权重的设定和分数的可比性。** Reciprocal Rank Fusion (RRF)**一种不依赖分数绝对值的融合方法只利用物品在各路结果中的排名效果通常不错且稳定。公式大致为score sum(1 / (k rank_i))rank_i是物品在第i路结果中的排名k是一个常数通常取60。7.3 监控与运维要点一个稳定的召回系统离不开监控。数据库层面MySQL监控慢查询、连接数、主从延迟。Elasticsearch监控集群健康状态_cluster/health、节点磁盘使用率、索引的search和index延迟。Qdrant监控集合的点数、内存/CPU使用率、搜索QPS和延迟。Redis监控内存使用率、连接数、缓存命中率、慢查询。同步链路监控Kafka消费延迟Consumer Lag这是衡量数据同步实时性的关键指标。服务层面召回服务监控各召回通道的QPS、平均延迟、错误率、超时率。设置不同通道的降级开关。向量化服务监控模型推理的延迟和吞吐量这是向量召回链路的潜在瓶颈。业务效果通过A/B测试对比不同召回策略、融合方法对最终业务指标如点击率、转化率的影响。这是迭代优化召回系统的根本依据。8. 总结与个人实践中的几点体会搭好这四个数据库就像是给召回系统建好了四个专业车间MySQL是原料仓库ES是精密零件加工中心Qdrant是智能识别实验室Redis是高速装配流水线。它们各司其职通过数据流水线BinlogKafka连接最终由召回服务这个总装车间产出成品。回顾整个搭建过程有几个体会特别深第一没有银弹只有组合拳。早期我们试图用ES的向量检索功能包打天下但在面对复杂的多属性过滤和实时性要求时非常吃力。引入Qdrant专门处理向量用Redis做缓存和中间状态整个系统顿时清晰、高效了许多。技术选型一定要匹配场景的“主矛盾”。第二数据一致性是个持久战。Binlog同步方案看似完美但实际会遇到各种问题消息乱序、重复消费、向量化失败、网络抖动。必须为同步程序设计完善的幂等、重试和告警机制。我们为每条数据同步记录状态如sync_to_es_status,sync_to_qdrant_status并有一个补偿任务定期扫描失败记录进行重试。第三性能优化是细活。ES的索引设置、Qdrant的Payload索引、Redis的Key设计和批量操作、以及多路召回的并行超时控制每一个细节都可能成为瓶颈。必须建立全面的监控从宏观QPS到微观的99分位延迟都要了然于胸。第四召回是为下游服务的。召回不是终点。我们设计的Payload、缓存的元数据都是为了方便精排模型快速获取特征。召回阶段返回的item_id列表和基础分数是精排阶段的重要输入。在设计数据流时要时刻想着下游需要什么。这套“四库”架构在我们当前千万级物品、日均百万级查询的场景下运行稳定支撑了关键词、语义、个性化等多路召回需求。当然随着数据量和场景复杂度的增长可能还需要引入图数据库处理关系召回或者更复杂的缓存分层。但无论如何理解每种数据库的核心能力让它们做自己最擅长的事这个思路是不会变的。希望这篇长文能为你搭建自己的召回数据层提供一份切实可行的蓝图。