视频
RediSearch 2.0 入门
了解更多
速度的未来即将在您所在的城市举办的活动中亮相。
加入我们参加 Redis 发布会
分享
RediSearch 是一款实时二级索引，具有针对 Redis 的全文搜索功能，是 Redis 最成熟、功能最丰富的模块之一。它也正在变得越来越受欢迎，在过去几个月里，RediSearch Docker 的下载量增长了 500%！这种飙升的人气促使客户提出了一系列有趣的用例，从 实时库存管理 到 短暂搜索。
为了进一步发展这一势头，我们现在发布了 RediSearch 2.0 的公开预览版，旨在提升开发者体验，并成为最可扩展的 RediSearch 版本。RediSearch 2.0 支持 Redis 的 双活地理分布 技术，可实现可扩展性，且无停机，并包含 Redis on Flash 支持（目前处于私有预览阶段）。为了实现这些目标，且不影响性能，我们为 RediSearch 2.0 创建了一种全新的架构，结果证明是有效的：RediSearch 2.0 的速度比 RediSearch 1.6 快 2.4 倍。
在您的 Redis 数据库中拥有丰富的查询和聚合引擎，可以支持各种新用例，远远超出缓存范围。RediSearch 使您能够在需要使用复杂查询访问数据的场景中使用 Redis 作为您的主要数据库。更棒的是，它保留了 Redis 的世界级速度、可靠性和可扩展性，无需您在代码中添加复杂性即可更新和索引数据。
对于 RediSearch 2.0，我们重新设计了索引与数据保持同步的方式。RediSearch 现在不再需要通过索引写入数据（使用 FT.ADD 命令），而是跟踪写入哈希的数据并同步地对其进行索引。这种重新设计带来了 API 的一些更改，我们之前在 RediSearch 2.0 迈出第一步 的文章中讨论过。
这种新架构带来了两个主要优势。首先，现在比以往任何时候都更容易在现有数据之上创建二级索引。您只需将 RediSearch 添加到现有的 Redis 数据库中，创建索引，然后开始查询，无需迁移数据或使用新的命令向索引中添加数据。这大大降低了 RediSearch 新用户的学习曲线，并允许您在现有 Redis 数据库上创建索引，甚至无需重新启动它们。
除了实现一种新的索引数据方法外，我们还将索引移出了键空间。这使 Redis Enterprise 的 双活技术 成为可能，该技术基于 无冲突复制数据类型 (CRDT)。无冲突地合并两个倒排索引非常困难，但 Redis 已经具有 经过验证的哈希 CRDT 实现。因此，这种新架构的第二个重大优势是使 RediSearch 2.0 更加可扩展。由于 RediSearch 现在跟踪哈希，并且索引已移出键空间，因此您现在可以在双活地理分布式数据库中运行 RediSearch。
文档将以 强最终一致性方式 复制到复制集中所有数据库中。在每个副本中，RediSearch 只是跟踪对哈希的所有更新，这意味着所有索引也具有强最终一致性。
我们不想将可扩展性的提升能力仅限于 Redis Enterprise 用户，因此我们添加了对使用开源 Redis 集群 API 在多个分片上扩展单个索引的支持。以前，单个 RediSearch 索引及其文档必须驻留在单个分片上。这意味着 OSS Redis 的数据集大小和吞吐量受单个 Redis 进程能够处理的范围限制。Redis Enterprise 提供了将文档分布到集群数据库中的能力，并在查询时聚合结果。这种扇出和聚合由一个称为“协调器”的组件处理，该组件现在也 公开提供，根据 Redis 源代码可用许可，因此它可以使用开源 Redis 集群和 Redis Enterprise。最终结果是迄今为止最可扩展的 RediSearch 版本。
为了评估 RediSearch 2.0 的摄取性能，我们使用 公开的 NYC 出租车数据集 扩展了我们的全文搜索基准测试 (FTSB) 套件。由于该数据集包含丰富的各种数据类型（文本、标签、地理和数字）以及大量文档，因此被整个行业广泛使用。
此基准测试侧重于写入性能，使用纽约市黄色出租车乘坐记录数据。具体而言，对于此基准测试，我们使用了 2015 年 1 月的数据集，该数据集加载了超过 1200 万个文档，每个文档的平均大小为 500 字节。有关完整的基准测试规范，请参阅 GitHub 上的 FTSB。
所有基准测试变体都在 Amazon Web Services 实例上运行，并通过我们的基准测试基础设施进行配置。测试在具有 15 个分片的 3 节点集群上执行，使用 RediSearch Enterprise 版本 1.6 和 2.0。基准测试客户端和包含启用 RediSearch 的数据库的 3 个节点都在独立的 c5.9xlarge 实例上运行。
鉴于 RediSearch 2.0 具有跟踪 Redis 中哈希更改并自动对其进行索引的功能，我们添加了针对 FT.ADD 和 HSET 命令的变体。为了简化升级，我们将现在已弃用的 FT.ADD 命令重新映射到 RediSearch 2.0 中的 HSET 命令。以下两个图表显示了 RediSearch 1.6 和 RediSearch 2.0 的整体摄取速率和延迟，同时保持毫秒级的延迟。
RediSearch 一直以来都很快，但通过这种架构更改，我们的索引速度从每秒 96K 个文档提升到每秒 132K 个文档，整体 p50 摄取延迟为 0.4 毫秒，极大地提高了写入扩展性。
您不仅会从吞吐量提升中受益，而且每次摄取速度也会更快。除了由于架构更改而带来的整体摄取提升之外，您现在还可以依靠 OSS Redis 集群 API 功能来线性扩展搜索数据库的摄取。
结合吞吐量和延迟改进，RediSearch 2.0 的速度比 RediSearch 1.6 快 2.4 倍。
总而言之，RediSearch 2.0 是我们发布的最快、最可扩展的版本，适用于所有 Redis 用户。此外，RediSearch 2.0 的新架构改善了为 Redis 中的现有数据创建索引的开发者体验，并无需将 Redis 数据迁移到另一个支持 RediSearch 的数据库。这种新架构允许 RediSearch 跟踪并自动索引其他数据结构，如流或字符串。在未来的版本中，它将允许您使用其他数据结构，例如 RedisJSON 中的嵌套数据结构。
我们计划继续添加更多功能来进一步增强开发者体验。接下来，您将看到一个新命令，允许您分析搜索查询以更好地了解查询执行期间性能瓶颈出现的位置。
准备好开始了吗？查看 Tug Grall 的博客，了解有关 ... 如何开始使用 RediSearch 2.0 的内容！然后按照 GitHub 上的本教程 中的步骤操作，或在 Redis Enterprise Cloud Essentials 中创建一个免费数据库。（请注意，RediSearch 2.0 的公开预览版在两个 Redis Enterprise Cloud Essentials 区域中提供：孟买和俄勒冈州。）
