• Redis 提供的持久化方案行不通了吗?
  • 发布于 2个月前
  • 521 热度
    0 评论
  • 顾及谁
  • 24 粉丝 32 篇博客
  •   
大数据时代,数据体量和复杂性对于数据库提出更高要求,仅依靠关系型数据库难以处理这些数据,非关系型数据库得以快速发展壮大。主流的的非关系型数据库有Redis、Memcache、MongoDB、HBase 等。

为了满足广泛的业务场景对于数据库提出的高可用、高效率、高可扩展性的要求,Redis 的应用场景也早已突破了缓存的范畴,并提供了持久内存的解决方案。业务数据量爆炸式增长,Redis 的内存消耗在不断增加。这意味着,作为一个基于内存的数据库,Redis 的内存是否被高效合理的利用至关重要。在持久内存的主流思路下,是否有一种方案可以平衡企业对于性能、成本、持久化和规模的需求?

Redis 提供的持久化方案行不通了吗?
我们先来系统看下 Redis 提供的 AOF 和 RDB 两种持久化方案。AOF 可以通俗地理解为日志记录,将每一个收到的写命令都通过 write 函数追加到文件中,好处在于写入性能高,没有磁盘寻址的开销,后台重写不影响客户端读写,秒存的方式能够紧急恢复误删的数据,但劣处在于日志文件过大,写 QPS 相对低,数据恢复不能保证 100%实现。

RDB 的持久化通过在指定的时间间隔内将内存中的数据集快照写入磁盘来实现。生成 RDB 文件时,Redis 主进程不需要进行任何磁盘 IO 操作,通过子进程来进行保存,适合进行备份和灾难恢复,并且恢复速度比 AOF 更快。但 RDB 也有自己的局限,正是因为保存动作由子进程来实现,所以在快照持久化期间修改的数据不会被保存,丢失数据的可能性变大。

所以 Redis 4.0 提出了混合式持久化策略,取两种方案的优点,但兼容性不佳。如果从内存消耗的角度来看,Redis 内存消耗主要在于其主进程的自身内存、对象内存、缓冲区内存、内存碎片方面,和子进程的 AOF/RDB 重写时的内存消耗。通过优化管理 Redis 内存的使用,达到用更少的内存存储更多数据、节省成本的目的,才能真正实现 Redis 的高性能和高可用,但难以从根本上缓解内存消耗大带来的成本压力问题。业内也有一些基于磁盘的 KV 存储产品,例如 Pika、Kvrocks、SSDB 等,难比 Redis 的性能。

行业内有句话,软件优化三年不如硬件更新一代。Redis 提供的持久化方案是软件角度的解决方案,或许我们可以从硬件角度来找到解决内存成本、容量限制以及持久化等一系列问题的方法。 

从硬件的角度能否优化持久内存?
英特尔®傲腾™持久内存(PMem)和 Redis 的结合提供了一个思路。传统的内存和存储架构中,通过 DRAM 内存直接访问存储设备,虽然快但是容量有限,成本也高,并且无法做到持久内存。持久内存处在内存 DRAM 和外存(HDD 或者 SSD)之间,性能优于外存输于内存,既可以当做内存使用,也可以当做持久化外存设备使用。英特尔®傲腾™持久内存通过在 DRAM 内存和块存储之间加入大容量持久内存层,提供了接近 DRAM 内存的性能、更大的存储容量、降低了数据的易失性。

英特尔®傲腾™持久内存(PMem)和 Redis 的结合一度被业内视为“天作之合”。但是仅仅基于内存的 Redis 依然给企业带来了不小的成本压力。传统数据库的设计原则中,默认以存储 IO 为瓶颈进行设计。而英特尔®傲腾™持久内存(PMem)存储模式优化,主要解决的就是外部数据存储 IO 性能瓶颈的问题。云时代高并发场景下大量的 IOPS,也要求数据存储找到新的解决方案。

腾讯云数据库团队一直在寻找让 Redis“快和低成本兼具”的优化方案,曾推出 Redis4.0 集群版解决方案。为了进一步释放英特尔®傲腾™持久内存(PMem)的性能,如今,腾讯云数据库团队基于全新的架构设计思路推出了首款软硬件结合、高速低延迟的 NoSQL 数据库产品——KeeWiDB 键值数据库,提供了高性能、低成本的分布式 KV 存储方案。

据悉,KeeWiDB 整体架构由代理层和服务层两个部分构成,代理层负责与客户端进行交互,服务层负责数据的存储以及在机器发生故障时可以自动进行故障切换。

值得关注的是,KeeWiDB 服务层后端集群架构的具体实现上参考了 Redis 的集群模式,用多个分片和节点实现一主多从的高可用架构,并通过每个分片的主节点 Slot 数据实现弹性扩缩容。据悉,KeeWiDB 的设计目的,就是为了解决 Redis 的痛点问题,目标实现更大容量,更高性能以及更低延迟。所以与 Redis 的数据存储在内存中不同,KeeWiDB 的数据主要存储在持久内存(PMEM)和固态硬盘(SSD)上。

