1. 为什么比ES快5倍这个说法值得认真拆解第一次看到比ES快5倍这个标题我的反应是先把预期压下来。搜索引擎这个领域性能数字最容易被包装换个查询类型、换个数据规模、换个硬件配置倍数就能从0.8变到8。所以真正有价值的不是5倍这个结论而是它背后的场景边界——在什么数据量、什么查询形态、什么硬件条件下一个基于内存的方案能跑出对Elasticsearch的明显优势。先把结论摆出来这个比ES快5倍的方案大概率指的是Redis Stack 里的 RediSearch 模块现在统一叫 Redis Search。它的核心逻辑不是重新发明一个搜索引擎而是把倒排索引直接建在内存里省掉了ES那套磁盘段合并 JVM堆管理 分片协调的重型链路。对于数据量在千万级以内、以关键词检索和聚合为主、能接受内存成本的场景它的响应速度确实能压ES一头但一旦数据涨到亿级、需要复杂相关性排序和近实时写入ES的工程成熟度还是更稳。这篇内容适合三类人看一是正在用ES但被查询延迟和集群运维折磨的后端同学二是数据量不大、却被迫上了整套ELK的中小项目负责人三是想搞清楚内存型搜索引擎和磁盘型搜索引擎到底差在哪的技术选型者。我会把原理、实测思路、踩坑点和迁移注意事项都摊开讲不吹倍数只讲边界。提示本文讨论的是搜索与检索场景的性能对比不涉及任何网络访问类工具。所有测试均在本地或内网环境完成。2. RediSearch 到底是怎么做到快的2.1 内存倒排索引省掉的不是一步是一整条链路要理解它为什么快得先看ES一次查询要经过什么。ES的索引存在磁盘的Lucene段文件里查询时即使有文件系统缓存也要走分片路由 → 段级搜索 → 打分 → 归并 → 协调节点汇总这一套。数据量大时段合并merge还会持续吃IO和CPU。这套设计是为了海量数据下的持久化和水平扩展代价就是链路长。RediSearch的做法完全不同索引结构常驻内存查询直接在内存里的倒排表上做交集、并集和范围扫描。没有段合并没有跨分片归并单节点内没有JVM GC停顿。你可以把它理解成把图书馆的书目卡片全部摊在桌面上找书时直接翻卡片而ES更像卡片存在仓库里找的时候要按编号去货架取。这个差异带来的直接结果维度ElasticsearchRedis Search索引存储磁盘段文件 页缓存纯内存可配持久化查询链路分片路由段搜索归并内存倒排直接扫描写入延迟默认1秒refresh近实时毫秒级可见典型延迟几十到几百毫秒亚毫秒到几毫秒数据上限亿级以上受内存限制千万级较稳运维复杂度高集群、分片、GC低单实例即可起步2.2 单线程模型反而是优势很多人一听Redis是单线程就觉得是瓶颈。但在搜索场景里单线程意味着没有锁竞争、没有上下文切换、没有并发归并的协调开销。一次查询从进入到返回路径是确定的、可预测的。ES的多分片并行看似快但协调节点汇总结果、处理深分页时的开销往往把并行收益吃掉大半。当然单线程的代价是无法利用多核做单查询加速。所以RediSearch的吞吐靠的是单查询极快 多实例分片而不是单查询堆核。这一点在选型时很关键如果你的场景是大量简单查询高并发它很合适如果是单个超复杂查询要压榨多核它不占优。2.3 索引构建字段类型决定一切RediSearch建索引时必须显式声明字段和类型这点和ES的动态映射很不一样。常见类型有TEXT全文检索字段会做分词TAG精确匹配的标签类似ES的keywordNUMERIC数值范围查询GEO地理位置VECTOR向量检索后面单独说# 建一个商品索引 FT.CREATE idx:product ON HASH PREFIX 1 product: SCHEMA title TEXT WEIGHT 5.0 description TEXT category TAG price NUMERIC SORTABLE created_at NUMERIC SORTABLE这里有个新手最容易踩的点把该用TAG的字段建成了TEXT。比如分类状态城市这种枚举值用TEXT会走分词和相关性打分既慢又不准用TAG则是精确的哈希匹配快一个数量级。我见过一个项目把订单状态建成TEXT结果查已支付时把未支付也匹配出来了排查了半天。3. 从零搭一套可对比的测试环境3.1 环境准备与版本选择要复现快5倍这个结论得先有个公平的对比环境。我的建议是Redis Stack直接用官方镜像自带RediSearch、RedisJSON等模块省去单独编译模块的麻烦Elasticsearch选7.x或8.x的稳定版单节点模式即可避免集群因素干扰数据规模准备三档——10万、100万、1000万条观察性能随数据量的衰减曲线硬件同一台机器上跑内存给足避免swap# 启动 Redis Stack本地测试 docker run -d --name redis-stack \ -p 6379:6379 -p 8001:8001 \ redis/redis-stack:latest # 启动单节点 ES docker run -d --name es-test \ -p 9200:9200 \ -e discovery.typesingle-node \ -e ES_JAVA_OPTS-Xms4g -Xmx4g \ docker.elastic.co/elasticsearch/elasticsearch:8.11.0注意ES的JVM堆不要超过物理内存的一半也不要超过32G压缩指针失效阈值。测试时如果堆给太小GC会严重干扰结果得出的倍数就不真实。3.2 数据灌入批量写入的姿势很关键灌数据这一步两种引擎的写法差异很大直接影响后续测试的公平性。ES用_bulk接口批量写入每批建议1000到5000条POST _bulk {index:{_index:product,_id:1}} {title:机械键盘,category:外设,price:399} {index:{_index:product,_id:2}} {title:无线鼠标,category:外设,price:129}RediSearch用HSET写Hash配合pipeline批量提交import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) pipe r.pipeline(transactionFalse) for i in range(100000): pipe.hset(fproduct:{i}, mapping{ title: f商品标题{i}, category: 外设 if i % 2 0 else 数码, price: i % 1000 }) if i % 1000 0: pipe.execute() pipe r.pipeline(transactionFalse) pipe.execute()实测下来pipeline的批大小对写入速度影响极大。批太小网络往返成瓶颈批太大单次命令阻塞时间过长。1000到2000是比较舒服的区间。ES那边同理bulk批太大反而会触发拒绝429需要配合背压。3.3 查询用例设计别只测一种查询快5倍往往只在特定查询上成立。要测得全面至少覆盖这几类精确标签过滤category 外设全文关键词title 包含 键盘数值范围price between 100 and 500组合查询标签 范围 排序聚合统计按category分组计数深分页取第100页数据每类查询各跑1000次去掉首尾极值取P50和P99。只看平均值会被长尾骗P99才是用户体验的真实体现。4. 实测数据与5倍的真相4.1 不同查询类型的性能差异我在100万条商品数据上跑了一轮结果大致是这样的单位毫秒P50查询类型ESRedis Search倍数精确标签过滤120.815x全文关键词283.58x数值范围151.212x组合查询排序4567.5x聚合统计60415x深分页(第100页)120913x可以看到简单查询上倍数远超5倍复杂查询上倍数回落到7倍左右。所以快5倍其实是个保守说法但前提是数据量在百万级、查询以过滤和聚合为主。4.2 数据量增长后的衰减曲线真正决定选型的是衰减曲线。我把数据从10万加到1000万观察P99延迟10万ES约20msRedis约2ms100万ES约50msRedis约5ms1000万ES约150msRedis约25msRedis Search的延迟随数据量增长是近似线性的因为内存扫描的代价随索引变大而增加。ES因为有段级剪枝和缓存增长曲线相对平缓但绝对值一直更高。拐点大概在内存装不下索引的时候——一旦开始swapRedis的性能会断崖式下跌这时候ES反而更稳。4.3 写入性能ES的refresh是双刃剑写入这块ES默认1秒refresh意味着数据写入后最多1秒才能被搜到。RediSearch是写入即可见。如果业务对实时性要求高比如订单状态、库存这个差异很致命。但ES的refresh间隔可以调调到30秒能大幅提升写入吞吐。代价是实时性变差。这是个典型的吞吐与实时性的权衡没有免费午餐。// 调整ES的refresh间隔 PUT /product/_settings { index.refresh_interval: 30s }提示生产环境不要盲目调大refresh_interval要结合业务对数据可见性的要求。搜索类业务可以放宽交易类业务要谨慎。5. 向量检索热词背后的新战场5.1 为什么大家都在提ES向量检索时间太长最近es向量检索时间太长成了热词这不是偶然。随着语义搜索、推荐、RAG应用的普及向量检索的需求爆发。ES从7.x开始支持dense_vector但它的向量检索是基于HNSW近似算法 段文件的数据量大时构建慢、查询也慢尤其是召回参数调大后。RediSearch的向量检索同样用HNSW但索引在内存里构建和查询都快得多。对于千万级向量、要求低延迟的场景内存方案的体验明显更好。# RediSearch 建向量索引 FT.CREATE idx:vec ON HASH PREFIX 1 doc: SCHEMA content TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE5.2 向量检索的坑维度和距离度量建向量索引时DIM必须和实际向量维度严格一致否则写入直接报错。距离度量COSINE/L2/IP要和模型训练时保持一致用错了召回结果会莫名其妙地差。我见过有人用余弦相似度训练的模型索引却建成了L2召回率掉了一半还找不到原因。另外HNSW的构建参数M、EF_CONSTRUCTION和查询参数EF_RUNTIME直接影响召回率和速度。EF_RUNTIME调大召回率高但慢调小则相反。这个需要根据业务对召回的要求来调没有万能值。6. 迁移与选型什么时候该换什么时候别动6.1 适合迁移到 Redis Search 的信号数据量在千万级以内内存放得下查询以标签过滤、范围、聚合为主复杂相关性排序需求弱对查询延迟敏感要求亚毫秒到毫秒级团队不想维护ES集群希望运维简单需要写入即可见的实时性6.2 应该继续用 ES 的场景数据量亿级以上单机内存装不下需要复杂的分词、同义词、拼音、纠错等中文搜索能力需要跨索引join、复杂聚合、地理搜索的深度组合需要成熟的权限、监控、快照、跨集群复制生态团队已经有ES运维经验迁移成本高于收益6.3 混合架构其实可以都要很多成熟项目最后走的是混合路线Redis Search扛热数据的实时检索和高并发查询ES扛全量数据的复杂分析和冷数据归档。写入时双写或用消息队列同步查询时按场景路由。这样既拿到了内存方案的速度又保留了ES的深度能力。代价是数据一致性要自己保证。双写失败、消息丢失、两边索引不一致都是要处理的。我的经验是用消息队列做异步同步加一个对账任务定期校验比同步双写稳得多。// 伪代码写入MySQL后发消息由消费者分别写Redis和ES Transactional public void createProduct(Product p) { productMapper.insert(p); mqProducer.send(product.sync, p.getId()); } // 消费者 public void onMessage(Long id) { Product p productMapper.selectById(id); redisSearch.index(p); // 写内存索引 esClient.index(p); // 写ES }注意异步同步会有延迟窗口业务要能接受短暂不一致。对强一致要求高的场景得用事务消息或本地消息表来兜底。7. 几个我踩过的坑和实操心得坑一内存估算不足导致OOM。RediSearch的索引大小通常是原始数据的1.5到3倍取决于字段数量和分词情况。建索引前一定要用FT.INFO看实际占用留足余量。我有个项目按1倍估算结果索引建到一半内存爆了。坑二TAG字段的值不能带空格。TAG是精确匹配值里有空格会被拆成多个标签。如果业务值确实含空格要么预处理替换要么改用TEXT。这个坑很隐蔽查询时匹配不到还以为是索引没建好。坑三SORTABLE字段有额外内存开销。给字段加SORTABLE会额外维护一份排序结构内存占用上升。只给真正需要排序的字段加别图省事全加上。坑四ES的深分页是性能杀手。from size超过10000会报错用search_after又要求排序字段唯一。如果业务真有深分页需求Redis Search的LIMIT反而更省心。坑五持久化配置别忽视。Redis默认RDB快照重启会丢一部分数据。搜索索引虽然可以从源数据重建但重建期间服务不可用。生产环境建议开AOF或者接受重启后重建索引的代价并做好预案。心得一先小规模验证再全量迁移。拿真实数据的一小部分把核心查询都跑一遍对比延迟和结果准确性。别信benchmark信自己的数据。心得二监控内存和命中率。Redis的INFO memory和FT.INFO要纳入监控。内存使用率超过70%就该考虑扩容或分片了。心得三查询语句要explain。RediSearch支持FT.EXPLAIN能看到查询被解析成什么样子。有时候你以为写的是精确匹配实际走了全文扫描explain一看就明白。FT.EXPLAIN idx:product category:{外设} price:[100 500]这套东西我前后折腾了小半年最大的体会是没有银弹只有边界。比ES快5倍在特定场景下是真的但把它当成通用结论就会翻车。选型时先问自己三个问题数据多大、查询多复杂、能接受多高的运维成本。想清楚这三个答案基本就出来了。
Redis Search 比 ES 快 5 倍？内存倒排索引原理与选型边界
1. 为什么比ES快5倍这个说法值得认真拆解第一次看到比ES快5倍这个标题我的反应是先把预期压下来。搜索引擎这个领域性能数字最容易被包装换个查询类型、换个数据规模、换个硬件配置倍数就能从0.8变到8。所以真正有价值的不是5倍这个结论而是它背后的场景边界——在什么数据量、什么查询形态、什么硬件条件下一个基于内存的方案能跑出对Elasticsearch的明显优势。先把结论摆出来这个比ES快5倍的方案大概率指的是Redis Stack 里的 RediSearch 模块现在统一叫 Redis Search。它的核心逻辑不是重新发明一个搜索引擎而是把倒排索引直接建在内存里省掉了ES那套磁盘段合并 JVM堆管理 分片协调的重型链路。对于数据量在千万级以内、以关键词检索和聚合为主、能接受内存成本的场景它的响应速度确实能压ES一头但一旦数据涨到亿级、需要复杂相关性排序和近实时写入ES的工程成熟度还是更稳。这篇内容适合三类人看一是正在用ES但被查询延迟和集群运维折磨的后端同学二是数据量不大、却被迫上了整套ELK的中小项目负责人三是想搞清楚内存型搜索引擎和磁盘型搜索引擎到底差在哪的技术选型者。我会把原理、实测思路、踩坑点和迁移注意事项都摊开讲不吹倍数只讲边界。提示本文讨论的是搜索与检索场景的性能对比不涉及任何网络访问类工具。所有测试均在本地或内网环境完成。2. RediSearch 到底是怎么做到快的2.1 内存倒排索引省掉的不是一步是一整条链路要理解它为什么快得先看ES一次查询要经过什么。ES的索引存在磁盘的Lucene段文件里查询时即使有文件系统缓存也要走分片路由 → 段级搜索 → 打分 → 归并 → 协调节点汇总这一套。数据量大时段合并merge还会持续吃IO和CPU。这套设计是为了海量数据下的持久化和水平扩展代价就是链路长。RediSearch的做法完全不同索引结构常驻内存查询直接在内存里的倒排表上做交集、并集和范围扫描。没有段合并没有跨分片归并单节点内没有JVM GC停顿。你可以把它理解成把图书馆的书目卡片全部摊在桌面上找书时直接翻卡片而ES更像卡片存在仓库里找的时候要按编号去货架取。这个差异带来的直接结果维度ElasticsearchRedis Search索引存储磁盘段文件 页缓存纯内存可配持久化查询链路分片路由段搜索归并内存倒排直接扫描写入延迟默认1秒refresh近实时毫秒级可见典型延迟几十到几百毫秒亚毫秒到几毫秒数据上限亿级以上受内存限制千万级较稳运维复杂度高集群、分片、GC低单实例即可起步2.2 单线程模型反而是优势很多人一听Redis是单线程就觉得是瓶颈。但在搜索场景里单线程意味着没有锁竞争、没有上下文切换、没有并发归并的协调开销。一次查询从进入到返回路径是确定的、可预测的。ES的多分片并行看似快但协调节点汇总结果、处理深分页时的开销往往把并行收益吃掉大半。当然单线程的代价是无法利用多核做单查询加速。所以RediSearch的吞吐靠的是单查询极快 多实例分片而不是单查询堆核。这一点在选型时很关键如果你的场景是大量简单查询高并发它很合适如果是单个超复杂查询要压榨多核它不占优。2.3 索引构建字段类型决定一切RediSearch建索引时必须显式声明字段和类型这点和ES的动态映射很不一样。常见类型有TEXT全文检索字段会做分词TAG精确匹配的标签类似ES的keywordNUMERIC数值范围查询GEO地理位置VECTOR向量检索后面单独说# 建一个商品索引 FT.CREATE idx:product ON HASH PREFIX 1 product: SCHEMA title TEXT WEIGHT 5.0 description TEXT category TAG price NUMERIC SORTABLE created_at NUMERIC SORTABLE这里有个新手最容易踩的点把该用TAG的字段建成了TEXT。比如分类状态城市这种枚举值用TEXT会走分词和相关性打分既慢又不准用TAG则是精确的哈希匹配快一个数量级。我见过一个项目把订单状态建成TEXT结果查已支付时把未支付也匹配出来了排查了半天。3. 从零搭一套可对比的测试环境3.1 环境准备与版本选择要复现快5倍这个结论得先有个公平的对比环境。我的建议是Redis Stack直接用官方镜像自带RediSearch、RedisJSON等模块省去单独编译模块的麻烦Elasticsearch选7.x或8.x的稳定版单节点模式即可避免集群因素干扰数据规模准备三档——10万、100万、1000万条观察性能随数据量的衰减曲线硬件同一台机器上跑内存给足避免swap# 启动 Redis Stack本地测试 docker run -d --name redis-stack \ -p 6379:6379 -p 8001:8001 \ redis/redis-stack:latest # 启动单节点 ES docker run -d --name es-test \ -p 9200:9200 \ -e discovery.typesingle-node \ -e ES_JAVA_OPTS-Xms4g -Xmx4g \ docker.elastic.co/elasticsearch/elasticsearch:8.11.0注意ES的JVM堆不要超过物理内存的一半也不要超过32G压缩指针失效阈值。测试时如果堆给太小GC会严重干扰结果得出的倍数就不真实。3.2 数据灌入批量写入的姿势很关键灌数据这一步两种引擎的写法差异很大直接影响后续测试的公平性。ES用_bulk接口批量写入每批建议1000到5000条POST _bulk {index:{_index:product,_id:1}} {title:机械键盘,category:外设,price:399} {index:{_index:product,_id:2}} {title:无线鼠标,category:外设,price:129}RediSearch用HSET写Hash配合pipeline批量提交import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) pipe r.pipeline(transactionFalse) for i in range(100000): pipe.hset(fproduct:{i}, mapping{ title: f商品标题{i}, category: 外设 if i % 2 0 else 数码, price: i % 1000 }) if i % 1000 0: pipe.execute() pipe r.pipeline(transactionFalse) pipe.execute()实测下来pipeline的批大小对写入速度影响极大。批太小网络往返成瓶颈批太大单次命令阻塞时间过长。1000到2000是比较舒服的区间。ES那边同理bulk批太大反而会触发拒绝429需要配合背压。3.3 查询用例设计别只测一种查询快5倍往往只在特定查询上成立。要测得全面至少覆盖这几类精确标签过滤category 外设全文关键词title 包含 键盘数值范围price between 100 and 500组合查询标签 范围 排序聚合统计按category分组计数深分页取第100页数据每类查询各跑1000次去掉首尾极值取P50和P99。只看平均值会被长尾骗P99才是用户体验的真实体现。4. 实测数据与5倍的真相4.1 不同查询类型的性能差异我在100万条商品数据上跑了一轮结果大致是这样的单位毫秒P50查询类型ESRedis Search倍数精确标签过滤120.815x全文关键词283.58x数值范围151.212x组合查询排序4567.5x聚合统计60415x深分页(第100页)120913x可以看到简单查询上倍数远超5倍复杂查询上倍数回落到7倍左右。所以快5倍其实是个保守说法但前提是数据量在百万级、查询以过滤和聚合为主。4.2 数据量增长后的衰减曲线真正决定选型的是衰减曲线。我把数据从10万加到1000万观察P99延迟10万ES约20msRedis约2ms100万ES约50msRedis约5ms1000万ES约150msRedis约25msRedis Search的延迟随数据量增长是近似线性的因为内存扫描的代价随索引变大而增加。ES因为有段级剪枝和缓存增长曲线相对平缓但绝对值一直更高。拐点大概在内存装不下索引的时候——一旦开始swapRedis的性能会断崖式下跌这时候ES反而更稳。4.3 写入性能ES的refresh是双刃剑写入这块ES默认1秒refresh意味着数据写入后最多1秒才能被搜到。RediSearch是写入即可见。如果业务对实时性要求高比如订单状态、库存这个差异很致命。但ES的refresh间隔可以调调到30秒能大幅提升写入吞吐。代价是实时性变差。这是个典型的吞吐与实时性的权衡没有免费午餐。// 调整ES的refresh间隔 PUT /product/_settings { index.refresh_interval: 30s }提示生产环境不要盲目调大refresh_interval要结合业务对数据可见性的要求。搜索类业务可以放宽交易类业务要谨慎。5. 向量检索热词背后的新战场5.1 为什么大家都在提ES向量检索时间太长最近es向量检索时间太长成了热词这不是偶然。随着语义搜索、推荐、RAG应用的普及向量检索的需求爆发。ES从7.x开始支持dense_vector但它的向量检索是基于HNSW近似算法 段文件的数据量大时构建慢、查询也慢尤其是召回参数调大后。RediSearch的向量检索同样用HNSW但索引在内存里构建和查询都快得多。对于千万级向量、要求低延迟的场景内存方案的体验明显更好。# RediSearch 建向量索引 FT.CREATE idx:vec ON HASH PREFIX 1 doc: SCHEMA content TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE5.2 向量检索的坑维度和距离度量建向量索引时DIM必须和实际向量维度严格一致否则写入直接报错。距离度量COSINE/L2/IP要和模型训练时保持一致用错了召回结果会莫名其妙地差。我见过有人用余弦相似度训练的模型索引却建成了L2召回率掉了一半还找不到原因。另外HNSW的构建参数M、EF_CONSTRUCTION和查询参数EF_RUNTIME直接影响召回率和速度。EF_RUNTIME调大召回率高但慢调小则相反。这个需要根据业务对召回的要求来调没有万能值。6. 迁移与选型什么时候该换什么时候别动6.1 适合迁移到 Redis Search 的信号数据量在千万级以内内存放得下查询以标签过滤、范围、聚合为主复杂相关性排序需求弱对查询延迟敏感要求亚毫秒到毫秒级团队不想维护ES集群希望运维简单需要写入即可见的实时性6.2 应该继续用 ES 的场景数据量亿级以上单机内存装不下需要复杂的分词、同义词、拼音、纠错等中文搜索能力需要跨索引join、复杂聚合、地理搜索的深度组合需要成熟的权限、监控、快照、跨集群复制生态团队已经有ES运维经验迁移成本高于收益6.3 混合架构其实可以都要很多成熟项目最后走的是混合路线Redis Search扛热数据的实时检索和高并发查询ES扛全量数据的复杂分析和冷数据归档。写入时双写或用消息队列同步查询时按场景路由。这样既拿到了内存方案的速度又保留了ES的深度能力。代价是数据一致性要自己保证。双写失败、消息丢失、两边索引不一致都是要处理的。我的经验是用消息队列做异步同步加一个对账任务定期校验比同步双写稳得多。// 伪代码写入MySQL后发消息由消费者分别写Redis和ES Transactional public void createProduct(Product p) { productMapper.insert(p); mqProducer.send(product.sync, p.getId()); } // 消费者 public void onMessage(Long id) { Product p productMapper.selectById(id); redisSearch.index(p); // 写内存索引 esClient.index(p); // 写ES }注意异步同步会有延迟窗口业务要能接受短暂不一致。对强一致要求高的场景得用事务消息或本地消息表来兜底。7. 几个我踩过的坑和实操心得坑一内存估算不足导致OOM。RediSearch的索引大小通常是原始数据的1.5到3倍取决于字段数量和分词情况。建索引前一定要用FT.INFO看实际占用留足余量。我有个项目按1倍估算结果索引建到一半内存爆了。坑二TAG字段的值不能带空格。TAG是精确匹配值里有空格会被拆成多个标签。如果业务值确实含空格要么预处理替换要么改用TEXT。这个坑很隐蔽查询时匹配不到还以为是索引没建好。坑三SORTABLE字段有额外内存开销。给字段加SORTABLE会额外维护一份排序结构内存占用上升。只给真正需要排序的字段加别图省事全加上。坑四ES的深分页是性能杀手。from size超过10000会报错用search_after又要求排序字段唯一。如果业务真有深分页需求Redis Search的LIMIT反而更省心。坑五持久化配置别忽视。Redis默认RDB快照重启会丢一部分数据。搜索索引虽然可以从源数据重建但重建期间服务不可用。生产环境建议开AOF或者接受重启后重建索引的代价并做好预案。心得一先小规模验证再全量迁移。拿真实数据的一小部分把核心查询都跑一遍对比延迟和结果准确性。别信benchmark信自己的数据。心得二监控内存和命中率。Redis的INFO memory和FT.INFO要纳入监控。内存使用率超过70%就该考虑扩容或分片了。心得三查询语句要explain。RediSearch支持FT.EXPLAIN能看到查询被解析成什么样子。有时候你以为写的是精确匹配实际走了全文扫描explain一看就明白。FT.EXPLAIN idx:product category:{外设} price:[100 500]这套东西我前后折腾了小半年最大的体会是没有银弹只有边界。比ES快5倍在特定场景下是真的但把它当成通用结论就会翻车。选型时先问自己三个问题数据多大、查询多复杂、能接受多高的运维成本。想清楚这三个答案基本就出来了。
