GaussDB(for Redis)与开源Redis有什么区别

云数据库GaussDB(for Redis)架构图介绍

① 全量数据落盘，GaussDB基础组件服务提供底层数据三副本冗余保存，0丢失

② 全部计算节点可写

③ 数据三副本强一致保障，多点访问无脏读

④ 完备的大规模集群管理能力，故障秒级接管，动态负载均衡

⑤ 存算分离架构，资源可弹性平滑扩缩容，业务几乎无感知

开源Redis Cluster 架构图介绍

① 数据分散保存到各个独立节点本地内存中；一对主备宕机=部分数据丢失

② 集群中一半节点是备，不可写

③ 主从异步复制，访问从节点数据会不一致

④ Gossip协议在集群规模过大时，效率显著下降

⑤ 容量扩缩容 = 物理节点数量变更，对业务影响大

适用业务场景对比

云数据库GaussDB(for Redis)开源Redis业务场景特点：① 关心重要数据安全② 关心系统稳定性，不希望高峰期间发生宕机③ 关心数据一致性数据量：- 数据量小场景，GaussDB(for Redis)提供更低成本- 数据量大场景，开源Redis难以胜任，GaussDB(for Redis)完美驾驭特点：① 对数据安全性要求低，接受核心数据丢失或被LRU挤出② 对稳定性要求低，接受OOM宕机发生③ 接受多点访问数据不一致数据量：- 往往只能用于数据量小、数据有效期短的业务

多维度深入对比

云数据库GaussDB(for Redis)开源Redis成本成本降低75%~90%全量数据落盘，采用GaussDB基础组件服务，拥有极大价格优势。硬件成本极高全部数据保存在纯内存介质中，且自身fork机制导致内存使用率低。最大容量支持PB级存算分离架构让存储资源自由扩容。同时计算层资源也可同步弹性伸缩，性能有保障。百GB级别开源Redis Cluster如果进一步增加数据量，一方面将导致硬件成本陡增难以承受，另一方面其内部Gossip集群管理效率将变得极低。容量利用率100%纯自研架构，不受fork问题影响，用户购买的持久化存储空间几乎全部可用。<50%开源Redis受独fork机制影响，在快照、主从复制、AOF重写期间，如遇业务高峰，理论上内存可增长一倍。因此，内存使用率控制在50%以内，才能确保安全规格选型1GB细粒度，随时按需调整档位不连续（...32G、48G、64G）假设业务数据量约30G。如选用云缓存Redis，考虑到安全有效容量<50%，只能选64G规格。造成“买多”浪费。数据压缩逻辑压缩+物理压缩结合，比开源Redis更省空间- 逻辑压缩：对value进行初步压缩- 物理压缩：对存储介质中的数据块整体进行二次压缩- 根据实际业务测试，string、hash等常用结构在GaussDB(for Redis)实例中，存储空间占用仅为开源Redis的70%~85%只使用逻辑压缩时延平均时延差距不大，p9999表现有一定差距平均时延较低，p9999时延较低抗写能力【强】多节点可以同时写入，且采用多线程架构，吞吐轻松翻倍【弱】集群中仅主节点可写，且属于单线程架构，业务高峰有OOM宕机风险数据可靠性【高】逐条命令实时落盘，底层三副本冗余存储，无数据丢失风险【低】内存数据秒级落盘，且主从异步复制不及时，存在数据丢失风险数据一致性【强一致性】实现三副本强一致，多点访问无脏读风险【弱一致性】主从异步复制，多点访问存在数据不一致问题可用性【强】即使N-1个节点同时故障，实例依然可用【中等】- 半数主节点发生宕机，集群将不可用- 任一对主从宕机，集群将不可用故障恢复分钟级恢复，且数据恢复时长与数据量大小无关在全量数据下沉存储的shared everything架构下，数据只需被可用节点接管即可，几乎不需耗时加载数据量越大，恢复耗时越久数据物理分散在多个独立节点上，故障恢复需要将RDB快照从磁盘加载进内存，耗时久负载均衡【支持】细粒度数据分片，节点间实现动态负载均衡【不支持】需要依赖第三方组件扩容【平滑扩容】- 节点扩容：分钟级完成，业务秒级感知- 容量扩容：秒级完成，业务0感知- share everything架构下，底层数据可被任一节点访问，扩容过程不发生数据拷贝搬迁，速度极快【耗时长，对业务影响大】- 各节点本地内存装载数据分片，迁移意味着新节点的加入以及数据的拷贝搬迁，耗时长安全【高】① 内核采用纯自研架构，不存在开源Redis安全漏洞问题。② 提供虚拟私有云、子网、安全组、DDoS防护以及SSL安全访问等多层安全防护体系，实现租户隔离和访问控制。① 开源Redis内核不定期会爆出安全漏洞问题，如CVE-2021-32761等。如版本升级不及时，随时有被恶意利用风险。② 网络环境安全级别取决于所使用的服务质量运维【一站式服务】成熟的迁移方案、实时监控、故障预警、7*24h内核团队支撑取决于所使用的服务质量