“多写多读集群”被攻克,中国数据库产业“越过山丘”

2023-12-29 06:04

本文主要是介绍“多写多读集群”被攻克,中国数据库产业“越过山丘”,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

2020年全国两会期间,合肥工业大学应用数学研究所所长檀结庆在媒体采访中提到:“国产数据库只占据不到7%的市场份额,尤其在数据库最核心的交易业务中,鲜有能跟甲骨文同台竞争并实现替换的产品。”

彼时“去IOE”浪潮已经兴起十多年的时间,但囿于性能、稳定性等客观因素,银行、能源、电信等传统业务,对国产数据库依然是“不敢用、不愿用、不想用”的态度,无形中为国产数据库产业制造了一个天花板。

现在,这样的景象正在成为过去式。

华为数据存储与优炫软件日前联合发布“数据库存算分离联合解决方案”,同时推出了高可靠、高性能共享存储多写多读集群数据库解决方案,旨在通过先进的存储技术和创新的设计,满足金融、运营商、能源、制造、政务等传统业务场景下的数据库替代需求。

放在数智化转型的语境下,这样的合作到底意味着什么,能否打破国产数据库产业的天花板?

01 国产数据库:百花齐放,多而不强
和操作系统、中间件等基础软件相比,数据库是国产替代最为迅猛的市场。然而外界对国产数据库的印象,看起来并不太乐观,用一句话来形容的话:数量上百花齐放,市场竞争力却只能说“多而不强”。

为何会出现这样的局面?外界的讨论有很多,并产生了两种主流观点。

一种说法是国产数据库的起点比较晚。

早在1978年,Oracle就推出了第一版数据库,那时候中国的信息化转型进程还无从谈起。2000年前后,国内出现了第一批数据库企业,但全球数据库产业已经走完了竞争、并购、退出的过程,形成了典型的IOE格局,I是指服务器提供商IBM,O是指数据库软件提供商Oracle,E则是指存储设备提供商EMC。

2014年后,在政策和市场红利的驱动下,国产数据库产业百花齐放,却未能改变Oracle、IBM等主导市场的格局,国产数据库只能占领一些缝隙市场。国产数据库的数量越来越多,结果却是高度的碎片化。

图:2023年墨天轮中国数据库排行榜每月收录数量

按照信通院与墨天轮的统计,目前国内有280多个数据库产品。可稍微再深挖一些,超过60%的国产数据库厂商不足100人,超过500人的企业不到10%,再加上协同合作的不足,原本就相对薄弱的研发能力无法形成合力,难以进入金融、能源等“稳定性大于天”的业务场景,生存环境一直比较艰难。

另一种解释是国产数据库的架构问题。

2008年左右,在阿里等互联网巨头的倡导下,“去IOE”浪潮如火如荼。当时中国互联网已经进入到高速增长期,出现了双11购物节等数据量和用户量激增的场景,而IOE架构欠缺横向扩展能力,无法满足激增的性能诉求和灵活扩容诉求,一些企业开始使用通用服务器打造灵活易扩展的分布式数据库。

在数据库的架构上,为了消除不必要的数据搬移延迟和功耗,看似提高效率并降低了成本的存算一体架构,逐渐被互联网企业所追捧。存算一体的优势很明显,短板也同样明显。为了实现高可靠,通常采用一主多从的架构,多个从节点大部分时间都处于闲置状态,导致CPU资源利用率极低。而且服务器出现故障后,无法自动切换,需投入大量人力和时间手工恢复数据。

即使达梦、南大通用等老牌国产数据库厂商,仍在坚持存算分离架构,可当整个市场的注意力转向时,一两家企业无法左右行业的风向。像银行这样对稳定性要求苛刻的传统业务,由于国产化数据库无法满足需求,不得不把订单交给国外厂商。

当存算一体架构被越来越多人诟病,数据传输性能的短板被填补后,存算分离的架构再度被推向台前。华为数据存储与优炫软件的合作,就是新背景下的叙事,试图用软硬结合的方式闯出一条新路。

02 多写多读集群:难题背后的新解法
存算分离的概念不难理解,简单地说就是分别构建计算资源池和存储资源池,全局共享一份数据,一些不必要的消耗可以被避免,进一步提升了数据库的性能,即使某个服务器出现了故障,也不会导致数据丢失。

在存算分离的架构下,华为数据存储与优炫软件共同发布了“数据库存算分离联合解决方案”,主要包含三个子方案:

一是主备集群部署方案,采用数据库一主一从架构,保证业务高可用,并具备易部署、易管理等特点,适用于OA、门户、邮箱、订单管理等业务系统;

二是读写分离集群部署方案,采用一主多从架构,通过存算分离+主从数据强一致性技术确保从节点可读,具有高性能、易扩展、高可靠等优势,适用于金融账务系统、ERP系统、CRM系统、生产制造、研发系统等中大型关键交易应用;

