官方Blog：RedisJSON: Public Preview & Performance Benchmarking

1. 写在前面

现在网上充斥着各种 “碾压ES和MongoDB的言论” ，所以就去了解了一下，具体看完大致有了一定理解。

如果单纯想做检索的话用 RedisJSON* 确实性能非常高（官方给的例子就是产品检索），毕竟这货可是基于内存呀，就这一特性不就轻轻松松的干掉一切？？但是如果是想要对数据进行统计分析之类的场景，最好还是使用 ES，ES 除了全文检索以外，还支持复杂数据分析，海量数据的近实时处理等操作。

官方的文档名词还是挺多的： RedisJSON 、RediSearch、RedisJSON* 。确实有种傻傻分不清楚的感觉。这三者具体分别是：

• RedisJSON： 是支持 JSON 存储的 Redis，Redis 的衍生模块。
• RediSearch：是提供查询、二级索引以及全文检索的 Redis，Redis 的衍生模块。
• RedisJSON*：其实还是 RedisJSON ，只不过是之前的 RedisJSON 与 RediSearch 的结合而诞生的新的 RedisJSON，一结合释放出爱情的火花然后就有了 * 星花。。。

想要体验 RedisJSON* 需要下面的三个条件：

- Redis 6.x or later
- RediSearch 2.2 or later (安装 RediSearch 模块)
- RediJSON 2.0 or later (安装 RedisJSON 模块)

【注】如果使用 Docker 的话，可以直接使用 Docker 上提供 RedisJSON 镜像，该镜像目前已经支持 RedisJSON* 。搜索是基于 RediSearch。

docker pull redislabs/rejson

铺垫结束，接下来直接看新 RedisJSON* 的强大之处。

2. 总体描述

2021年7月，我们推出了实时文档存储的私有预览版，具有由 RedisJSON 和 RediSearch 组合支持的原生索引、查询和全文搜索的功能。在私有预览期间，极大地提高了产品的性能和稳定性，简化了包装以方便入门，并增强了驱动程序支持。2021年11月16日，RedisJSON* （由 RediSearch 提供搜索支持）现已作为公共预览版提供，并且可在 Redis Cloud 使用。公共预览版意味着在有限的部署环境中一般可用（GA）质量代码。

RedisJSON* 是一个源可用的实时文档存储，允许使用动态分层的 JSON 文档模型构建现代应用程序。早期的客户已经开始在其数据堆栈的各种架构场景中使用它：作为缓存，作为加速热点数据的查询加速器以及作为主数据库。开发人员社区也越来越多的采用，仅在过去的3个月中，RedisJSON 和 RediSearch 加起来的 Docker 拉取镜像就达到了 100 万次。

Redis 连读第 5 年成为最受欢迎的数据库（来自 Stack Overflow 调查），并且我们希望 RedisJSON* 具有社区熟悉的 Redis 相同的简单性、可扩展性以及重要的速度，所以从一开始就有针对性的构建它。考虑到性能是 Redis 的关键优势，我们决定看看自己在之前的版本和市场上类似的产品中表现如何。为了对 RedisJSON、MongoDB 和 ElasticSearch 进行公平的比较，环境都采用了行业标准的 Yahoo! 云服务基准（YCSB）。

每个产品都有不同的架构和不同的功能集。对于给定的用例，一种产品可能比另一种更适合。在完全透明的情况下，MongoDB 和 ElasticSearch 存在的时间更长。对于使用哪种工具，取决于实际遇到的问题。在博客中，我们为 RedisJSON 的基准测试结果添加了大量的上下文，因此有许多变量可能与您实际的用例不同。我们发现：

• RediSearch 2.2 （为RedisJSON*提供搜索支持 ）比之前的版本快 1.7 倍。
• 在直接读、写和更新操作上，RedisJSON* 比 MongoDB 和 ElasticSearch 更快。 更具体地说，当结合吞吐量和延迟结果时，并考虑到进一步概述的基准测试细节的上下文： 对于隔离写入，RedisJSON* 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。
对于隔离读取，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 被以上。
• 在混合工作负载场景中，实时更新不会影响 RedisJSON* 的搜索和读取性能，而 ElasticSearch 会受到影响， RedisJSON* 支持的操作数/秒比 MongoDB 高约 50 倍，比 ElasticSearch 高 7 倍/秒。
RedisJSON* 的延迟比 MongoDB 低约 90 倍，比 ElasticSearch 低 23.7 倍。

