Redis7系列：百万数据级Redis Search 吊打 ElasticSearch

SimonKing
1,224 阅读7分钟

1、Redis Search深度解析

1.1 核心特性

Redis Search是基于Redis的全文搜索引擎模块（RediSearch），具备以下核心能力：

  • 实时索引写入与查询（微秒级延迟）
  • 支持文本、数值、地理空间等多类型数据
  • 内置中文分词支持（需加载Friso分词器）
  • 丰富的聚合分析功能
  • 与Redis数据结构无缝集成

1.2 颠覆认知

Redis Search 的「核弹级」实战手册

你以为 Redis 只能做缓存？这5个黑科技直接封神！

  • 0.1ms 极限响应：实测百万级数据查询比 MySQL 快 1000 倍
  • 中文分词暴击：电商搜索"苹果手机"，竟自动识别「新品/二手/5G」标签（附分词配置秘籍）
  • 内存杀招：1亿数据仅占 12GB 内存，某大厂用它替代 ES 节省 80% 服务器成本
  • 骚操作预警：用 GEO 索引实现「附近的人」功能，代码量减少 90%
  • 隐藏大招：结合 RedisJSON 玩转嵌套文档搜索（附避坑指南）

1.3 手撕代码现场

程序员最爱的「暴力」命令行

数据准备：

{
    "name": "张三",
    "age": 15,
    "job": "java",
    "city": "上海市"
},
{
    "name": "李四",
    "age": 20,
    "job": "c",
    "city": "杭州市"
},
{
    "name": "王五",
    "age": 30,
    "job": "python,java",
    "city": "杭州市"
}

创建索引的命令：

#命令
FT.CREATE index 
  [ON HASH | JSON] 
  [PREFIX count prefix [prefix ...]] 
  [FILTER {filter}]
  [LANGUAGE default_lang] 
  [LANGUAGE_FIELD lang_attribute] 
  [SCORE default_score] 
  [SCORE_FIELD score_attribute] 
  [PAYLOAD_FIELD payload_attribute] 
  [MAXTEXTFIELDS] 
  [TEMPORARY seconds] 
  [NOOFFSETS] 
  [NOHL] 
  [NOFIELDS] 
  [NOFREQS] 
  [STOPWORDS count [stopword ...]] 
  [SKIPINITIALSCAN]
  SCHEMA field_name [AS alias] TEXT | TAG | NUMERIC | GEO | VECTOR | GEOSHAPE [ SORTABLE [UNF]] 
  [NOINDEX] [ field_name [AS alias] TEXT | TAG | NUMERIC | GEO | VECTOR | GEOSHAPE [ SORTABLE [UNF]] [NOINDEX] ...]

主要参数说明：

  • index ：索引的名称
  • [ON HASH | JSON] ：支持的数据类型Hash、JSON
  • [PREFIX count prefix [prefix ...]] ：指定Key值前缀的个数，并罗列前缀。罗列的前缀个数要和前面的数据匹配。
  • SCHEMA：关键字，后面接要创建索引的字段
  • TEXT | TAG | NUMERIC | GEO | VECTOR ：字段的类型
    • TEXT ：字符串类型
    • TAG：标签，可理解为字典类型
    • NUMERIC ：数字类型
    • GEO ：地理位置
    • VECTOR：向量

创建索引：

针对key值以search_data 开头的所有数据，创建hash:search:index索引。

# 可执行命令
FT.CREATE hash:search:index ON HASH PREFIX 1 'search_data' SCHEMA name TEXT WEIGHT 10.0 age NUMERIC SORTABLE job TAG city TEXT


# 参数说明
FT.CREATE 
	# 索引名称
    hash:search:index 
    # 索引的数据类型：支持hash |json
	ON HASH 
	# 针对创建索引Redis中key的前缀数量以及罗列
	PREFIX 1 'search_data' 
	# 关键词：后面接创建索引的字段
	SCHEMA 
		# 指定数据类型为text， 权重为10.默认是1
		name TEXT WEIGHT 10.0 
		# 指定数据类型为numeric，可以排序
		age NUMERIC SORTABLE 
		# 指定数据类型为tag
		job type TAG 
		# 指定数据类型为Text
		city TEXT

查询：

查看所有数据，并按照年龄倒序排列

> FT.SEARCH hash:search:index * sortby age desc
1) "3"
2) "search_data_03"
3) 1) "age"
   2) "30"
   3) "name"
   4) "\xe7\x8e\x8b\xe4\xba\x94"
   5) "job"
   6) "python,java"
   7) "city"
   8) "\xe6\x9d\xad\xe5\xb7\x9e\xe5\xb8\x82"
4) "search_data_02"
5) 1) "age"
   2) "20"
   3) "name"
   4) "\xe6\x9d\x8e\xe5\x9b\x9b"
   5) "job"
   6) "c"
   7) "city"
   8) "\xe8\x8b\x8f\xe5\xb7\x9e\xe5\xb8\x82"
6) "search_data"
7) 1) "age"
   2) "15"
   3) "name"
   4) "\xe5\xbc\xa0\xe4\xb8\x89"
   5) "job"
   6) "java"
   7) "city"
   8) "\xe4\xb8\x8a\xe6\xb5\xb7\xe5\xb8\x82"

查看【name=李四】的数据

