在 AWS 云上对 NoSQL 进行基准测试时遗漏的经验教训（AerospikeDB 和 Redis）

Aerospike 兑现了其上周的承诺，昨天发布了 Lynn Langit 题为“在 AWS 云上对 NoSQL 进行基准测试时遗漏的经验教训（AerospikeDB 和 Redis）”的基准测试结果。 Redis 的创建者 Salvatore Sanfilippo 在“我们为什么没有将 Redis 与其他数据库进行比较的基准测试”中发表了回应，其中他描述了进行“比较广告”的一些陷阱，并提供了几种从 Redis 获得更好结果的方法。

该基准测试清楚地表明，在某些读写混合情况下，Redis 和 AerospikeDB 都可以用作“哑”键值存储，并且在每个服务器的吞吐量方面基本上提供相同的价值。 那么除了可比较的性能之外还有什么呢？ 嗯，Aerospike 理所当然地拥有一个不错的 UI 和友好的自动化（而且我看到了Redis 也有相同的功能:)），但昨天的基准测试仍然留下了一些未解答的问题。

为什么基准测试没有使用传统的、推荐的 Redis 实践，例如流水线和多键操作？ 我认为这是因为 Aerospike 没有这些的等价物，不得不求助于简单的 GET/SET 操作，本质上测量的是网络（也许还有操作系统），而不是技术的真正能力。 另一个缺失的部分是 20%-80% 的读/写测试 (-w RU, 20) 和 100% 的写测试 (-w RU, 0)。 我怀疑此类运行的结果与基准测试的信息不符。

无论如何，为什么有些点根本不加起来呢？ 以 Lynn 对 Test 1 和 Test 2 中分片 Redis 的 100% 读取模式的结果为例。在第一个测试中，配置得分 928K TPS，而在第二个测试中仅达到 860K——这一减少完全无法解释，因为她使用了 AOF。 即使为 Test 2 启用了 AOF，Redis 也仅响应数据更改（也称为写入）而访问磁盘，因此 AOF 对只读流量的影响应为 0%。 这本身就很令人费解，但这里还有另一个奇怪之处：她的基准测试发现，EBS 支持的 Redis 实际上比仅使用 RAM 的 Redis 服务器性能更好——再次比较 Test 2 和 Test 1 的单分片 Redis 的从不写入分数：分别为 180K 和 132K TPS。

如果您在写入属于流量的一部分时比较 Test 1 和 2 中的单分片 Redis，惊喜会继续。 在 Test 1（50% 和 20% 写入）中，单分片 Redis 分别获得 128K 和 129K TPS，而在 Test 2 中，我们看到相同模式的性能有所提高（是的，通过打开 AOF），得分为 150K 和 164K TPS。

因此，虽然多分片 Redis 设置神秘地受到 AOF 活动的影响（无论如何，这不应该发生在只读场景中），但即使在写入时，相同的 AOF 设置实际上也提高了单分片配置的性能。 这要么是一个悖论，要么是一些肮脏的巫术，要么是神圣干预的行为——我不相信。

关于 AOF 的使用，一种常见的做法（也在我们的 Redis 部署中使用）是让从属 Redis 实例处理持久性考虑因素，以减轻主节点的负载。 我只能假设 Redis 的这种最佳实践没有被使用，因为 SSD 优化的多线程数据库的处理方式不同。

比较很难做对，也很容易做错，而投入到这项工作中的努力是值得注意的。 我尊重 Aerospike 的工程师发现并分享了这么多有用的网络调整，并且非常感谢整个团队尝试对 Redis 进行分片。 但我认为，最终结果有些不足，并且留下了太多的悬而未决的问题。