KeeWiDB 采取了“内存(DRAM)+持久内存(PMEM)+固态硬盘(SSD)”分级存储的架构设计,根据数据访问热度自动分级、自动升热降冷,将不同的同访问密度的数据存储到不同成本的介质中,预期在实现高性能和低延迟的同时,提高性价比。

以查询操作为例,如果查询操作命中 DRAM 中存储的少量高速索引,则最多仅需要一次 IO 就可以定位到 value 的位置;如果没有命中,才会通过 PMEM 来做热数据的查找;如果依然没有命中,才会从 SSD 中读取冷数据。这意味着在主要读的场景下,KeeWiDB 的性能优势将更加明显。

值得关注的是,在写入方面,KeeWiDB 采用了英特尔®傲腾™持久内存(PMem)作为高速写入的存储介质,通过持久内存对数据进行实时持久化,延迟相对 SSD 降低了 2 个数量级,IO 更少吞吐更高;在读取方面,KeeWiDB 自研了一个基于 Hash 存储的 KV 引擎,而 Hash 结构和 KV 存储在数据模型、访问模型上天然的匹配。

在文件操作场景,从大容量低成本的角度出发,KeeWiDB 将数据文件存放在 SSD 上,在处理用户请求期间不再直接操作 SSD 上的数据页,而是操作读写延迟更低的 PMem,使数据库的性能和吞吐量得到了进一步的提升。

为了避免日志文件在写入的过程中涉及到的持久化操作有可能会成为整个系统的瓶颈,KeeWiDB 通过将 WAL 存放在 PMem 上,可以大幅降低日志持久化操作耗时。由于 PMem 比 SSD 更快的读写速度,数据库整体的故障恢复速度也得到了大幅提升,进而提升了整个系统的可用性。

来自腾讯云的压测数据显示,KeeWiDB 在长时间压测中,P99 和 P99.9 都保持非常稳定且达到个位数的响应延迟;吞吐量方面,KeeWiDB 的延迟始终能保持在 12 万以上,比基于 RocksDB 方案要高 50%以上。KeeWiDB 完全兼容 Redis 协议,使用 Redis 的业务无需修改任何代码便可以迁移到 KeeWiDB 上。原生分布式架构,让 KeeWiDB 可以提供百 TB 级的存储容量,并且支持水平扩展。

总体而言,KeeWiDB 实现了:
性能(单节点):28 万读取,18 万写入,P99<2ms 可水平堆叠,性能线性提升;
成本:分级存储,冷数据成本下降 97%;
持久化:命令级持久化;毫秒级稳定写入延迟;SSD 提供低成本持久化;
大容量:单节点提供 TB 级容量空间;集群方式提供 128TB 容量空间。

虽然第四代英特尔®傲腾™持久内存不再开发有些遗憾,但是第四代英特尔®至强®可扩展处理器(Sapphire Rapids)将内置一系列加速器,包括新的指令集架构和集成 IP,能够高效应对人工智能、数据分析、网络、存储和其他高需求的工作负载,为提升软硬件性能提供了灵活的解决方案。

出色的数据库性能优化离不开计算、网络、存储以及监控运维等各方面技术优化,腾讯云数据库依托英特尔在硬件平台、架构层、应用层提供全栈优化的技术支持:除了前文提到的持久内存,在计算层面,英特尔至强处理器内置的密码操作加速,可以把数据库上的加密负载卸载到专用芯片上,从而降低 CPU 的负载,提高整体吞吐量。同时,在软件平台优化、参考架构设计、性能测试验证和创新技术应用方面,英特尔和腾讯云数据库团队展开了全面的合作,构筑了坚实的技术创新基座。 

NoSQL 数据库需要更加灵活易用
无论是对于持久内存方案的探索,还是对于硬件性能的进一步挖掘,都是为了打造一款更加灵活易用的 NoSQL 数据库,满足业务场景的需求。从电商、游戏、直播、短视频等一系列移动端应用场景的发展态势来看,“高并发、低延迟、低成本”的需求只会越来越旺盛。

无论是因“快”备受追捧的 KV 数据库 Redis,还是用文档取代关系型数据库的表格后,赋予数据更大的灵活性的 MongoDB,都在试图将 NoSQL 数据库在架构层面进一步提升高并发、易扩展和灵活易用等特性,服务海量并发访问和大数据业务场景。

随着数字化转型在企业内部的进一步深入,大量的数据被分层,海量语音、图像视频等非结构化的数据亟待被挖掘价值,将推动 NoSQL 数据库拥有更细颗粒度和更高水平的技术创新出现。NoSQL 数据库需要更加灵活易用,也将朝着更加灵活易用的方向发展。
用户评论