RediSearch 2.0-在Redis之上创建二级索引比以往任何时候都更容易

RediSearch是一个实时二级索引，具有针对Redis的全文搜索功能，是最成熟、功能最丰富的Redis模块之一。它也变得越来越受欢迎-在过去的几个月里，RediSearch Docker的拉动量跃升了500%！这种飙升的受欢迎程度导致客户提出了各种各样有趣的用例，从实时库存管理到短暂搜索，应有尽有。

为了延续这一势头，我们现在推出了RediSearch2.0的公开预览版，旨在改善开发人员的体验，成为Redisearch2.0最具伸缩性的版本。RediSearch2.0支持Redis Labs的主动-主动地理分发技术，可在不停机的情况下进行扩展，并且包括对Redis on Flash的支持(目前处于私人预览版)。为了在不对性能造成负面影响的情况下实现这些目标，我们为RediSearch 2.0创建了一个全新的体系结构--并且奏效了：RediSearch 2.0的速度是RediSearch 1.6的2.4倍。

在您的Redis数据库中拥有一个丰富的查询和聚合引擎可以实现各种新的用例，这些用例远远超出了缓存的范畴。RediSearch允许您在需要使用复杂查询访问数据的情况下使用Redis作为主要数据库。更好的是，它保持了Redis世界级的速度、可靠性和可伸缩性，并且不需要增加代码的复杂性来更新和索引数据。

对于RediSearch2.0，我们重新设计了索引与数据保持同步的方式。RediSearch现在不需要通过索引写入数据(使用FT.ADD命令)，而是跟踪以散列形式写入的数据并对其进行同步索引。这种重新架构伴随着API的几个变化，当RediSearch2.0达到它的第一个里程碑时，我们在上一篇文章中讨论了这一点。

这一新架构带来了两个主要好处。首先，现在在现有数据之上创建二级索引比以往任何时候都更容易。您只需将RediSearch添加到现有的Redis数据库、创建索引并开始查询，而不必迁移数据或使用新命令将数据添加到索引。这极大地降低了RediSearch新用户的学习曲线，并允许您在现有的Redis数据库上创建索引-甚至无需重新启动它们。

除了实现一种新的数据索引方式外，我们还将索引从关键字空间中移除。这使得Redis Enterprise基于无冲突复制数据类型(CRDs)的主动-主动技术得以实现。*合并两个无冲突的倒排索引是困难的，但Redis Labs已经有了经过验证的CRDs哈希实现。因此，这种新架构的第二大好处是使RediSearch 2.0更具可伸缩性。由于RediSearch现在跟随散列，并且索引已移出键空间，因此您现在可以在主动-主动地理分布式数据库中运行RediSearch。

文档将以最终高度一致的方式复制到复制集中的所有数据库。在每个副本中，RediSearch将简单地跟踪散列上的所有更新，这意味着所有索引最终也具有很强的一致性。

我们不想将增加可伸缩性功能限制为只增加Redis Enterprise用户，所以我们使用开源的Redis集群API添加了对在多个分片上扩展单个索引的支持。以前，单个RediSearch索引及其文档必须驻留在单个碎片上。这意味着OSS Redis的数据集大小和吞吐量与单个Redis进程可以处理的数据集大小和吞吐量绑定在一起。Redis Enterprise提供了在集群数据库中分发文档并在查询时聚合结果的功能。这种扇出和聚合是由一个称为“协调器”的组件处理的，该组件现在也可以在Redis Source Available许可证下公开使用，因此它可以与开源Redis集群以及Redis Enterprise一起使用。其结果是RediSearch迄今最具伸缩性的版本。

为了评估RediSearch2.0的吸收性能，我们使用公开可用的NYC Taxi数据集扩展了我们的全文搜索基准(FTSB)套件。此数据集因其丰富的数据类型集(文本、标记、地理和数字)和大量文档而在整个行业中使用。

该基准测试的重点是写入性能，使用的是纽约市乘坐黄色出租车的行程记录数据。特别针对此基准，我们使用了2015年1月的数据集，它加载了1200多万个文档，每个文档的平均大小为500字节。有关完整的基准测试规范，请参阅GitHub上的FTSB。

所有基准测试变体都在Amazon Web Services实例上运行，这些实例通过我们的基准测试基础设施进行配置。测试在具有15个分片的3节点集群上执行，RediSearch Enterprise版本为1.6和2.0。基准测试客户端和组成启用了RediSearch的数据库的3个节点都在单独的c5.9xLarge实例上运行。

鉴于RediSearch2.0能够跟踪Redis中散列的变化并自动索引它们，我们已经为FT.ADD和HSET命令添加了变体。为了使升级更容易，我们将现在不推荐使用的FT.ADD命令重新映射到RediSearch2.0中的HSET命令。下面的两个图表显示了RediSearch 1.6和RediSearch 2.0的总体摄取率和延迟，同时保持了亚毫秒级的延迟。

RediSearch一直都很快，但通过这种架构更改，我们已经从每秒索引96K文档转移到每秒132K文档索引，总体p50接收延迟为0.4ms，极大地提高了写入伸缩性。

您不仅会从吞吐量的提升中受益，而且每次摄取都会变得更快。除了架构更改带来的整体接收改进之外，您现在还可以依靠OSS Redis Cluster API功能线性扩展搜索数据库的接收。

结合吞吐量和延迟改进，与RediSearch 1.6相比，RediSearch 2.0提供了高达2.4倍的加速。

总而言之，RediSearch2.0是我们发布的最快、最具伸缩性的Redis用户版本。此外，RediSearch 2.0的新架构改善了开发人员无缝地为Redis中的现有数据创建索引的体验，并消除了将您的Redis数据迁移到另一个启用RediSearch的数据库的需要。这个新的架构允许RediSearch跟踪和自动索引其他数据结构，例如流或字符串。在即将发布的版本中，它将允许您使用额外的数据结构，例如RedisJSON中的嵌套数据结构。

我们计划继续增加更多功能，以进一步提升开发者体验。接下来，寻找一个新命令，它允许您分析搜索查询，以便更好地了解查询执行期间哪里出现性能瓶颈。

准备好开始了吗？在…上查看塔格·葛尔的博客。RediSearch 2.0入门！然后在GitHub上按照本教程中的步骤操作，或者在Redis Enterprise Cloud Essentials中创建一个免费数据库。(请注意，RediSearch 2.0的公开预览版在两个Redis Enterprise Cloud Essentials地区提供：孟买和俄勒冈州。)