> FT.SEARCH hash:search:index "@name:李四"
1) "1"
2) "search_data_02"
3) 1) "name"
   2) "\xe6\x9d\x8e\xe5\x9b\x9b"
   3) "age"
   4) "20"
   5) "job"
   6) "c"
   7) "city"
   8) "\xe8\x8b\x8f\xe5\xb7\x9e\xe5\xb8\x82"

查看年龄20岁及以上，job为java的数据

> FT.SEARCH hash:search:index "@age:[20 +inf] @job:{java}"
1) "1"
2) "search_data_03"
3) 1) "name"
   2) "\xe7\x8e\x8b\xe4\xba\x94"
   3) "age"
   4) "30"
   5) "job"
   6) "python,java"
   7) "city"
   8) "\xe6\x9d\xad\xe5\xb7\x9e\xe5\xb8\x82"

基于JSON数据的注意事项

上述案例采用了Hash的数据结构，JSON数据结构要求会严格一点，必须为{"key": value}的格式，否则获取的时候会有困难或者无法获取

1.4 血赚案例

这些公司靠 Redis Search 省了一套房

场景某音玩法结果
直播弹幕实时检索关键词屏蔽+用户画像过滤审核效率提升 300%
证券行情闪电查询千档盘口+分时图混合查询行情延迟从 50ms 降至 0.5ms
物联网设备预警10万+/秒传感器数据实时分析服务器成本减少 60%

2、ElasticSearch 的「死亡痛点」大曝光

ElasticSearch 在倒排索引领域已经取得优异的成绩，更适合PB级的数据。但是尺有所短、寸有所长，并不是所有场景都可以使用其解决问题。

2.1 核心优势

  • 分布式架构：原生支持PB级数据水平扩展
  • 分词能力：内置ICU、IK等专业分词器，支持同义词、拼音等高级功能
  • 数据持久化：基于Lucene的段存储机制保障数据可靠性
  • 生态体系：完善的ELK技术栈（Kibana/Logstash/Beats）
  • 大数据之神：PB级数据分布式处理无压力

2.2 局限性

  • 资源消耗：内存需求高（建议配置堆内存30GB+）
  • 运维复杂度：需要专业集群管理（分片分配、版本升级等）
  • 实时性：默认近实时（1秒延迟）
  • 学习成本：DSL查询语法较复杂

2.3 痛点场景

❌ 这些场景用 ES 就是找死！

  • 高频更新场景：某游戏排行榜每分钟更新 10 万次，ES 集群直接崩盘
  • 极致延迟要求：金融订单系统要求 <1ms 响应，ES 跪地求饶
  • 小型数据集合：10GB 数据硬上 ES，维护成本比开发成本还高

2.4 血泪教训

💣 ES 七宗罪（附血泪教训）

  1. 内存吸血鬼：32GB 机器实际可用不到 10GB（JVM 堆内存魔咒）
  2. 分片地狱：某公司误设 1000 分片，查询直接超时 30 秒
  3. 版本升级坑：从 7.x 升 8.x 踩坑 20+ 小时（兼容性列表比代码还长）
  4. 冷启动暴击：10 亿数据初始化索引要 8 小时（Redis Search 只要 40 分钟）
  5. 昂贵的专家：招一个 ES 工程师的钱够买 3 台服务器

3、Redis Search优势

  • 极致速度：内存计算带来碾压级性能，微秒级响应
  • 吞吐量：百万级写入12万/秒（单线程）左右
  • 实时王者：写入即查无延迟，适合金融/社交等场景
  • 成本杀手：节省50%+服务器资源
  • 高频更新：基于内存高频更新，CPU的占用率更低
  • 资源消耗低：轻量级，1亿数据仅需数GB内存，单节点可运行

4、Redis Search VS ElasticSearch

对比维度Redis SearchElasticSearch
实时性⚡ 微秒级延迟：数据写入即可查询，无需刷新间隔⏳ 近实时（约1秒延迟）：依赖索引刷新机制
内存性能🚀 全内存存储：读写速度极快，适合高频实时场景📁 磁盘+内存缓存：依赖文件系统缓存，速度较慢
资源消耗💡 轻量级：1亿数据仅需数GB内存，单节点可运行💸 高资源需求：需要大内存+SSD，集群运维成本高
架构复杂度🛠️ 零依赖：无需额外组件，与Redis生态无缝集成🔗 依赖集群：需部署多个节点+分片管理，复杂度高
混合查询能力🔍 原生支持：文本+数值+地理空间查询一站式解决🧩 需组合方案：复杂查询需结合其他工具（如Kibana）

5、选型建议

评估维度Redis SearchElasticSearch
延迟要求<1ms10-100ms
数据规模<1TB>1TB
查询复杂度中等（支持聚合但不支持嵌套查询）高（支持管道聚合、脚本查询等）
运维成本低（单节点）高（需集群管理）
实时性要求极高（金融交易、游戏场景）高（日志分析、监控系统）

实施建议 ：

  • 实时优先场景：选Redis Search（如在线客服系统）
  • 大数据分析：选ElasticSearch（如日志分析平台）
  • 混合架构：用Redis Search作缓存层，ElasticSearch作持久层
  • 轻量级应用：Redis Search单机版可降低运维复杂度

6、未来预言

Redis Search 3.0 王炸功能

  • 支持向量搜索（AI场景）
  • 增强的JSON路径查询
  • 分布式集群方案改进

ElasticSearch 的绝地反击

  • 增强自然语言处理能力
  • 优化稀疏数据存储效率
  • 强化安全管控体系
avatar
文章
阅读
粉丝