Redis Search系列 - 第六讲 基准测试 - Redis Search VS. MongoDB VS. ElasticSearch

目录

    • 一、引言
    • [二、Redis Search 2.x版本的性能提升](#二、Redis Search 2.x版本的性能提升)
    • [三、Redis Search VS. MongoDB VS. ElasticSearch](#三、Redis Search VS. MongoDB VS. ElasticSearch)
      • [3.1 测试环境](#3.1 测试环境)
      • [3.2 100%写 - 基准测试](#3.2 100%写 - 基准测试)
      • [3.3 100%读 - 基准测试](#3.3 100%读 - 基准测试)
      • [3.4 混合读/写/搜索 - 基准测试](#3.4 混合读/写/搜索 - 基准测试)
      • [2.5 搜索延迟分析](#2.5 搜索延迟分析)
      • [3.6 读延迟分析](#3.6 读延迟分析)
      • [3.7 写延迟分析](#3.7 写延迟分析)
      • [3.8 Redis Search VS. ElasticSearch](#3.8 Redis Search VS. ElasticSearch)
      • [3.9 总结](#3.9 总结)

一、引言

本基准测试参考自Redis官方博客,本文仅做汇总说明,具体原文可参见:
https://redis.io/blog/redisjson-public-preview-performance-benchmarking/

索引了590万篇维基百科摘要,并运行了一个全文搜索查询面板(详情参见这里),不难发现:

  • Redis Search 2.2(结合Redis JSON)比之前的版本快1.7倍,且每个新版本都在持续优化
  • 从v2.0升级到v2.2,将得到更快的写/读/搜索

具体统计结果参见下面2张图:

3.1 测试环境

基础环境说明

  • 均采用m5d.8xlarge虚拟机,带有本地ssd,
  • 每组压测均由四个虚拟机组成:一个客户端 + 三个数据库服务器。
  • 基准测试客户机和数据库服务器都运行在单独的m5d.8xlarge实例,并放置在最佳网络条件下,这些实例均位于同一可用区内,实现了稳态分析所需的低延迟和稳定的网络性能。

测试集群说明

存储 集群组成 索引
MongoDB 5.0.3 三成员副本集(Primary-Secondary-Secondary) 在搜索字段上创建了文本索引(TEXT),以支持文本搜索查询
ElasticSearch 7.15 15个分片设置,启用查询缓存, 使用RAID 0阵列的2个本地NVMe SSD 预先创建索引
Redis Search 2.2 Redis JSON 2.0 OSS Redis Cluster v6.2.6, 27个分片均匀分布在三个节点上, 加载了Redis Search 2.2和Redis JSON 2.0 OSS模块 预先创建索引

测试框架
https://github.com/RedisJSON/RedisJSON/tree/master/tests/benchmarks
https://github.com/RediSearch/ftsb/blob/master/docs/enwiki-abstract-benchmark/description.md
https://github.com/RediSearch/ftsb/blob/master/docs/nyc_taxis-benchmark/description.md
https://github.com/brianfrankcooper/YCSB/pull/1577

3.2 100%写 - 基准测试

结合 延迟吞吐量 的综合提升:

  • Redis JSON比Mongodb快5.4倍
  • 比Elastic Search在单独写方面快200倍
  • 99%的Redis请求在不到1.5ms的时间内完成。

注:

Redis JSON是三种方案中唯一在每次写入时自动更新索引的解决方案,

其他均是异步更新索引,需要等待一段时间后才能检索到数据

具体统计结果如下图:

3.3 100%读 - 基准测试

注:

此处的读可以理解为根据key直接读取文档,而不是执行全文检索

结合 延迟吞吐量 的综合提升:

  • Redis JSON比MongoDB快12.7倍
  • 比Elastic Search快500倍

3.4 混合读/写/搜索 - 基准测试

实际应用程序的工作负载几乎总是混合了读、写和搜索查询。因此,当混合工作负载接近饱和时,理解由此产生的混合工作负载吞吐量曲线就更加重要了。作为起点,我们考虑了 65%搜索35%读取的场景,这代表了一个常见的现实场景,在这个场景中,我们执行的搜索/查询比直接读取更多。65%的搜索35%的读取0%的更新 的初始组合也使ElasticSearch和Redis JSON的吞吐量相等,后续不断切换YCSB工作负载中搜索/读取/更新之间的比率以匹配测试需求。在每个测试变量中,我们都添加了10%的写操作,并以相同的比例降低了搜索和读取百分比。这些测试变化的目标是了解每个产品如何处理数据的实时更新,我们认为这是事实上的架构目标,即 写入立即提交到索引,读取总是最新的

搜索场景

分页查询,双字全文检索,结果按数字属性排序

a paginated two-word query match, sorted by a numeric field

结合对比结果如下:

  • Redis JSON: 持续更新数据并增加写入比例不会影响读取或搜索性能,反而会提高整体吞吐量。
  • ElasticSearch:随着更新比例从0%增加到50%,吞吐量(Ops/sec)从10k下降到2.1k(降低5倍),性能受到显著影响,读取和搜索速度变慢。
  • MongoDB:搜索性能比Redis JSON和ElasticSearch慢两个数量级,最大吞吐量为424 Ops/sec,而Redis JSON为16k Ops/sec。
  • 综合所有混合负载测试
    • Redis JSON在混合工作负载下的吞吐量比MongoDB高50.8倍,比ElasticSearch高7倍。
    • Redis JSON的操作延迟比MongoDB低91倍,比ElasticSearch低23.7倍。
  • 总结: Redis Search几乎不受更新比例影响,吞吐量稳步提升,三者中性能最高;ElasticSearch受到更新比例的显著影响,随着更新比例的提高,读取和搜索速度变慢;MongoDB性能整体最差(比RedisSearch、ElasticSearch慢2个数据级)。

具体测试统计结果如下图:

2.5 搜索延迟分析

注: 延迟即耗时,即请求平均耗时

在下图中,显示了搜索测试吞吐量为250ops/sec时从p0到p9999的延迟百分位数:

  • Mongodb DB的表现都远远落后于ElasticSearch和Redis JSON。
  • 对比ElasticSearch与Redis JSON,很明显ElasticSearch容易受到更高延迟的影响,这很可能是由垃圾收集(GC)触发或搜索查询缓存丢失引起的。
  • Redis JSON的p99低于2.61ms,而Elastic Search的p99则达到了10.28ms。

3.6 读延迟分析

在下图中,显示了读测试吞吐量为250ops/sec时从p0到p9999的延迟百分位数:

  • Redis JSON是在所有分析的延迟百分位数中保持亚毫秒级延迟的唯一解决方案。
  • 在p99时,Redis JSON的延迟为0.23ms,其次是MongoDB的5.01ms, ElasticSearch的10.49ms。

3.7 写延迟分析

在下图中,显示了写测试吞吐量为250ops/sec时从p0到p9999的延迟百分位数:

  • MongoDB和Redis JSON即使在p99时也保持着亚毫秒级的延迟。
  • Elastic Search显示出很高的尾部延迟(>10ms),很可能是由于与Elastic Search的搜索峰值相同的原因(GC)。

只关注ElasticSearch和Redis JSON,同时保持6K ops/sec的可持续负载,我们可以观察到:

  • 在读和更新(写)时
    • ElasticSearch和Redis JSON(更稳定的方案)的读取和更新模式仍然跟之前250 ops/sec时的压测差不多。
    • 在读时,Redis JSON的p99为3ms,而ElasticSerach的p99为162ms。
    • 在更新时,Redis JSON的p99为3ms,而ElasticSearch的p99为167ms。
  • 在搜索时
    • Elastic Search和Redis JSON以一位数的p50延迟开始(Redis JSON的p50延迟为1.13ms,而Elastic Search的p50延迟为2.79ms)
    • 在较高的百分位数上,Elastic Search付出了GC触发和查询缓存丢失的代价,这在>= p90百分位数上可以清楚地看到。
    • Redis JSON(更高效)的p99保持在33ms以下,而在Elastic Search上,p99保持在163ms,是前者的5倍。

具体测试结果参见下图:

3.9 总结

测试项 RedisSearch ElasticSearch MongoDB 结果对比
100%写 吞吐量:69672/秒 平均耗时:0.341毫秒 吞吐量:7911/秒 平均耗时:7.818毫秒 吞吐量:37985/秒 平均耗时:1.001毫秒 * Redis JSON比MongoDB快5.4倍 * 比ElasticSearch在单独写方面快200倍 * 99%的Redis请求在不到1.5ms的时间内完成
100%读 吞吐量:178364/秒 平均耗时:0.172毫秒 吞吐量:11281/秒 平均耗时:5.578毫秒 吞吐量:62933/秒 平均耗时:0.768毫秒 * Redis JSON比MongoDB快12.7倍 * 比ElasticSearch快500倍
混合读/写/搜索 持续更新数据并增加写入比例不会影响读取或搜索性能,反而会提高整体吞吐量(从10k到16k)。 随着更新比例从0%增加到50%,吞吐量(Ops/sec)从10k下降到2.1k(降低5倍),性能受到显著影响,读取和搜索速度变慢。 搜索性能比Redis JSON和ElasticSearch慢两个数量级,最大吞吐量为424 Ops/sec,而Redis JSON为16k Ops/sec。 * Redis JSON在混合工作负载下的吞吐量比MongoDB高50.8倍,比ElasticSearch高7倍。 * Redis JSON的操作延迟比MongoDB低91倍,比ElasticSearch低23.7倍。 * Redis Search几乎不受更新比例影响,吞吐量稳步提升,三者中性能最高;ElasticSearch受到更新比例的显著影响,随着更新比例的提高,读取和搜索速度变慢;MongoDB性能整体最差(比RedisSearch、ElasticSearch慢2个数量级)。

优劣势对比:

  • RedisSearch 的优势在于其在所有测试项中都表现出色,具有最高的吞吐量和最低的延迟,几乎不受更新比例的影响。
  • ElasticSearch 的劣势在于其性能随着更新比例的增加显著下降,读写操作的延迟较高。
  • MongoDB 的劣势在于其整体性能最差,无论是读、写还是混合操作,吞吐量和延迟都远不及RedisSearch和ElasticSearch。
相关推荐
hongkid1 小时前
MongoDB常用操作
数据库·mongodb
执键行天涯2 小时前
【工具使用】VSCode如何将本地项目关联到远程的仓库 (vscode本地新项目与远程仓库建立链接)
ide·vscode·elasticsearch
尘佑不尘4 小时前
shodan5,参数使用,批量查找Mongodb未授权登录,jenkins批量挖掘
数据库·笔记·mongodb·web安全·jenkins·1024程序员节
再拼一次吧5 小时前
Elasticsearch
大数据·elasticsearch·搜索引擎
孟章豪5 小时前
从零开始:在 .NET 中构建高性能的 Redis 消息队列
redis·c#
隔窗听雨眠5 小时前
深入理解Redis的四种模式
java·redis·mybatis
北笙··5 小时前
Redis慢查询分析优化
数据库·redis·缓存
p-knowledge5 小时前
redis的三种客户端
数据库·redis·缓存
说淑人5 小时前
Redis & 线程控制 & 问题
redis·线程控制
积水成江5 小时前
Redis相关面试题
数据库·redis·缓存