【虹科干货】Redis Enterprise 自动分层技术:大数据集高性能解决方案

越来越多的应用程序依赖于庞大的数据集合,而这些应用程序必须快速响应。借助自动分层,Redis Enterprise 7.2 帮助开发人员轻松创建超快的应用程序。何乐而不为?

Redis将数据存储在内存中,因此应用程序能以最快的速度检索和处理数据。然而,随着应用程序需要处理的数据越多,存储数据集所需的内存越大,所耗费的成本则更高,Redis Enterprise自动分层技术能很好地化解这个两难的局面。

一、问题:内存有限且昂贵

当应用程序访问的数据量很大,例如达到TB级时,开发人员就面临着内存有限的问题,他们一般使用基于磁盘的解决方案来在幕后支持Redis。这样一来,开发人员就不得不在应用程序中构建整个数据管理系统,这意味着他们要把时间花在不相干的任务上。

利用Redis Enterprise的自动分层功能,开发人员可以使用固态硬盘(SSD)作为可用内存的一部分,将大容量数据库扩展到SSD中。Redis Enterprise可以随时识别哪些数据应留在内存中,哪些数据应留在固态硬盘上,从而将吞吐量提高一倍,并将延迟减半。

因此,开发人员无需编写额外的代码或学习其他新技术。通过将动态RAM与速外部存储相结合,Redis Enterprise可以轻松高效地使用系统资源,同时还能快速访问数据。

二、自动分层的工作原理

自动分层可自动管理数据。它会将热数据转移到DRAM,并智能地将未使用的数据转移到SSD。这为依赖大型数据集的应用带来了新的可能性。

通过将访问频率较低的冷数据转移到固态硬盘,开发人员可以优化内存使用,降低与大容量内存需求相关的成本。

实际上,这可以使数据量大的应用程序运行得更快,而无需开发人员额外付出。与仅使用DRAM 的部署相比,它还能节省高达 70% 的基础硬件设施成本。而且,由于自动分层可以高效地自动管理数据访问模式,因此您无需花费时间(计算或人工筛选)来识别热数据和冷数据。


为了增强这一功能,Redis 与创新的键值存储引擎 Speedb 建立了战略合作伙伴关系。我们将其技术整合为默认的自动分层引擎。

集成Speedb 后,Redis Enterprise 的性能显著提升,在访问相同资源的情况下,吞吐量翻倍,延迟减半。这大大拓宽了可利用自动分层优势的用例范围。在这一改进之后,Redis Enterprise 使用自动分层的数据库规模由每个内核5k ops/秒增至10k ops/秒。


通过自动分层使核心吞吐量加倍

三、数据案例

我们来看一个案例。

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

为了模拟最标准的Redis 用例,我们在 20% DRAM 和 80% SSD 的配置上定义了两种不同的有效载荷(1KiB 和 10KiB),并提供了三种可能的使用模式:平衡读/写(1:1)、重读(1:4)和重写(4:1)。在这两种情况下,我们测量了以每秒操作数为单位的吞吐量和相应的延迟。以下图表显示了结果。


RAM/SSD数据占比2:8,单次操作1KB值

与RS 6.4 (RocksDB) 相比,RS 7.2 (Speedb) 改进了:

· 85% 命中率时:每秒操作次数增加1.4 倍至 1.6 倍,同时延迟降低高达 2.4 倍

· 50% 命中率时:每秒操作次数增加1.9 倍至 2.3 倍,同时延迟降低高达 3.8 倍


RAM/SSD数据占比2:8,单次操作10KB值

与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 都具有更好的吞吐量,这意味着维持这种性能水平所需的应用程序速度更快,基础设施更少。

四、应用场景

自动分层尤其适用于将数据分为热数据和冷数据的情况

1.移动银行

让我们来看看移动银行应用的例子。

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

用户希望获得更多信息的情况并不常见,例如旧交易记录--也许是两年前的税务数据。用户需要访问这些数据,但数据访问速度并不那么重要。这种数据集是我们的冷数据,可以保存在高速外部存储如固态硬盘中。

2.游戏行业

速度在游戏行业也很重要。例如,游戏应用对延迟有严格要求。另外,从本质上讲,游戏是一种潮流。随着时间的推移,游戏公司会积累越来越多的用户数据,并将其存储在用户资料数据库中但并非所有用户都是活跃用户。通过自动分层,活跃用户的资料数据可以存储在DRAM 中,而其他用户的数据则存储在 SSD 中。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,542评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,822评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,912评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,449评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,500评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,370评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,193评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,074评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,505评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,722评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,841评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,569评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,168评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,783评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,918评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,962评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,781评论 2 354

推荐阅读更多精彩内容