RedisRedisJson（RedisSearch）近日，官网给出了RedisJson（RedisSearch）的性能测试报告。比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会降低它能处理的整体吞吐量。◆测试过程◆基础架构MongoDBv5.0.3、ElasticSearch7.15和RedisJSON（RediSearch2.2+RedisJSON2.0）。生产中常用于分布式模式。这就是为什么所有产品都使用具有本地SSD的相同通用m5d.8xlargeVM，并且每个设置都包含四个VM：一个客户端+三个数据库服务器。基准客户端和数据库服务器都在最佳网络条件下在单独的m5d.8xlarge实例上运行，将实例紧密打包在一个可用区内，以实现稳态分析所需的低延迟和稳定的网络性能。测试在一个三节点集群上进行，部署细节如下：MongoDB5.0.3：三成员副本集（Primary-Secondary-Secondary）。副本用于增加读取容量并允许较低的延迟读取。为了支持对字符串内容的文本搜索查询，在搜索字段上创建了一个文本索引。ElasticSearch7.15：15个分片设置、启用查询缓存和2个基于NVMe的本地SSD的RAID0阵列，以提高与文件系统相关的弹性操作的性能。这15个分片提供了我们为Elastic所做的所有分片变体中可实现的最佳性能结果。RedisJSON*：RediSearch2.2和RedisJSON2.0：OSSRedisClusterv6.2.6，27个分片，均匀分布在三个节点上，加载RediSearch2.2和RedisJSON2.0OSS模块。除了这个主要的基准测试/分析场景之外，我们还在网络、内存、CPU和I/O上运行基准测试，以了解底层网络和虚拟机特性。在整个基准设置期间，网络性能保持在带宽和PPS的测量限制以下，以产生稳定和稳定的超低延迟网络传输（p99<100微秒/数据包）。我们将从提供每个单独操作[100%写入]和[100%读取]的性能开始，并以一组混合工作负载结束，以模拟现实生活中的应用场景。◆下图所示的100%写入基准表明，RedisJSON*的摄取速度比ElasticSearch快8.8倍，比MongoDB快1.8倍，同时每个操作的延迟保持在亚毫秒级。值得注意的是，99%的Redis请求在不到1.5毫秒内完成。此外，RedisJSON*是我们测试过的唯一一种在每次写入时自动更新其索引的解决方案。这意味着任何后续搜索查询都会找到更新的文档。ElasticSearch没有这种细粒度的能力；它将摄取的文档放在一个内部队列中，并且该队列由服务器（不受客户端控制）每N个文档或每M秒刷新一次。他们将这种方法称为近实时(NRT)。ApacheLucene库（实现了ElasticSearch的全文功能）专为快速搜索而设计，但索引过程复杂而繁重。正如这些WRITE基准图表所示，由于这种“设计”限制，ElasticSearch付出了巨大的代价。结合延迟和吞吐量改进，RedisJSON*在隔离写入方面比Mongodb快5.4倍，比ElasticSearch快200多倍。◆100%读取基准与写入类似，我们可以观察到Redis在读取方面表现最好，读取次数比ElasticSearch多15.8倍，比MongoDB多2.8倍，同时在整个延迟范围内保持亚毫秒级延迟，如下表所示.当结合延迟和吞吐量改进时，RedisJSON*比MongoDB快12.7倍，比ElasticSearch快500倍以上用于隔离读取。◆混合读取/写入/搜索基准实际应用程序工作负载几乎总是混合读取、写入和搜索查询。因此，当您接近饱和时，了解由此产生的混合工作负载吞吐量曲线更为重要。作为起点，我们考虑了65%的搜索和35%的读取场景，这代表了一个常见的现实世界场景，我们执行的搜索/查询多于直接读取。65%搜索、35%读取和0%更新的初始组合也导致ElasticSearch和RedisJSON*的吞吐量相等。尽管如此，YCSB工作负载允许您指定搜索/读取/更新之间的比率以满足您的要求。“搜索性能”可以指代不同类型的搜索，例如“匹配查询搜索”、“分面搜索”、“模糊搜索”等。我们在YCSB中添加的初始搜索工作量仅专注于“匹配查询搜索”，模仿分页的双词查询匹配，按数字字段排序。匹配查询搜索是任何支持搜索的供应商进行搜索分析的起点，因此支持YCSB的每个数据库/驱动程序都应该能够轻松地在其基准驱动程序上启用此功能。在每个测试变体中，我们添加了10%的写入以混合并减少等比例的查找和读取百分比。这些测试变体的目标是查看每个产品如何处理数据的实时更新，我们认为这是事实上的架构目标，写入立即提交到索引，读取始终是最新的。正如您在图中所见，不断更新数据和提高RedisJSON*上的写入率不会影响读取或搜索性能并提高整体吞吐量。对数据进行的更新越多，对ElasticSearch性能的影响就越大，最终导致读取和搜索速度变慢。ElasticSearch可实现的ops/sec从0%更新到50%的演变我们注意到它以0%更新基线的10kOps/sec开始，并受到严重影响，在50%更新率基准下ops/sec减少了5倍。与我们在上面的单一操作基准测试中观察到的情况类似，MongoDB搜索性能比RedisJSON和ElasticSearch慢两个数量级，MongoDB的最大总吞吐量为424ops/sec，而RedisJSON的最大总吞吐量为16Kops/sec。最后，对于混合工作负载，RedisJSON支持的操作数/秒比MongoDB多50.8倍，比ElasticSearch多7倍。如果我们将分析重点放在混合工作负载期间每种操作类型的延迟上，RedisJSON与MongoDB相比最多可减少延迟91倍，与ElasticSearch相比最多可减少23.7倍。◆每个解决方案的完整延迟分析与在饱和前测量每个解决方案的最终吞吐量曲线类似，在所有解决方案共有的可持续负载下执行完整延迟分析也很重要。这将使您了解什么是所有已发布操作的延迟最稳定的解决方案，以及哪些不易受应用程序逻辑引起的延迟峰值的影响（例如，ElasticQueryCache未命中）。如果您想更深入地了解我们这样做的原因，GilTene提供了延迟测量注意事项的深入概述。查看上一节中的吞吐量图并关注10%更新基线以包括所有三个操作，我们做了两种不同的可持续负载变化：250操作/秒：比较MongoDB、ElasticSearch和RedisJSON*，低于MongoDB压力率。6000ops/sec：比较ElasticSearch和RedisJSON*，低于ElasticSearch压力率。◆MongoDBvs.ElasticSearchvs.RedisJSON*的延迟分析在下面的第一张图中，显示了从p0到p9999的百分位数，很明显MongoDB优于Elastic和RedisJSON。此外，看看ElasticSearch与RedisJSON，很明显ElasticSearch容易受到更高延迟的影响，这很可能是由垃圾收集(GC)触发器或搜索查询缓存未命中引起的。RedisJSON*的p99低于2.61毫秒，而ElasticSearchp999搜索达到10.28毫秒。在下面的读取和更新图表中，我们可以看到RedisJSON*在所有延迟范围内表现最佳，其次是MongoDB和ElasticSearch。RedisJSON是唯一一种在所有分析的延迟百分位上保持亚毫秒延迟的解决方案。在p99，RedisJSON的延迟为0.23毫秒，其次是MongoDB的5.01毫秒和ElasticSearch的10.49毫秒。写入时，MongoDB和RedisJSON*即使在p99时也能保持亚毫秒级延迟。另一方面，ElasticSearch显示出高尾延迟（>10毫秒），这很可能与导致ElasticSearch搜索峰值的原因(GC)相同。◆ElasticSearch和RedisJSON的延迟分析只关注ElasticSearch和RedisJSON，在保持6Kops/sec的可持续负载的情况下，我们可以观察到Elastic和RedisJSON的读取和更新模式与在250ops/sec下进行的分析一致。RedisJSON*是更稳定的解决方案，其p99读取时间为3毫秒，而Elastic的p99读取时间为162毫秒。更新时，RedisJSON*保留了3毫秒的p99，而ElasticSearch保留了167毫秒的p99。专注于搜索操作，ElasticSearch和RedisJSON以个位数的p50延迟开始（RedisJSON为1.13msp50，而ElasticSearch为2.79ms），ElasticSearch以较高的百分位数分位数支付GC触发器和查询缓存未命中的代价，在>=p90百分位数。RedisJSON*将p99保持在33毫秒以下，而ElasticSearch上的p99百分位数为163毫秒，高出5倍。◆小结从上面的测试结论可以看出，RedisJson可以说几乎在所有性能方面都碾压了ES和Mongo，那以后怎么办，NoSQL要变了吗？原文：https://redis.com/blog/redisj...翻译：https://www.toutiao.com/a7032...推荐近期文章：1.1,000+Java面试题及答案（2021最新版）2.劲爆！Java协程来了。..3.玩大！Log4j2.x再次爆发。..4、SpringBoot2.6正式发布，一大波新特性。.5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