三是多写多读集群部署方案,采用多主架构,通过共享存储+SRAC技术确保全局节点数据读写强一致性,并达成多写多读、负载均衡、脑裂控制等效果,具备极高的可靠性与性能扩展潜力,适用于金融、电信、能源、交通、财税、生产制造等行业中对可用性、性能要求极高的大型核心交易系统。

三个子方案对应着不同的业务场景,其中最为瞩目的正是多写多读集群部署方案,在很大程度上关系着国产数据库能否在最核心的交易业务中实现对Oracle RAC的替代。

以一个常见的支付场景为例:当银行拒绝用户的支付请求时,需要快速查询用户过往的支付习惯,判断支付请求是否有风险,同时以弹窗的方式进行风险提示。这就需要数据库有很高的处理复杂事务的能力,业务的连续性要求高、绝对的高可用性、业务和数据的一致性,以及一定的可扩展性。

国内对RAC的替代由来已久,大多采用三种方式:中间件模拟、分布式数据库以及类似RAC的技术路线。优炫软件的“多写多读集群部署方案”,采用的就是RAC的路线,可以直接进行国产替代。

除了优炫软件持续10年时间的高压投入,存储性能在攻克多写多读集群的难题中扮演了至关重要的角色。

想要实现多写多读集群,存储环节面临着多个节点并发读写、极高的并发吞吐量、高可靠性等挑战,华为OceanStor Dorado全闪存存储50μs的极致时延、2100万IOPS和极致稳定的 SmartMatrix 全互联架构,让整体性能比同等配置的普通存储提升了30%,可满足不同类型的交易型业务诉求。

数据库系统遵循“木桶理论”,硬件和软件任何一环存在短板,都将制约数据库的发展。华为数据存储和优炫软件的合作,无疑为整个数据库行业提供了新的解题思路:优炫数据库的软件优势和华为OceanStor闪存存储的硬件优势融合后,原先横亘在国产数据库头上的“魔咒”悄然被解除。

03 越过山丘:行业已经形成了新共识
如果说十几年前的“去IOE”浪潮中,过于聚焦互联网业务的需求,选择性忽略了传统业务的诉求。华为数据存储和一众数据库厂商的联合创新,目的正是为了关键行业的核心系统上,不断缩小与国际领先梯队在性能、可靠性上的差距,提升国产数据库的综合竞争力。

特别是在“存算分离”架构上,不只是优炫软件,华为数据存储已经和不少数据库厂商推出联合解决方案,在不少领域实现了跨越式升级。

比如万里数据库与华为数据存储联合发布的“存算分离&多主架构联合创新方案,突破了数据库多读多写的业界难题,大幅提升了数据库性能,同时降低系统的建设成本。以性能为例,通过数据库跨节点缓存池化技术,实现了全局表并发读写、事务并发处理能力,相比于传统的主备数据库和分片数据库,性能在不同场景下可提升10倍。

再比如华为数据存储与南大通用共同发布的“金融核心级数据库高可用解决方案”,基于存算分离+共享存储架构,联合GBase南大通用数据库和华为OceanStor闪存存储,提供了满足金融核心系统要求的高性能、高可用数据库解决方案。

其中一个不可小觑的创新是双重容灾机制,在应用层实现了基于逻辑复制的数据库容灾、备库可读,在存储层依托OceanStor闪存存储HyperMetro A-A双活能力,确保数据高效、完整复制到容灾站点,且不影响工作站点性能,确保RPO=0,确保数据不丢失、业务快速恢复,满足金融核心系统的业务要求。

国产数据库以往被频频诟病各自为战,对比IOE这样的“黄金组合”,国内数据库市场可谓一盘散沙。不同厂商间缺少密切的合作,无法构建一个良性生态系统,无法脱离国外品牌为主导的生态圈,导致多而不强的市场格局。

优炫软件、万里数据库、南大通用、海量数据……华为数据存储就像是一条纽带,把不同数据库厂商凝聚在了一起,也许现阶段的生态协作还不是特别紧密,但“存算分离+共享存储架构”已经是一种行业共识。

借用一位数据库从业者的说法:国内数据库行业并不缺少优秀的工程师,重要的是找到正确的问题与正确的方向去发力。

沿循这样的逻辑,随着越来越多的数据库厂商选择华为作为伙伴,和华为数据存储进行联合方案创新,一个有利于国产数据库产业崛起的良性生态,已经初具雏形。在自主创新的道路上默默苦行了十几年的中国数据库产业,正在越过山丘,等待他们的,将是一个繁荣的数据库生态。

04 写在最后
市场咨询机构Gartner曾在2022年发布的《数据库中国市场指南报告》中预测:到2025年,中国分析型数据库市场来自海外厂商的将只剩下30%,交易型数据库市场海外厂商市场也只会剩下50%左右。

可能在一年多以前,不少人还会对Gartner的预测数据表示怀疑,毕竟IOE在交易型数据库市场还是不可替代的存在。伴随着“存算分离+共享存储架构”的不断创新、突围,Gartner的预测离现实已经越来越近。

