一、概述
近期官网给出了 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 会升高它能够解决的整体吞吐量。
二、查问引擎
如前所述，reresearch 和 RedisJSON 的开发十分强调性能。对于每一个版本，咱们都想确保开发者能够体验到稳固和产品。为此，咱们咱们给出了一些剖析工具、探测器来进行性能剖析。
并且，咱们每次发行新版本时时，也在一直的晋升性能。特地是对于 reresearch 来说，2.2 版本在加载和查问性能上都比 2.0 快了 1.7 倍，同时还改良了吞吐量和数据加载的提早。
2.1 加载优化
接下来的两个图显示了运行纽约市出租车基准测试的运行后果
从这些图表中能够看出，每一个 reresearch 的新版本都有一个实质性的性能改良。
2.2 全文搜寻优化
为了评估搜寻性能，咱们索引了 590 万篇维基百科摘要。而后咱们运行一个全文搜寻查问面板，失去的后果如下图所示。
从下面的图能够看出，通过从 v2.0 迁徙到 v2.2，同样的数据，在写、读、搜寻 (提早图) 方面都有了大幅度的改良，从而进步了运行 Search 和 JSON 的可实现吞吐量。
三、和其余框架的比照
为了评估 RedisJSON 的性能，咱们决定将它与 MongoDB 和 ElasticSearch 进行比拟。为了不便比照，咱们会从文档存储、本地可用、云中可用、业余反对和提供可伸缩性、性能等方面进行全方位的比照。
咱们应用了欠缺的 YCSB 规范来进行测试比照，它可能基于常见的工作负载来评估不同的产品，测量提早、吞吐量曲线直到饱和。除了 CRUD YCSB 操作之外，咱们还增加了一个两个字的搜寻操作，专门帮忙开发人员、零碎架构师和 DevOps 从业者找到适宜他们用例的最佳搜索引擎。
3.1 基准测试
此次测试，咱们应用了如下的一些软件环境：
- 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 阵列，以实现更高级别的文件系统相干弹性操作性能。这 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% 读取] 开始，并以一组混合工作负载完结以模仿事实工作中的应用程序场景。
3.2 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 倍以上，用于隔离写入。
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 可实现的 ops/sec 从 0% 更新到 50% 的演变，咱们留神到它在 0% 更新基准上以 10k Ops/sec 开始，并受到重大影响，缩小了 5 倍的 ops/sec，在 50% 更新率基准。
与咱们在上述单个操作基准中察看到的相似，MongoDB 搜寻性能比 RedisJSON* 和 ElasticSearch 慢两个数量级，MongoDB 的最大总吞吐量为 424 ops/sec，而 RedisJSON* 为 16K 最大 ops/sec。
最初，对于混合工作负载，RedisJSON* 反对的操作数 / 秒比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍。如果咱们将剖析集中在混合工作负载期间的每种操作类型的提早上，与 MongoDB 相比，RedisJSON* 可将提早升高多达 91 倍，与 ElasticSearch 相比，提早升高 23.7 倍。
3.5 残缺提早剖析
与测量每个解决方案饱和之前产生的吞吐量曲线相似，在所有解决方案通用的可继续负载下进行残缺的提早剖析也很重要。这将使您可能理解对于所有已公布操作在提早方面最稳固的解决方案是什么，以及哪种解决方案不易受到利用程序逻辑引发的提早峰值的影响（例如，弹性查问缓存未命中）。如果您想更深刻地理解咱们为什么要这样做，Gil Tene 提供了提早测量注意事项的深刻概述。
查看上一节的吞吐量图表，并关注 10% 更新基准以蕴含所有三个操作，咱们做了两种不同的可继续负载变动：
250 ops/sec：比拟 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的压力率。6000 ops/sec：比拟 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 压力率。
3.5.1 MongoDB 与 ElasticSearch 与 RedisJSON* 的提早剖析
在上面的第一张图片中，展现了从 p0 到 p9999 的百分位数，很显著，在每次搜寻时，MongoDB 的体现都远远优于 Elastic 和 RedisJSON*。此外，关注 ElasticSearch 与 RedisJSON*，很显著，ElasticSearch 容易受到较高提早的影响，这很可能是由垃圾收集 (GC) 触发器或搜寻查问缓存未命中引起的。RedisJSON* 的 p99 低于 2.61 毫秒，而 ElasticSearch p999 搜寻达到 10.28 毫秒。
在上面的读取和更新图表中，咱们能够看到 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 与 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 放弃在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位数为 163 毫秒，高出 5 倍。