Amazon 云上 NoSQL 基准测试遗漏的经验教训（AerospikeDB 和 Redis）

履行了 Aerospike 上周的 承诺，昨日 Aerospike 公布了 Lynn Langit 完成的基准测试结果，题为“经验教训 - 在 AWS 云上比较 NoSQL（AerospikeDB 和 Redis）”。Redis 的创建者 Salvatore Sanfilippo 在“为什么我们没有与其他数据库比对的基准”一文中发布了回应，他在文中描述了进行“比较‘广告’”的一些弊端，并提供了从 Redis 那里获得更好结果的一些方法。

基准测试明确表明：在一些读写混合中，Redis 和 AerospikeDB 均可用作“愚蠢的”键值存储，并且从每个服务器的吞吐量来看，其本质上可提供相同的值。那么除了类似的性能外，还有什么呢？嗯，Aerospike 自豪地宣称拥有一个良好的 UI 和友好的自动化（而且我已看到 Redis 的类似做法 :)），但昨天的基准测试仍留下了一些悬而未决的问题。

为什么基准测试不使用传统、推荐的 Redis 实践（例如流水线处理和多键操作）？我想这是因为 Aerospike 没有这些实践的等效项，并且不得求助于简单的 GET/SET 操作，基本上测量网络（以及操作系统）而不是该技术的真正功能。另一个遗漏的部分是 20%-80% 的读/写测试 (-w RU, 20) 和 100% 的写测试 (-w RU, 0)。我怀疑这类运行的结果不会与基准测试的结果吻合。

无论如何，为什么有些观点根本不成立？例如，Lynn 在测试 1 和测试 2 中，针对分片的 Redis 得出的 100% 读取模式的结果。在第一个测试中，配置获得 928K TPS 的分数，而在第二个测试中，仅为 860K - 这一下降完全无法解释为因为她使用了 AOF。即使在测试 2 中启用了 AOF，Redis 也仅在响应数据（又称写）的更改时访问磁盘，因此对于只读流量，AOF 的影响应为 0%。这本身就很令人费解，但这里有另一个疑点：她的基准测试发现，受 EBS 支持的 Redis 实际上比仅受 RAM 支持的 Redis 服务器性能更好 - 再次比较测试 2 和测试 1 的永不写入分数，针对单个分片 Redis，分别为 180K 和 132K TPS。

在测试 1 和测试 2 中对比具有单个分片的 Redis，当写成为流量的一部分时，惊喜继续。在测试 1（50% 和 20% 写）中，具有单个分片的 Redis 分别得到 128K 和 129K TPS，而在测试 2 中，我们看到同样的模式性能提升（没错，通过启用 AOF），分数为 150K 和 164K TPS。

因此，当具有多扇区的 Redis 设置神秘地受到 AOF 活动的影响（在任何情况下，这都不应在只读情形中发生）时，相同的 AOF 设置实际上提高即使有写入内容的单一扇区配置的性能。这是一个悖论、某种肮脏的巫术或神圣的干预行为，但我并不相信这一点。

关于 AOF 的使用，一种常见做法（在我们的 Redis 部署中也采用这种做法）是让一个从式 Redis 实例处理持久性考虑因素，以减轻主机的负载。我只能认为，这是因为经过 SSD 优化的多线程数据库是与众不同的，因此并未使用 Redis 的此项最佳实践。

进行比较既难做对，又容易做错，为此本报告投入的精力十分显著。对于 Aerospike 的工程师来说，我十分敬佩他们发现了许多有用的网络调整，并分享了出来，也十分感激整个团队对分片 Redis 所做的尝试。但在我看来，最终结果有点欠缺，简单来说就是遗漏了太多细节。