速度的未来即将来到您所在的城市。
加入我们参加 Redis 发布会
分享
注意： 此文章已更新，以反映 Redis JSON 2.0 和 Redis Search 2.2 的正式发布。
2019 年 7 月，我们推出了 私人预览，一个实时文档存储，具有原生索引、查询和全文搜索功能，由 Redis JSON 和 Redis Search 结合提供。在预览期间，我们极大地提高了产品的性能和稳定性，简化了打包以更轻松地上手，并增强了驱动程序支持。今天，我们很高兴地宣布，RedisJSON/Redis JSON（由 RediSearch/Redis Search 提供支持）**现在已正式发布**，并已** 在我们的云中提供**。
Redis JSON 是一种源代码可用的实时文档存储，允许您通过使用动态的、层次化的 JSON 文档模型来构建现代应用程序。我们早期的客户已经开始在数据堆栈的各种架构场景中使用它：作为缓存、作为查询加速器以加快热点处理，以及作为主要数据库。我们也看到开发人员社区的采用率在不断上升。仅在过去 3 个月， Redis JSON 和 Redis Search 的 Docker 拉取量就达到了 100 万次。
Redis 是连续 5 年最受欢迎的数据库（Stack Overflow 调查），我们希望 RedisJSON 能够与我们社区所熟悉的 Redis 一样简单、可扩展，最重要的是速度快，因此我们从头开始专门构建它。鉴于性能是 Redis 的关键优势，我们决定检查一下我们与以前的版本和市场上可比的参与者相比如何。为了公平地比较 RedisJSON、MongoDB 和 ElasticSearch，我们使用了行业标准的 Yahoo! 云服务基准测试 (YCSB)。
每个产品都有不同的架构和不同的功能集。对于给定的用例，一种产品可能比另一种更适合。坦率地说，我们知道 MongoDB 和 ElasticSearch 已经存在了更长时间。开发者可以选择适合手头问题的工具。我们在博客中为我们的基准测试结果添加了很多上下文，因为有很多变量在起作用，这些变量可能与您的用例不同。我们发现
此外，**Redis JSON 在负载下的读、写和搜索延迟在较高百分位数方面远比 ElasticSearch 和 MongoDB 更稳定。**当写入比例增加时，Redis JSON 还可以处理越来越高的整体吞吐量，而 ElasticSearch 则会降低其可以处理的整体吞吐量。
如前所述，Redis Search 和 Redi sJSON 在开发过程中非常重视性能。在每次发布中，我们都希望确保您体验到稳定且快速的產品。无论我们是在寻找改进模块效率的空间，还是进行性能回归调查，我们都依靠一个完全自动化的框架，在对存储库的每次提交时运行端到端性能测试 （详情见此），并在需要时通过附加遥测和分析工具/探测器进行性能调查。
这使我们能够以简洁的方法在每次发布中不断提高性能。**具体来说，对于 Redis Search，2.2 版本比 2.0 版本快 1.7 倍，包括摄取和查询性能，结合了吞吐量和延迟方面的改进。**
接下来的两张图显示了运行 NYC 出租车基准测试的结果（ 详情见此）。该基准测试衡量了摄取大约 1200 万个文档（2015 年在纽约市进行的黄色出租车行驶）时观察到的吞吐量和延迟。
从这些图中可以看出，Redis Search 的每个新版本都带来了显著的性能提升。
为了评估搜索性能，我们索引了 590 万个维基百科摘要。然后，我们运行了一组全文搜索查询（ 详情见此）。
如上图所示，通过从 v2.0 升级到 v2.2，您将受益于更快的写入/读取/搜索（延迟图表），从而提高 Search 和 JSON 运行的相同硬件的可实现吞吐量。
为了评估 Redis JSON 的性能，我们决定将其与 MongoDB 和 ElasticSearch 进行基准测试。谈到文档存储，这些解决方案经常会被提及。它们都可以在本地部署，也可以在云中部署，提供专业支持，并致力于提供可扩展性和性能。当然，一切取决于用例，未来，我们计划将此基准测试扩展到其他提供与 Redis 相当功能范围的供应商。让我们来看看我们的方法。
我们使用了成熟的 YCSB，它能够基于常见工作负载评估不同的产品，测量产生的延迟/吞吐量曲线，直至饱和。除了 CRUD YCSB 操作， 我们还添加了一个双词搜索操作，专门帮助开发人员、系统架构师和 DevOps 从业人员为其用例找到最佳的搜索引擎。生成的文档大小约为 500 字节，每个解决方案都会创建一个二级索引，索引一个文本字段和一个数字字段。
对于所有测试的解决方案，都使用了最新的可用的稳定 OSS 版本：MongoDB v5.0.3、ElasticSearch 7.15 和 Redis JSON（Redis Search 2.2 + Redis JSON 2.0）。
我们在 Amazon Web Services 实例上运行了基准测试，这些实例通过我们的 基准测试基础设施 进行配置。所有这三种解决方案都是分布式数据库，通常在生产中以分布式方式使用。这就是为什么所有产品都使用相同的通用 m5d.8xlarge 虚拟机，并配有本地 SSD，并且每个设置都包含四台虚拟机：一台客户端 + 三台数据库服务器。基准测试客户端和数据库服务器都运行在单独的 m5d.8xlarge 实例上，这些实例处于最佳网络条件下，实例紧密地打包在可用区内，从而实现低延迟和稳定的网络性能，从而使稳态分析成为可能。
测试在以下部署详细信息的三节点集群上执行
除了这个主要的基准测试/性能分析场景之外，我们还在网络、内存、CPU 和 I/O 上运行了基准测试，以便了解底层的网络和虚拟机特征。在整个基准测试过程中，网络性能保持在测量的限制以下，包括带宽和 PPS，以产生稳定且超低延迟的网络传输（每个数据包的 p99 < 100 微秒）。
我们首先提供每个单独的操作性能 [100% 写入] 和 [100% 读取]，最后提供一组混合工作负载，以模拟现实应用程序场景。
从下面的图表中可以看出，这个基准测试表明 Redis JSON 的摄取速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同时保持每个操作的亚毫秒延迟。值得注意的是，99% 的 Redis 请求在不到 1.5 毫秒内完成。
此外，**Redis JSON 是我们测试的唯一一个在每次写入时原子更新其索引的解决方案。**这意味着任何后续的搜索查询都会找到已更新的文档。ElasticSearch 并不具备这种细粒度的能力；它将摄取的文档放入内部队列中，该队列由服务器（不受客户端控制）每 N 个文档或每 M 秒刷新一次。他们将这种方法称为近乎实时 (NRT)。Apache Lucene 库（为 ElasticSearch 实现全文功能）旨在快速搜索，但索引过程复杂且繁重。正如这些写入基准测试图表所示，ElasticSearch 由于这种“设计使然”的限制而付出了巨大的代价。
当结合延迟和吞吐量改进时，Redis JSON 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 多倍，用于孤立的写入。
与写入类似，我们可以观察到 Redis 在读取方面是性能最佳的，允许的读取次数是 ElasticSearch 的 15.8 倍，是 MongoDB 的 2.8 倍，同时在整个延迟范围内保持亚毫秒级延迟，如以下表格所示。
当结合延迟和吞吐量改进时，Redis JSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 多倍，用于孤立的读取。
现实世界的应用程序工作负载几乎总是读、写和搜索查询的混合。因此，了解接近饱和时的混合工作负载吞吐量曲线就更加重要了。
作为起点，我们考虑了 65% 的搜索和 35% 的读取场景，这代表了常见的现实世界场景，在这种场景中，我们执行的搜索/查询比直接读取更多。65% 的搜索、35% 的读取和 0% 的更新的初始组合也导致 ElasticSearch 和 Redis JSON 的吞吐量相同。尽管如此，YCSB 工作负载允许您指定搜索/读取/更新之间的比率以匹配您的要求。
“搜索性能”可以指不同类型的搜索，例如“匹配查询搜索”、“分面搜索”、“模糊搜索”等等。我们最初向 YCSB 添加的搜索工作负载仅关注模仿分页的双词查询匹配的“匹配查询搜索”，按数字字段排序。“匹配查询搜索”是任何支持搜索功能的供应商进行搜索分析的起点，因此，每个 YCSB 支持的数据库/驱动程序都应该能够在其基准驱动程序上轻松启用此功能。
在每个测试变体中，我们添加了 10% 的写入以混合并按相同比例减少搜索和读取百分比。这些测试变体的目标是了解每个产品如何处理数据的实时更新，我们认为这是事实上的架构目标，即写入立即提交到索引，读取始终是最新的。
如您在图表中所见，持续更新数据并在 Redis JSON 上增加写入比例不会影响读取或搜索性能，并会提高总体吞吐量。数据产生的更新越多，ElasticSearch 的性能受到的影响就越大，最终导致读取和搜索速度变慢。
查看 ElasticSearch 从 0 到 50% 更新的每秒可实现操作数的演变，我们注意到它在 0% 更新基准测试中从 10k 操作数/秒开始，并深受影响，减少了 5 倍的操作数/秒，在 50% 更新率基准测试中仅达到 2.1K 操作数/秒。
与我们在上面的单个操作基准测试中观察到的情况类似，MongoDB 的搜索性能比 Redis JSON 和 ElasticSearch 慢两个数量级，MongoDB 的最大总吞吐量为 424 操作数/秒，而 Redis JSON 为 16K 操作数/秒。
最后，对于混合工作负载，Redis JSON 的每秒操作数比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍。如果我们关注混合工作负载期间每种操作类型的延迟分析，那么与 MongoDB 相比，Redis JSON 的延迟低 91 倍，与 ElasticSearch 相比，Redis JSON 的延迟低 23.7 倍。
与测量每个解决方案饱和之前的吞吐量曲线类似，在所有解决方案都具有可持续负载的情况下，进行完整的延迟分析也很重要。这将使您能够了解在延迟方面哪个解决方案对所有发出的操作最稳定，以及哪个解决方案最不容易受到应用程序逻辑（例如，Elastic 查询缓存未命中）引起的延迟峰值的影響。如果您想深入了解为什么我们应该这样做，Gil Tene 提供了延迟测量要点和禁区的深入概述。
查看上一节的吞吐量图表，并重点关注 10% 更新基准测试以包含所有三个操作，我们执行了两种不同的可持续负载变体
在下面的第一张图片中，展示了从 p0 到 p9999 的百分位数，很明显，MongoDB 在每个单独的搜索时间方面都远远落后于 Elastic 和 Redis JSON。此外，重点关注 ElasticSearch 与 Redis JSON，很明显，ElasticSearch 容易受到更高延迟的影响，这很可能是由垃圾回收 (GC) 触发器或搜索查询缓存未命中引起的。Redis JSON 的 p99 低于 2.61 毫秒，而 ElasticSearch 的 p99 搜索则达到了 10.28 毫秒。
在下面的读取和更新图表中，我们可以看到，在所有延迟范围内，Redis JSON 的性能最佳，其次是 MongoDB 和 ElasticSearch。
Redis JSON 是唯一一个在所有分析的延迟百分位数范围内保持亚毫秒级延迟的解决方案。在 p99 处，Redis JSON 的延迟为 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒，ElasticSearch 的 10.49 毫秒。
在写入方面，即使在 p99 处，MongoDB 和 Redis JSON 也保持了亚毫秒级延迟。另一方面，ElasticSearch 显示出高尾部延迟（>10 毫秒），这很可能是与导致 ElasticSearch 搜索峰值的相同原因（GC）有关。
仅关注 ElasticSearch 和 Redis JSON，同时保持 6K 操作数/秒的可持续负载，我们可以观察到 Elastic 和 Redis JSON 的读取和更新模式与 250 操作数/秒的分析保持一致。Redis JSON 是更稳定的解决方案，p99 读取为 3 毫秒，而 Elastic 的 p99 读取为 162 毫秒。
在更新方面，Redis JSON 保持了 3 毫秒的 p99，而 ElasticSearch 的 p99 为 167 毫秒。
重点关注搜索操作，ElasticSearch 和 Redis JSON 以个位数的 p50 延迟开始（Redis JSON 的 p50 为 1.13 毫秒，而 ElasticSearch 的 p50 为 2.79 毫秒），ElasticSearch 在更高百分位数上为 GC 触发和查询缓存未命中付出了代价，正如在 >= p90 百分位数上清晰可见的那样。
Redis JSON 保持了低于 33 毫秒的 p99，而 ElasticSearch 的 p99 高 5 倍，为 163 毫秒。
我们非常重视性能，并希望邀请其他合作伙伴和社区成员在我们的努力中进行合作，为搜索和文档工作负载创建标准基准定义。Redis JSON 和 Redis Search 性能数据和工具将在未来几个月内向社区开放。
与上面的自管理（本地）基准数字类似，我们还将在未来几周内对 Redis Cloud 的 DBaaS 性能进行基准测试，以对比其他类似的云文档数据库。除了基准测试之外，我们还发布了一篇技术博客，介绍如何使用 Redis JSON 构建快速、灵活且可搜索的产品目录。
最后，我们还使用向量相似性搜索扩展了 Redis Search，目前处于私人预览阶段。
要开始使用 Redis JSON，您可以创建 Redis Cloud 中所有区域的免费数据库。或者，您可以使用Redis JSON docker 容器。我们更新了redis.io 上的文档，以便您可以轻松开始使用查询和搜索功能。此外，正如我们最近的客户端库公告中提到的，以下是一些针对多种流行语言的客户端驱动程序，可帮助您入门。
| Redis JSON | |
| Node.js | node-redis |
| Java | Jedis |
| .NET | NRedisJSON NRediSearch |
| Python | redis-py |
以下是一些帮助您入门的信息
* – RedisJSON* 和 RediSearch 的命名约定是历史遗留物，可以忽略 *
