Redis on Flash：现在使用新型数据引擎和 Amazon EC2 I4i 实例快 3.7 倍

Redis on Flash (RoF) 一直是我们的最受欢迎企业级功能之一，它通过将高达 80% 的数据集存储在固态硬盘 (SSD) 中，而不是昂贵的 DRAM 中来让内存计算变得更具性价比，同时仍保持低于毫秒级的延迟和 Redis 的高吞吐量。在典型部署中，RoF 可以提供高达 70% 的总体拥有成本 (TCO) 折扣。 

现在，通过与两家令人兴奋的新公司合作，我们自豪地宣布，RoF 现在可以在大型数据集上运行 Redis 的同时，提供高达 3.7 倍的性能，同时保持同样的具有吸引力的总体拥有成本。首先，AWS 宣布推出新一代实例的公测版，Amazon EC2 I4i，它由第 3 代英特尔至强可扩展处理器（代号为 Ice Lake）和基于 AWS Nitro SSD NVMe 的存储提供支持。这一新一代承诺为数据密集型 Redis 客户提供显著的性能提升。此外，我们很高兴地分享我们的计划，即向任何兼容 RocksDB 的数据库开放 RoF 的数据引擎，首先是 Speedb 的新公布技术。 

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

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

让我们深入了解 RoF 的新增功能。AWS 在 4 个区域提供新的 Amazon EC2 I4i（“i”代表英特尔）实例。I4i 实例使用最新技术，即英特尔 Ice Lake 处理器和 AWS Nitro SSD，与上一代 I3 实例相比，它提高了 IOPS 并降低了延迟。 

除了硬件之外，我们一直在寻找 RoF 可以提供更高性能的方法，并找到了一个机会，让客户和企业家对数据引擎进行创新。我们很高兴地宣布，RoF 现在向任何RocksDB 兼容数据引擎开放，而 Speedb 是 Redis 提供的第一个替代方案。Speedb 团队与我们合作，重新设计了 RocksDB 内部数据结构，显着提高了性能和可扩展性，同时减少了 CPU 资源。

在本博文中，我们分享了 Speedb 如何在我们的亚毫秒测试中提供高达 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 用例是批数据处理，它需要通过关键业务应用程序处理海量数据，并且需要随着时间的推移保持稳定的低延迟和高吞吐量。

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

我们的基准测试对象

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

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 个副本分片

在每种配置中，我们测试了在保持亚毫秒级客户端延迟（不包括网络）的情况下，能够实现多少次操作/秒

我们的发现

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

我们可以看到以下改进

下图显示了使用 Speedb 和不同读写比率在 I4i 上进行扩展的情况

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

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

4xlarge → 8xlarge 的系数约为 1.55 倍到 1.8 倍
8xlarge → 16xlarge 的扩展系数约为 1.85 倍到 1.95 倍

第二个值得注意的结果是，使用 Speedb 在 I4i 上的 RoF 对应用程序访问模式（读写比率）几乎没有任何差别。这意味着性能保持稳定且可预测。当使用多个不同的应用程序或访问模式随时间而变化时，这可能很有用。 

下图显示了整体 3.7 倍性能改进

附录
基准测试设置

Redis Enterprise 版本：Ubuntu 18.04 上的 v. 6.2.8-39
使用 Flash 数据库的 Redis：参见上面每实例的详细信息
客户端机：EC2 m5.8xlarge（32 个 VCPU，128 GB RAM）
负载生成工具：memtier 基准测试

用于 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}

设置说明

---