此外，RedisJSON* 在负载下的读取、写入和搜索延迟在更高的百分比中远比 ElasticSearch 和 MongoDB 稳定。 当增加写入比率时，RedisJSON* 还能处理越来越高的整体吞吐量，而当写入比率增加时，ElasticSearch 会降低它可以处理的整体吞吐量。

2. 更快的查询引擎

如前所述，RediSearch 和 RedisJSON 的开发非常注重性能。 每次发布时，我们都希望确保您能体验到稳定、快速的产品。 无论我们是在寻找提高模块效率的空间还是进行性能回归调查，我们都依赖于一个完全自动化的框架来对存储库的每次提交运行端到端性能测试（点击了解详情），如果需要，我们通过附加遥测和分析工具/探测器进行性能调查。

这使我们能够以简洁有条理的方式在每个版本中不断提高性能。 特别是对于 RediSearch，在吞吐量和延迟都改进完成后，2.2 在写入数据和查询性能方面比 2.0 快 1.7 倍。

2.1 写入数据改进

接下来的两个图表显示了运行纽约市出租车基准测试的结果（详情）。 该基准测试测量了在加载约 1200 万份文档（2015 年在纽约的黄色出租车上执行的行程）时观察到的吞吐量（throughput）和延迟（latency）。

从这些图表中可以看出，每个新版本的 RediSearch 都具有显着的性能改进。

2.2 全文检索改进

为了评估搜索性能，我们索引了 590 万份维基百科摘要。 然后我们运行了一组全文搜索查询（详情），并观察其吞吐量（throughput）和延迟（latency）。

如上图所示，通过从 V2.0 迁移到 V2.2，将体验到更快的 写入/读取/搜索（延迟图表），在运行搜索和JSON 的相同硬件中获得更高的吞吐量。

3. RedisJSON* 与其他解决方案相比如何?

为了评估 RedisJSON 的性能，我们决定将其与 MongoDB 和 ElasticSearch 进行比较。在谈论文档存储时，这些解决方案通常会出现。它们既可在本地使用，也可在云中使用，提供专业支持，并致力于提供可扩展性和性能。当然，一切都取决于用例，在未来，我们计划将此基准扩展到其他供应商，提供与 Redis 相当的功能范围。让我们来看看我们的方法。

我们使用了完善的 YCSB，能够根据常见的工作负载评估不同的产品，测量由此产生的延迟/吞吐量曲线直到饱和。除了 CRUD YCSB 操作之外，我们还专门添加了两个关键词的搜索操作，以帮助开发人员、系统架构师和 DevOps 从业人员找到适合他们用例的最佳搜索引擎。生成的文档大小大约为 500 字节，每个解决方案都会创建一个二级索引，索引一个文本字段和一个数字字段。

3.1 测试基础环境

对于所有经过测试的解决方案，均使用最新的可用稳定 OSS 版本：MongoDB v5.0.3、ElasticSearch 7.15 和 RedisJSON* (RediSearch 2.2+RedisJSON 2.0)。

我们在通过我们的基准测试配置要求的 Amazon Web Services 实例上运行基准测试。这三种解决方案都是分布式数据库，与生产环境一样，都采用的是分布式的部署方式。这就是为什么所有产品都使用相同的通用 m5d.8xlarge VM 和本地 SSD，并且每个设置由四个 VM 组成：一个客户端 + 三个数据库服务器。基准测试客户端和数据库服务器都运行在处于最佳网络条件下的单独 m5d.8xlarge 实例上，这些实例在一个可用区内紧密排列，实现了稳态分析所需的低延迟和稳定的网络性能。

测试是在三个节点的集群上执行的，部署细节如下：

• MongoDB 5.0.3：三个副本集，一主两从（Primary-Secondary-Secondary）。副本用于增加读取容量并允许更低的延迟读取。为了支持对字符串内容的文本搜索查询，在搜索字段上创建了一个文本索引。
• ElasticSearch 7.15：设置了 15 个分片，启用查询缓存，以及 2 个基于 NVMe 的本地 SSD 的 RAID 0 阵列，以实现更高级别的文件系统相关弹性操作性能。我们为 Elastic 这 15 个分片提供了可实现的最佳性能结果。
• RedisJSON*：RediSearch 2.2 和 RedisJSON 2.0：OSS Redis Cluster v6.2.6，有 27 个分片，均匀分布在三个节点上，加载了 RediSearch 2.2 和 RedisJSON 2.0 OSS 模块。

