Redis on Flash：借助新数据引擎和 Amazon EC2 I4i 实例，现在提速 3.7 倍

Redis on Flash (RoF) 一直是我们最受欢迎的企业版功能之一。它通过将高达 80% 的数据集存储在 SSD 而不是昂贵的 DRAM 中，使得内存计算具有成本效益，同时仍保持 Redis 的亚毫秒级延迟和高吞吐量。在典型部署中，RoF 可降低多达 70% 的总拥有成本 (TCO)。 

现在，通过两项激动人心的新合作，我们自豪地宣布 RoF 现在可提供高达 3.7 倍的性能，同时为在 Redis 上运行大型数据集保持同样吸引人的总拥有成本。首先，AWS 宣布推出新一代实例 Amazon EC2 I4i 的正式可用性，该实例由第三代 Intel Xeon Scalable 处理器（代号 Ice Lake）和基于 AWS Nitro SSD NVMe 的存储提供支持。新一代实例有望为数据密集型 Redis 客户带来显著的性能提升。此外，我们也很高兴分享我们的计划：将 RoF 的数据引擎开放给任何 RocksDB 兼容数据库，其中 Speedb 新宣布的技术是首选方案。 

我们相信，新的 I4i 实例与为客户提供数据引擎选择的结合，将使 RoF 对于海量数据集更具吸引力，因为构建现代化应用或低延迟微服务架构的公司对实时体验的需求不断增加。

Amazon EC2 I4i 和 Speedb 为 Redis on Flash 带来了什么？

让我们深入了解 RoF 的新变化。AWS 正在 4 个区域提供新的 Amazon EC2 I4i（“i”代表 Intel）实例。I4i 实例采用最新技术，包括 Intel Ice Lake 处理器和 AWS Nitro SSD，与上一代 I3 实例相比，可提高 IOPS 并降低延迟。 

除了硬件之外，我们一直在寻找能让 RoF 提供更卓越性能的方法，并发现了一个机会：将数据引擎开放给客户和企业家的创新。  我们很高兴地宣布，RoF 现在支持任何 RocksDB 兼容的数据引擎，Speedb 是 Redis 提供的首个替代方案。通过与我们合作，Speedb 团队重新设计了 RocksDB 的内部数据结构，这显著提高了性能和可扩展性，同时减少了 CPU 资源。

在这篇博文中，我们分享了 Speedb 在我们的亚毫秒级测试中与 RocksDB 相比如何实现近 50% 的显著性能提升，无论我们使用的是 AWS EC2 I4i 还是 I3 实例。 

采用 Speedb 的 RoF 目前正处于私有预览阶段。Redis 客户可以联系其客户团队获取更多信息或试用新服务。

新版 Redis on Flash 基准测试

我们的性能工程师迫不及待地想亲自测试 AWS 的 I4i 实例以及 RoF 的新 Speedb 数据引擎。我们很高兴成为第一家全面测试 Amazon EC2 I4i 实例的 AWS 合作伙伴。在此提醒，RoF 会智能地对大型数据集进行分级存储，旨在利用 NVMe SSD 每 GiB 比 DRAM 便宜的优势。这使得我们能够提供 Redis 级别的性能，现在通过 I4i 实例变得更快，而总拥有成本仅为基于 DRAM 实例的 30%。 

在开始讨论基准测试结果和数据之前，让我们先回顾一下客户应该何时考虑使用 RoF。我们开发 RoF 旨在解决以下用例：工作数据集小于总数据集，并且增加 DRAM 成本过高。另一个常见的 RoF 用例是批量数据处理，其中需要为业务关键型应用程序处理大量数据，这些应用程序需要随着时间的推移保持稳定的低延迟和高吞吐量。

现在进入有趣的部分：基准测试结果。

我们的基准测试内容

我们比较了 Redis on Flash 在四种 AWS 实例上的性能

i3.8xlarge – 244GB RAM, 4块 NVMe SSD 硬盘，总计 7.6TB
I4i.4xlarge – 128GB RAM, 1块 NVMe SSD 硬盘，总计 3.75TB
I4i.8xlarge – 256GB RAM, 2块 NVMe SSD 硬盘，总计 7.5TB
I4i.16xlarge – 512GB RAM, 4块 NVMe SSD 硬盘，总计 15TB

我们比较了两种数据引擎的性能

• RocksDB
• Speedb

测试参数

我们使用 1KiB 的值大小，涵盖了大多数标准 Redis 用例
我们测试了 50% 和 85% 的 RAM 命中率（即许多请求直接从 RAM 提供服务）
我们测试了 20:80 的 RAM:Flash 比例
我们对各种读写比例进行了基准测试：1:1、4:1 和 1:4
所有测试均使用两台服务器完成
以下是我们根据实例类型运行的数据库大小

• I4i.4xlarge: 500GB + 复制。5 个主分片 + 5 个副本分片
• i3.8xlarge: 1TB + 复制。10 个主分片 + 10 个副本分片
• I4i.8xlarge: 1TB + 复制。10 个主分片 + 10 个副本分片
• I4i.16xlarge: 2TB + 复制。20 个主分片 + 20 个副本分片

在每种配置中，我们测试了在保持亚毫秒级客户端延迟（不包括网络）的情况下，可以达到多少 ops/秒

我们的发现

下图显示了 i3 与 I4i 以及 RocksDB 与 Speedb 的对比

我们可以看到以下改进

下图显示了在 Speedb 上的 I4i 实例在不同读写比例下的扩展性

我们可以看到以下结果和改进

从扩展性来看，我们可以看到在 Speedb 上使用 I4i 实例的 RoF 几乎呈线性扩展。

4xlarge → 8xlarge 的加速因子约为 1.55 倍-1.8 倍
8xlarge → 16xlarge 的扩展因子约为 1.85 倍-1.95 倍

第二个值得注意的结果是，在 Speedb 上使用 I4i 实例的 RoF 对应用程序访问模式（读写比例）非常不敏感。这意味着性能保持稳定且可预测。这在处理多个不同应用程序或访问模式随时间变化时非常有用。 

下图显示了总体 3.7 倍的性能提升

附录
基准测试设置

Redis Enterprise 版本：v. 6.2.8-39 on Ubuntu 18.04
Redis on Flash 数据库：请参阅上文各实例详情
客户端机器：EC2 m5.8xlarge (32 VCPUs, 128 GB RAM)
负载生成工具：memtier benchmark

85% RAM 命中率的 memtier 示例命令
^{memtier_benchmark -s <数据库主机 IP> -p <数据库端口>
–hide-histogram –pipeline=1 -c 4 -t 256  -d 1000
–key-maximum=771141855 –key-pattern=G:G –key-stddev=50358491
–ratio=1:1 –distinct-client-seed –randomize –test-time=1200}

设置图解

---