近期官网给出了RedisJson（RedisSearch）的性能测试报告，可谓碾压其他NoSQL，下面是核心的报告内容，先上结论：
对于隔离写入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。

对于隔离读取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。

在混合工作负载场景中，实时更新不会影响 RedisJSON 的搜索和读取性能，而 ElasticSearch 会受到影响。
RedisJSON* 支持的操作数/秒比 MongoDB 高约 50 倍，比 ElasticSearch 高 7 倍/秒。

RedisJSON* 的延迟比 MongoDB 低约 90 倍，比 ElasticSearch 低 23.7 倍。

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

测试过程

基础设施
MongoDB v5.0.3, ElasticSearch 7.15, and 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 阵列，以实现更高级别的文件系统相关弹性操作性能。这 15 个分片为我们为 Elastic 所做的所有分片变体提供了可实现的最佳性能结果。

RedisJSON: RediSearch 2.2 and RedisJSON 2.0: OSS Redis Cluster v6.2.6，有27个分片，均匀分布在三个节点上，加载了RediSearch 2.2和RedisJSON 2.0 OSS模块。

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

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

100% 写入基准

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

此外，RedisJSON* 是我们测试过的唯一一种在每次写入时自动更新其索引的解决方案。这意味着任何后续的搜索查询都会找到更新的文档。ElasticSearch 没有这种细粒度的容量；它将摄取的文档放在一个内部队列中，并且该队列由服务器（不受客户端控制）每 N 个文档或每 M 秒刷新一次。

他们称这种方法为近实时 (NRT)。Apache Lucene 库（它实现了 ElasticSearch 的全文功能）旨在快速搜索，但索引过程复杂且繁重。如这些 WRITE 基准测试图表所示，由于这种“设计”限制，ElasticSearch 付出了巨大的代价。

结合延迟和吞吐量改进，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔离写入。
100% 读取基准

与写类似，我们可以观察到 Redis 在读取方面表现最佳，允许读取比 ElasticSearch 多 15.8 倍，比 Mongo