除了这个主要的基准/性能分析场景之外，我们还在网络、内存、CPU 和 I/O 上运行基准基准测试，以了解底层网络和虚拟机特性。 在整个基准测试集期间，网络性能保持在带宽和 PPS 的测量限制以下，以产生平稳稳定的超低延迟网络传输（每个数据包 p99 < 100 micros）。

我们将从提供每个单独的操作性能 [100% 写入] 和 [100% 读取] 开始，并以一组混合工作负载结束以模拟现实生活中的应用程序场景。

3.2 100% 写入基准

如下图所示，该基准测试表明，RedisJSON* 的写入速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同时保持每个操作的亚毫秒级延迟。值得注意的是，99% 的 Redis 请求在不到 1.5 毫秒的时间内完成。

此外，RedisJSON* 是我们测试过的唯一一种在每次写入时自动更新其索引的解决方案。这意味着任何后续的搜索查询都会找到更新的文档。 ElasticSearch 没有这种细粒度的容量；它将写入的文档放在一个内部队列中，并且该队列由服务器（不受客户端控制）每 N 个文档或每 M 秒刷新一次。他们称这种方法为近实时 (NRT，Near Real Time)。 Apache Lucene 库（它实现了 ElasticSearch 的全文功能）旨在快速搜索，但索引过程复杂且繁重。如这些 WRITE 基准测试图表所示，由于这种 “设计” 的限制，ElasticSearch 付出了巨大的代价。

综合延迟和吞吐量两项测试结果后，在隔离写入场景中，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上。

3.3 100% 读取基准

与写入类似，我们可以观察到 Redis 是读取性能最好的，读取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同时在整个延迟范围内保持亚毫秒级延迟，如下表所示。

在综合延迟和吞吐量两项测试结果后，在隔离读取场景中，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。

3.4 混合 读/写/搜索 基准

实际应用程序工作负载几乎总是读取、写入和搜索查询的混合。因此，在接近饱和时了解由此产生的混合工作负载吞吐量曲线更为重要。

开始，我们考虑了 65% 搜索和 35% 读取的场景，这代表了一个常见的现实世界场景，在该场景中，我们执行的搜索/查询比直接读取更多。 65% 搜索、35% 读取和 0% 更新的初始组合的测试结果： ElasticSearch 和 RedisJSON* 的吞吐量差不多相等。尽管如此，YCSB 工作负载允许您 指定 搜索/读取/更新 之间的比率以满足您的要求。

“搜索性能”可以指不同类型的搜索，例如“匹配查询搜索”、“分面搜索”、“模糊搜索”等等。我们所做的最初向 YCSB 增加的搜索工作负载仅专注于“匹配查询搜索”，模仿分页的两词查询匹配，按数字字段排序。 “匹配查询搜索”是任何启用搜索功能的供应商进行搜索分析的起点，因此，每个支持 YCSB 的数据库/驱动程序都应该能够在其基准驱动程序上轻松启用此功能。

在每个测试用例中，我们添加了 10% 的写入，以按相同的比例混合和减少搜索和读取百分比。这些测试用例的目标是了解每个产品如何处理数据的实时更新，我们认为这是实际上的架构目标，即写入立即提交到索引，读取始终是最新的。

正如在图表中所展现的，在 RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能，整体吞吐量也在增加，没有任何影响。对数据产生的更新越多，对 ElasticSearch 性能的影响就越大，最终导致读取和搜索速度变慢。

从 ElasticSearch 从 0 到 50% 更新的 ops/sec 变化趋势中，我们注意到它在 0% 更新基准上以 10k Ops/sec 开始，然后逐渐被严重影响，在 50% 更新率基准上达到仅 2.1K ops/sec，减少了 5 倍的 ops/sec。

通过上述的基准测试中我们可以观察到，MongoDB 搜索性能比 RedisJSON* 和 ElasticSearch 慢两个数量级，MongoDB 的最大总吞吐量为 424 ops/sec，而使用 RedisJSON* 的最大总吞吐量为 16K ops/sec .

最后，对于混合工作负载，RedisJSON* 支持的操作数/秒（ops/sec）是 MongoDB 的 50.8 倍，是 ElasticSearch 的 7 倍。 如果我们将最后的分析集中在混合工作负载期间的每种操作类型延迟上，RedisJSON* 与 MongoDB 相比延迟降低了 91 倍，与 ElasticSearch 相比延迟降低了 23.7 倍。

