目录
-
- 一、引言
- [二、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/
二、Redis Search 2.x版本的性能提升
索引了590万篇维基百科摘要，并运行了一个全文搜索查询面板（详情参见这里），不难发现：
- Redis Search 2.2（结合Redis JSON）比之前的版本快1.7倍，且每个新版本都在持续优化
- 从v2.0升级到v2.2，将得到更快的写/读/搜索
具体统计结果参见下面2张图：
三、Redis Search VS. MongoDB VS. ElasticSearch
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）。
3.8 Redis Search VS. ElasticSearch
只关注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。