这篇关于“多写多读集群”被攻克,中国数据库产业“越过山丘”的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/548543

相关文章

创新、引领、发展——SAMPE中国2024年会在京盛大开幕

绿树阴浓夏日长,在这个色彩缤纷的季节,SAMPE中国2024年会暨第十九届国际先进复合材料制品原材料、工装及工程应用展览会在中国国际展览中心(北京朝阳馆)隆重开幕。新老朋友共聚一堂,把酒话桑麻。 为期4天的国际学术会议以“先进复合材料,引领产业创新与可持续化发展”为主题,设立了34个主题分会场,其中包括了可持续化会场、国际大学生会场、中法复合材料制造技术峰会三个国际会场和女科技工作者委员会沙龙,

关于如何更好管理好数据库的一点思考

本文尝试从数据库设计理论、ER图简介、性能优化、避免过度设计及权限管理方面进行思考阐述。 一、数据库范式 以下通过详细的示例说明数据库范式的概念,将逐步规范化一个例子,逐级说明每个范式的要求和变换过程。 示例:学生课程登记系统 初始表格如下: 学生ID学生姓名课程ID课程名称教师教师办公室1张三101数学王老师101室2李四102英语李老师102室3王五101数学王老师101室4赵六103物理陈

数据库期末复习知识点

A卷 1. 选择题(30') 2. 判断范式(10') 判断到第三范式 3. 程序填空(20') 4. 分析填空(15') 5. 写SQL(25') 5'一题 恶性 B卷 1. 单选(30') 2. 填空 (20') 3. 程序填空(20') 4. 写SQL(30') 知识点 第一章 数据库管理系统(DBMS)  主要功能 数据定义功能 (DDL, 数据定义语

给数据库的表添加字段

周五有一个需求是这样的: 原来数据库有一个表B,现在需要添加一个字段C,我把代码中增删改查部分进行了修改, 比如insert中也添入了字段C。 但没有考虑到一个问题,数据库的兼容性。因为之前的版本已经投入使用了,再升级的话,需要进行兼容处理,当时脑子都蒙了,转不过来,后来同事解决了这个问题。 现在想想,思路就是,把数据库的表结构存入文件中,如xxx.sql 实时更新该文件: CREAT

SQL Server中,查询数据库中有多少个表,以及数据库其余类型数据统计查询

sqlserver查询数据库中有多少个表 sql server 数表:select count(1) from sysobjects where xtype='U'数视图:select count(1) from sysobjects where xtype='V'数存储过程select count(1) from sysobjects where xtype='P' SE

SQL Server中,添加数据库到AlwaysOn高可用性组条件

1、将数据添加到AlwaysOn高可用性组,需要满足以下条件: 2、更多具体AlwaysOn设置,参考:https://msdn.microsoft.com/zh-cn/library/windows/apps/ff878487(v=sql.120).aspx 注:上述资源来自MSDN。

SQL Server中,用Restore DataBase把数据库还原到指定的路径

restore database 数据库名 from disk='备份文件路径' with move '数据库文件名' to '数据库文件放置路径', move '日志文件名' to '日志文件存放置路径' Go 如: restore database EaseWe from disk='H:\EaseWe.bak' with move 'Ease

数据库原理与安全复习笔记(未完待续)

1 概念 产生与发展:人工管理阶段 → \to → 文件系统阶段 → \to → 数据库系统阶段。 数据库系统特点:数据的管理者(DBMS);数据结构化;数据共享性高,冗余度低,易于扩充;数据独立性高。DBMS 对数据的控制功能:数据的安全性保护;数据的完整性检查;并发控制;数据库恢复。 数据库技术研究领域:数据库管理系统软件的研发;数据库设计;数据库理论。数据模型要素 数据结构:描述数据库

MySQL数据库(四):视图和索引

在数据库管理中,视图和索引是两种关键工具,它们各自发挥独特的作用以优化数据查询和管理。视图通过简化复杂查询、提高数据安全性和提供数据抽象,帮助用户轻松访问数据。而索引则通过加速查询、确保数据唯一性以及优化排序和分组操作,显著提升数据库性能。理解和合理运用这两者,对数据库系统的高效运行至关重要。 目录 一、视图概念(面试) 二、视图的作用(面试) 三、视图的创建和使用 3.1

Java中如何优化数据库查询性能?

Java中如何优化数据库查询性能? 大家好,我是免费搭建查券返利机器人省钱赚佣金就用微赚淘客系统3.0的小编,也是冬天不穿秋裤,天冷也要风度的程序猿!今天我们将深入探讨在Java中如何优化数据库查询性能,这是提升应用程序响应速度和用户体验的关键技术。 优化数据库查询性能的重要性 在现代应用开发中,数据库查询是最常见的操作之一。随着数据量的增加和业务复杂度的提升,数据库查询的性能优化显得尤为重