自动分层为大型数据集提供两倍的吞吐量，延迟降低一半

越来越多的应用程序依赖于庞大的数据集合 - 而且这些应用程序必须快速响应。Redis Enterprise 7.2 使得无需开发人员额外工作即可创建超高速应用程序。还有什么可挑剔的呢？

组织一直依赖于其收集的数据，但这些数据集正在增长 - 特别是在分析密集型市场，例如电子商务、金融、基于位置的计算和高端游戏。例如，在医学图像分析研究中，数据集的中位数规模在 2011 年至 2018 年间增长了三到十倍。

Redis 受欢迎的原因之一是它提供了极其快速的数据访问。它通过将数据存储在内存中来实现这一点，因此应用程序可以以最快的速度检索和操作数据。应用程序需要处理的数据越多，存储数据集所需的内存就越多。尽管如此，即使从其提取数据的存储库非常庞大，这些应用程序也必须以近乎即时的速度响应。

问题：内存是有限的且昂贵的

当应用程序访问的数据量以 TB 为单位时，开发人员必须应对内存中处理的局限性。因此，他们转向基于磁盘的解决方案来在幕后支持 Redis。这样做迫使开发人员在应用程序中构建整个数据管理系统，这意味着他们将时间花在无关紧要的任务上，而不是他们最初的目标，即提供高性能的应用程序。

必须有更好的选择。确实有。

使用 Redis Enterprise 的自动分层，开发人员可以通过将固态磁盘 (SSD) 作为可用内存的一部分，将大容量数据库扩展到集群中现有 DRAM 的限制之外。通过利用我们巧妙的编程，Redis Enterprise 识别出哪些数据应该在内存中，哪些数据应该在任何给定时刻保留在 SSD 上，使吞吐量翻倍并将延迟降低一半，而之前的解决方案则无法实现。

一切都自动完成。开发人员无需编写额外的代码或学习另一项新技术。通过将动态 RAM 与快速的外部存储相结合，Redis Enterprise 使得轻松高效地使用系统资源，同时仍然可以快速访问经常访问的数据。

自动分层的工作原理

自动分层自动管理数据。它将变得热门的数据提升到 DRAM 中，并智能地将未使用的數據降级到 SSD 中。这为依赖于大型数据集合的应用程序开辟了新的可能性。

快速获取大型数据集中的数据并不是唯一的好处。节省资金是另一个优势 - 也是财务部门理解的原因。内存中存储可能很昂贵。通过将访问频率较低的数据卸载到 SSD，开发人员可以优化内存使用并降低与高容量内存需求相关的成本。

实际上，这使数据密集型应用程序在没有开发人员额外工作的情况下运行得更快。与仅使用 DRAM 的部署相比，它还节省了高达 70% 的基础设施成本。而且，由于自动分层高效且自动地管理数据访问模式，因此您无需花费周期（计算或人类大脑方面）来识别热数据与温数据。

Auto tiering improves TCO by combining DRAM and SSDs — 自动分层通过将 DRAM 和 SSD 相结合来提高 TCO

为了提升此功能，Redis 与Speedb 建立了战略合作伙伴关系，Speedb 是一款创新的键值存储引擎。我们将它的技术集成到默认的自动分层引擎中。

通过集成 Speedb，Redis Enterprise 在性能方面取得了显著提升，吞吐量翻倍，延迟降低一半，同时使用相同的资源。这极大地扩展了可以利用自动分层优势的用例范围。在此改进之后，使用自动分层的数据库的 Redis Enterprise 规模已增加到每个核心 10k 次操作/秒。

Double the core throughput with auto tiering — 使用自动分层将核心吞吐量提高一倍

有多快才算快？

当然，我们使吞吐量翻倍，并将延迟降低了一半，但数字只说明了故事的一部分。示例很重要。

以下图形显示了自动分层在实际工作负载场景中的性能演变示例。蓝色条形图表示使用之前存储引擎 (RocksDB) 的 Redis Enterprise 6.4，红色条形图表示使用 Speedb 的 Redis Enterprise 7.2。对于基础设施，我们使用 I4i.8xlarge AWS 实例来托管 1 TB 数据库，数据库分布在 10 个分片上，并进行复制以实现高可用性，总共 20 个分片，为 1,024 个客户端提供服务。

为了模拟最标准的 Redis 用例，我们定义了两种不同的有效负载，1KiB 和 10KiB，在 20% DRAM 和 80% SSD 的配置下，使用三种可能的用例模式：平衡读写（1:1）、读密集型（1:4）和写密集型（4:1）。在这两种情况下，我们都测量了每秒操作的吞吐量以及相应的延迟。以下图表显示了结果。

Auto tiering throughput results with 1KiB values — 使用 1KiB 值的自动分层吞吐量结果

与 RS 6.4（RocksDB）相比，RS 7.2（Speedb）提高了

85% 命中率：操作/秒提高了 1.4 倍至 1.6 倍，同时延迟降低了 2.4 倍
50% 命中率：操作/秒提高了 1.9 倍至 2.3 倍，同时延迟降低了 3.8 倍

Auto tiering throughput results with 10KiB values — 使用 10KiB 值的自动分层吞吐量结果

与 RS 6.4（RocksDB）相比，RS 7.2（Speedb）提高了

85% 命中率：操作/秒提高了 2.3 倍至 3.0 倍，同时延迟降低了 3.0 倍
50% 命中率：操作/秒提高了 2.1 倍至 3.5 倍，同时延迟降低了 3.5 倍

在所有情况下，使用 Speedb 的 Redis Enterprise 7.2 都具有更高的吞吐量，这意味着应用程序更快，并且维持这种性能水平所需的基础设施更少。

自动分层发挥作用的地方

自动分层特别适用于将数据分为热数据和温数据的场景。一个例子是需要访问最新数据和历史数据的银行应用程序。

让我们仔细看看移动银行应用程序的示例。

如今，每个人都在他们的移动设备上都有一个银行应用程序。用户登录应用程序，获取余额，查看最后一次交易，并获取其他相对较小且集中的信息。每个人都希望这个过程流畅、简单且即时。这些数据就是我们的热数据，驻留在 Redis Enterprise 数据库的 DRAM 中。

不太频繁地，用户需要额外的信息，例如旧交易的记录 - 也许是两年前的税务文件。它需要可访问，但数据访问速度不是那么关键。此数据集就是我们的温数据，可以保留在 SSD 中。

速度在其他行业也很重要。例如，游戏应用程序对延迟有严格的要求。此外，由于其本质，游戏具有趋势性。随着时间的推移，游戏公司会积累用户数据，这些数据存储在配置文件数据库中。但并非所有用户都是活跃用户。使用自动分层，活跃用户的配置文件信息可以驻留在 DRAM 中，而其他用户的配置文件信息可以驻留在 SSD 中。