AerospikeDB与Redis性能比较：在AWS上的NoSQL基准测试
时间:2016-05-29 13:20 来源:linux.it.net.cn 作者:IT
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实例，专门用于持久化处理，以减轻主实例的负担。
最后，他写道：
比较是一件很难做对却很容易做错的事。
(责任编辑：IT)
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在扩展或分片的可管理性方面的差异：
接下来，Lynn针对下列工作负载做了两组基准测试：
第一组基准测试是在单个没有永久存储的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的测试结果提出质疑，主要包含如下几点：
同时，Itamar指出，对于AOF，一个常见的做法是引入一个从属Redis实例，专门用于持久化处理，以减轻主实例的负担。 最后，他写道： 比较是一件很难做对却很容易做错的事。 (责任编辑：IT) |