AerospikeDB 与 Redis 性能比较：在 AWS 上的 NoSQL 基准测试

AerospikeDB 以低延迟和高吞吐量而闻名，已经用于许多大型的、要求堪称苛刻的实时平台。而 Redis 同样以速度著称，并且也经常用作缓存。有鉴于此，Aerospike 团队近日联合拥有大数据和云架构师、AWS 社区英雄、谷歌云开发专家、微软 MVP（SQL Server）等众多头衔的 Lynn Langit 在 AWS 云的虚拟机上对 AerospikeDB 和 Redis 进行了基准测试，测试结果已经发布在 Aerospike 官方博客上。而 Lynn 也发表了题为《学到的经验——在 AWS 云上进行 NoSQL 基准测试（AerospikeDB 与 Redis）》的博文，对测试过程和结果进行了更为详细的描述。

由于 AerospikeDB 是多线程的，而 Redis 是单线程的，所以为了公平起见，需要对 Redis 进行扩展，以便它能够使用每个 AWS EC2 实例上的多个内核。在这个过程中，Lynn 发现了 AerospikeDB 和 Redis 在扩展或分片的可管理性方面的差异：

• Redis 需要开发人员自己管理分片并提供分片算法用于在各分片之间平衡数据；而 AerospikeDB 可以自动处理相当于分片的工作；
• 在 Redis 中，为了增加吞吐量，需要增加 Redis 分片的数量，并重构分片算法及重新平衡数据，这通常需要停机；而在 AerospikeDB 中，可以动态增加数据卷和吞吐量，无需停机，并且 AerospikeDB 可以自动平衡数据和流量；
• 在 Redis 中，如果需要复制及故障转移功能，则需要开发人员自己在应用程序层同步数据；而在 AerospikeDB 中，只需设置复制因子，然后由 AerospikeDB 完成同步复制操作，保持即时一致性；而且 AerospikeDB 可以透明地完成故障转移；
• 此外，AerospikeDB 既可以完全在内存中运行，也可以利用 Flash/SSD 存储的优点。

接下来，Lynn 针对下列工作负载做了两组基准测试：

• 负载一：50%-50% 读 / 写 (-w RU, 50)；
• 负载二：80%-20% 读 / 写 (-w RU, 80)；
• 负载三：100% 读 (-w RU, 100)。

第一组基准测试是在单个没有永久存储的 AWS R3.8xlarge 节点上进行的，测试结果如下：

（图一）

从上图可以看出，在运行（负载三）时，AerospikeDB 和 Redis 性能相近，均接近 1 MTPS。

第二组测试是在同样的实例上进行的，但引入了永久性存储。所有数据既会保存在内存中，也会存储在 EBS SSD（gp2）存储上。在本组测试中，Lynn 为 AerospikeDB 配置了一个新的命名空间，并使用了配置参数“data-in-memory”。而且，为了避免写入单个文件造成瓶颈，她还为 AerospikeDB 配置了 12 个不同的可写入位置。对于 Redis，则启用了“appendonly”选项。在这种模式下，一旦 AOF 文件增长到一定的大小，Redis 就会在后台重写 AOF 文件。这时，Redis 的吞吐量就会下降。为了避免这种情况出现，Lynn 将 auto-aof-rewrite-min-size 参数设为一个很大的值。这在一定程度上会夸大 Redis 的性能。在这个场景中，磁盘写成为瓶颈。因此，Lynn 针对 AerospikeDB 和 Redis 均减少了客户端线程的数量，保证不出现写错误。测试结果如下：

（图二）

从上图可以看出，在运行（负载二）和（负载三）时，AerospikeDB 都比 Redis 略快。

此外，Lynn 还单独测试了 AOF 重写对吞吐量的影响，测试结果如下：

（图三）

从上图可以看出，AOF 重写对 Redis 读写性能均有较大的影响。

按照 Lynn 的说法，上述基准测试结果可能会因为云环境本身的不稳定性、调优技术和基础设置的差异而有所不同。感兴趣的读者可以查看原文了解Lynn 的测试步骤及配置细节。

在上述结果发布后，Redis 创建者Salvatore Sanfilippo 很快就以《我们为什么不做基准测试来比较Redis 和其它DB 》为题发表博文对此进行了回应。他认为，这种对比有广告嫌疑，并提供了一些从Redis 得出更好结果的方法。紧接着，Redis 首席开发大使 Itamar Haber 也发表了题为《漏掉的经验——在 AWS 云上进行 NoSQL 基准测试（AerospikeDB 与 Redis）》的博文，对 Aerospike 团队和 Lynn 的测试结果提出质疑，主要包含如下几点：

• 该测试没有使用推荐的 Redis 做法，比如使用管道和多键操作；
• 该测试没有测试工作负载：20%-80% 读写（ -w RU,20 ）和 100% 写（-w RU,0）；
• 比较（图一）和（图二）可以得出：在针对（负载三）的测试中，第一次测试结果为 928K TPS，第二次测试结果为 860K TPS，使用了 AOF 并不能完全解释这种差别；此处还有一点令人疑惑，后端使用 EBS 的 Redis 其性能（180K TPS）竟然高于只在内存中使用的 Redis 服务器（132K TPS）。

同时，Itamar 指出，对于 AOF，一个常见的做法是引入一个从属 Redis 实例，专门用于持久化处理，以减轻主实例的负担。

最后，他写道：

比较是一件很难做对却很容易做错的事。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。