自动分层

自动分层使您的数据能够跨越RAM和专用闪存。

Redis Enterprise的自动分层技术为用户提供了使用固态硬盘(SSD)扩展数据库超出DRAM容量的独特能力。 开发者可以使用相同的Redis API构建需要大数据集的应用程序。 与仅使用DRAM部署相比,使用SSD可以显著降低基础设施成本。

经常使用的数据,称为热数据,应存放在最快的存储层级中,以提供实时的用户体验。 访问频率较低的数据,称为温数据,可以存放在稍慢的存储层级中。 Redis Enterprise的自动分层功能将热数据保持在DRAM中,将温数据存放在SSD中,并自动在层级之间传输数据。

Redis Enterprise的自动分层基于高性能存储引擎(Speedb),该引擎管理使用SSD和DRAM作为Redis Enterprise集群中数据库总可用内存的复杂性。此实现提供了每核心数据库每秒高达10k操作的性能提升,使Redis on Flash的性能翻倍。

就像全内存数据库一样,启用自动分层的数据库与现有的Redis应用程序兼容。

自动分层也支持在Redis CloudRedis Enterprise Software for Kubernetes上。

使用案例

自动分层的好处取决于使用情况。

自动分层在以下情况下是理想的:

  • 工作集明显小于您的数据集(高RAM命中率)
  • 平均键大小小于平均值大小(所有键名都存储在RAM中)
  • 最近的数据是最常用的(高RAM命中率)

自动分层不推荐用于:

  • 长键名(所有键名都存储在RAM中)
  • 广泛的访问模式(任何值都可能被拉入RAM)
  • 大型工作集(工作集存储在RAM中)
  • 频繁移动的数据(频繁在RAM中来回移动可能会影响性能)

自动分层不适用于持久存储。Redis Enterprise Software 数据库的持久存储和临时存储应位于不同的磁盘上,无论是本地磁盘还是附加磁盘。

我的数据在哪里?

使用自动分层时,RAM存储包含:

  • 所有键(名称)
  • 关键指标
  • 字典
  • 热数据(工作集)

所有数据都通过RAM访问。如果访问了闪存中的值,它将成为工作集的一部分并被移动到RAM中。这些值被称为“热数据”。

不活跃或不常访问的数据被称为“温数据”,并存储在闪存中。当RAM中需要更多空间时,温数据会从RAM移动到闪存存储。

注意:
当使用自动分层与RediSearch时,需要注意的是RediSearch索引也存储在RAM中。

RAM与Flash的比例

Redis企业版软件允许您独立配置和调整每个数据库的RAM与Flash的比例,以优化特定用例的性能。 虽然这是一个在线操作,不需要数据库停机,但建议在维护窗口期间执行,因为数据可能会在层级之间移动(RAM <-> Flash)。

RAM限制不能小于总内存的10%。我们建议您至少保留所有值的20%在RAM中。不要将RAM限制设置为100%。

闪存

实施自动分层需要对内存和大小进行预先规划。自动分层的考虑和要求包括:

  • 闪存必须本地连接(与网络附加存储(NAS)和存储区域网络(SAN)相对)。
  • 闪存必须专用于自动分层,不能与数据库的其他部分共享,例如持久性、二进制文件或持久化。
  • 为了获得最佳性能,SSD 应基于 NVMe,但也可以使用 SATA。
  • 可用的闪存空间必须大于或等于数据库的总大小(RAM+闪存)。额外的空间用于写缓冲区和写放大
注意:
Redis Enterprise Software 数据库的持久性和临时性存储应位于不同的磁盘上,无论是本地磁盘还是附加磁盘。

一旦满足这些要求,您就可以在同一集群中创建和管理启用了自动分层功能的数据库以及全内存数据库。

当您开始计划在生产环境中部署支持自动分层的数据库时,我们建议与Redis技术团队密切合作,进行容量规划和性能调优。

云环境

在云环境中运行时:

  • 闪存位于云实例的临时SSD上(例如AWS i4i实例和Azure Lsv2和Lsv3系列的本地NVMe)。
  • 持久数据库存储需要网络附加(例如,AWS 的 AWS EBS)。
注意:
我们特别推荐“Storage Optimized I4i - High I/O Instances”,因为NVMe在闪存上的性能表现优异。

本地环境

当您开始计划在生产环境中部署自动分层时,我们建议与Redis技术团队密切合作,进行容量规划和性能调优。

本地环境支持比其他环境更多的部署选项,例如:

注意:
为Active-Active分布式数据库启用自动分层需要先进行验证并获得Redis技术团队的批准。
警告:
自动分层不支持在网络附加存储(NAS)、存储区域网络(SAN)或本地HDD驱动器上运行。

下一步

RATE THIS PAGE
Back to top ↑