3.5 每个解决方案完整的延迟分析

与测量每个解决方案饱和之前产生的吞吐量曲线类似，在所有解决方案通用的可持续负载下进行完整的延迟分析也很重要。 这将使您能够了解对于所有已发布操作在延迟方面最稳定的解决方案是什么，以及哪种解决方案不易受到应用程序逻辑引发的延迟峰值的影响（例如，弹性查询缓存未命中）。

查看混合 读/写/搜索 基准的吞吐量图表，并关注 10% 更新基准以包含所有三个操作，我们做了两种不同的可持续负载变化：

• 250 ops/sec：比较 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的压力率。
• 6000 ops/sec：比较 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 压力率。

3.5.1 MongoDB vs. ElasticSearch vs. RedisJSON* 的延迟分析

在下面的第一张图片中，展示了从 p0 到 p9999 的百分比，很明显 MongoDB 在每次单独的搜索时间上都被 Elastic 和 RedisJSON* 远远超过。此外，关注一下 ElasticSearch 和 RedisJSON*，很明显，ElasticSearch 容易受到更高的延迟的影响，这很可能是由垃圾收集(GC)触发器或搜索查询缓存丢失引起的。RedisJSON*的 p99 低于2.61ms，而 ElasticSearch 的 p99 搜索则达到了10.28ms。

在下面的读取和更新图表中，我们可以看到 RedisJSON* 在所有延迟范围内表现最佳，其次是 MongoDB 和 ElasticSearch。

RedisJSON* 是在所有分析延迟百分位比中保持亚毫秒级延迟的唯一解决方案。 在 p99，RedisJSON* 的延迟为 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒和 ElasticSearch 的 10.49 毫秒。

在写入时，MongoDB 和 RedisJSON* 即使在 p99 时也能保持亚毫秒级的延迟。 另一方面，ElasticSearch 则在后面出现了高延迟（> 10 毫秒），这很可能与导致 ElasticSearch 搜索峰值的原因 (GC) 相同。

3.5.2 ElasticSearch vs. RedisJSON* 的延迟分析

仅关注 ElasticSearch 和 RedisJSON*，在保持 6K ops/sec 的可持续负载的同时，我们可以观察到 Elastic 和 RedisJSON* 的读取和更新模式与以 250 ops/sec 进行的分析保持一致。 RedisJSON* 是更稳定的解决方案，其 p99 读取时间为 3 毫秒，而 Elastic 的 p99 读取时间为 162 毫秒。

在更新时，RedisJSON* 保留了 3 毫秒的 p99，而 ElasticSearch 则保留了 167 毫秒的 p99。

从搜索操作上看，ElasticSearch 和 RedisJSON* 都从 p50 延迟开始（p50 时 RedisJSON* 为 1.13 毫秒，而 ElasticSearch 的 p50 为 2.79 毫秒），其中 ElasticSearch 在较高的百分比上付出了 GC 触发和查询缓存未命中的代价， 从 >= p90 百分比上清晰可见。

RedisJSON* 在 p99 上低于33ms，而 ElasticSearch 的 p99 则高达 5 倍，为 163ms。

4. 未来的路

我们非常重视性能，并希望邀请其他合作伙伴和社区成员共同努力，为搜索和文档工作负载创建标准的基准定义。 RedisJSON和 RediSearch 性能数据和工具将在未来几个月内向社区开放。

与上述自我管理（内部部署）基准测试数字类似，我们还将在未来几周内针对其他类似的云文档数据库对 Redis Cloud 的 DBaaS 性能进行基准测试。 除了基准测试之外，我们还发布了一篇关于如何使用 RedisJSON 构建快速、灵活且可搜索的产品目录的技术博客。

最后，我们扩展了 RediSearch 并使其支持矢量相似性搜索（Vector Similarity Search），现在处于私人预览版中。

5. 如何开始

要开始使用 RedisJSON*，您可以在所有区域的 Redis Cloud 上创建一个免费数据库。 或者，您可以使用 RedisJSON docker 容器。 我们更新了 redisjson.io 上的文档，以便轻松开始使用查询和搜索功能。 此外，正如我们最近的客户端库公告中所提到的，这里有几种流行语言的客户端驱动程序，可帮助您入门。

语言	RedisJSON*
Node.js	node-redis
Java	Jedis
.NET	NRedisJSON 和 NRediSearch
Python	redis-py