目录

前言

传统数据库的局限

可用性低、资源利用率低

扩展成本高、运维成本高

存算分离带来的技术革命

谷歌三架马车奠定理论基础

Hadoop——存算分离的大数据架构

为什么云原生数据库中需要存算分离?

数据库存储引擎中的存算分离实践

亚马逊Aurora

首个云原生数据库存算分离技术实践

工作原理

存储引擎的创新设计

优势:性能强悍、可用性、耐用性、安全性

为什么选择亚马逊云原生数据库?

完善的基础设施

高性能、低运维成本、安全可靠

庞大的客户群体和蓬勃发展的技术生态

重磅福利!

前言

博主为大家争取到了亚马逊专属福利!亚马逊云科技提供了100余种产品免费套餐,其中计算资源Amazon EC2首年12个月免费,750小时/月;存储资源 Amazon S3 首年12个月免费,5GB标准存储容量;数据库资源 Amazon RDS 首年12个月免费,750小时;Amazon Dynamo DB 25GB存储容量 永久免费。

在万物互联的大数据时代,数据库是大数据整个产业的基础设施之一,存储数据的仓库。如果要创建一个大数据的大厦,那么数据库就像这座大厦的地基,影响数据存储的速度、查询的速度、导出的速度等等。传统数据库在可靠性、安全性、拓展性、可用性、资源利用率等方面已经全面落后于云原生数据库,随着云生态的发展,云原生正被越来越多的人所关注。在“万物皆可上云”的时代,云原生数据库早已是最佳选择。

传统数据库的局限

数据库是结构化信息或数据(一般以电子形式存储在计算机系统中)的有组织的集合,通常由数据库管理系统 (DBMS) 来控制。在现实中,数据、DBMS 及关联应用一起被称为数据库系统,通常简称为数据库。为了提高数据处理和查询效率,当今最常见的数据库通常以行和列的形式将数据存储在一系列的表中,支持用户便捷地访问、管理、修改、更新、控制和组织数据。

传统数据库诞生于 20 世纪 60 年代,最初人们使用分层数据库和网络数据库这样的导航数据库来存储和操作数据。这些早期系统虽然简单,但缺乏灵活性。20 世纪 80 年代,关系型数据库开始兴起;20 世纪 90 年代,面型对象的数据库开始成为主流,其中最著名的代表如MySQL。

传统的数据库经过了60年的发展,技术日益成熟,但是有以下几个显著的局限性:

可用性低、资源利用率低

无论多稳定的数据库系统都会无可避免地发生“意外”,数据库的可用性是用来确保在从正常到“崩溃”的环境中当性能保持在一个必需的级别上时,数据必须是可用的。一般来说,数据的可用性可以从数据的一致性、准确性、完整性、时效性及实体同一性五个方面进行考察。

特别是在高集群高并发的场景中,数据库的故障恢复显得尤为困难。传统数据库一般仍以备份恢复的方法修复故障,当遇到据量大、数据产生速度快、数据类型复杂的情景时,平均恢复时间(MTTR)会变得越来越长,可用性大打折扣。

当扩展集群的计算能力时,不得不扩展存储空间,这往往会造成磁盘资源的浪费。特别是针对周期性的应用场景,例如双十一、618大促,需要临时扩展计算资源,或者在原先计算能力的基础上有较多冗余。但是平常维护庞大的计算资源势必对成本造成较大压力,资源利用率也大打折扣。

扩展成本高、运维成本高

传统本地数据库如果要新增实例,需要从备份中恢复数据,然后应用达到与主实例一致的状态,数据恢复的时间、日志应用的时间等耗时很高,特别是数据量大、数据状态过时的情况下,耗时耗力,数据库扩展的成本高。

传统的数据库需要运维成本极高,数据的备份、恢复、扩展均需要专业的运维团队体提供技术支持,面对数据量的爆炸式增长,使数据库管理员忙于数据管理和组织,给公司带来极高的人力成本压力。

存算分离带来的技术革命

为了解决当前的种种问题,计算机科学家一直在努力实现无状态化,对计算和存储进行解耦,实现计算与存储分离。2012年前后,亚马逊、Facebook等厂商基于GFS论文中的EC算法,提出了存储和计算分离的架构原型:计算部分为数据库提供算力,如基本的资源CPU和内存;存储部分可以灵活地扩展增强的数据持久化资源池,在动态“资源池”基础上,通过数据库内部计算与存储分离,将存储管理放到下层共享存储中,从而解决数据同步带来的延时问题,并同时增加了计算能力的横向扩展性。

谷歌三架马车奠定理论基础

这个时候谷歌摒弃了之前的观念“移动存储到计算”,采取了“移动计算到存储的观念”,将计算和存储耦合了,因为当时的网络速度对比现在来说慢了几百倍,网络速度跟不上我们的需要。于是在2004-2006年间,Google陆续发表了Google File System、MapReduce和BigTable三篇革命性技术的文章,分别说了分布式文件系统、分布式计算MR和分布式结构化存储系统,奠定了存算分离技术的理论基础。

Hadoop——存算分离的大数据架构

以谷歌三驾马车为核心技术的开源大数据框架是存算分离的最佳样例。Hadoop能够在开发者不了解分布式底层细节的情况下,利用集群的计算和存储能力,对大量数据进行可靠、高效、可伸缩的分布式高速运算。

Hadoop 1.0使用通用服务器和普通硬盘搭建了大规模数据存储和计算集群,由于单机吞吐量和集群网络带宽限制,并没有实现存算分离,而是将集群部署都存储和计算在一起,将计算的代码移动到数据所在的地方,而不是将数据传输到计算节点,这种方式可以产生更少的数据迁移,降低机器间、机柜间的网络带宽消耗,有效解决了分散在各个弱连接的存储节点间的海量数据访问的困难。

但是由于存算一体,计算资源和存储资源是按某一比例强绑定,系统扩容必须按节点数目增加,导致内存或磁盘的浪费。另外由于使用3副本的数据存储模式,在大集群(100+ 节点、PB级别)下将造成高昂的存储成本。

于是在Hadoop 2.0 平台使用EC替代了3副本减低了存储的成本,并在存算解耦后能独立扩计算集群和存储集群提高资源利用率。存储和计算可以按需创建和自动弹性伸缩,无须准确估算未来的业务规模,降低了系统部署和扩展成本,同时将CPU和磁盘充分调度起来,解决了资源利用不均衡的问题。

为什么云原生数据库中需要存算分离?

Massive Parallel Processing(MPP)架构为OLAP类数据库最普遍采用的技术架构。在MPP架构下,计算存储共享一个节点,每个节点有自己独立的CPU、内存、磁盘资源,互相不共享。数据经过一定的分区规则打散到不同的节点上,处理查询时每个节点并行处理各自的数据,互相之间没有资源争抢,具备比较好的并行执行能力。

但是这种将存储资源、计算资源紧密耦合的架构,不太容易满足云时代不同场景下的不同workload需求。例如复杂查询类任务往往对CPU的资源消耗非常大,而数据导入类的任务对CPU资源消耗不大,但是往往需要消耗比较大的IO和网络带宽。因此面对这两种不同的workload,在选择资源规格时,需要结合不同的workload分别做不同的类型选择,也很难用一种资源规格同时满足这两种类型。因为业务不停在发展,workload也不停在变化,比较难提前做好规划。

当我们需要扩容集群扩充CPU资源时,往往会引发数据的reshuffle,这会消耗比较大的网络带宽和CPU资源。即便是基于云平台构建的数据仓库,在查询低峰期时,也无法通过释放部分计算资源降低使用成本,因为这同样会引发数据的reshuffle。耦合的架构严重限制了数据仓库的弹性能力。

而通过分离存储资源、计算资源,可以独立规划存储、计算的资源规格和容量。这样计算资源的扩容、缩容、释放,均可以比较快完成,并且不会带来额外的数据搬迁的代价。存储、计算也可以更好的结合各自的特征,选择更适合自己的资源规格和设计。

数据库存储引擎中的存算分离实践

数据库2014年AWS首次推出了Aurora,阿里在2017年推出了PolarDB,华为云在2020年推出了GaussDB for MySQL,华为存储于2021年推出OceanData分布式数据库存算分离方案……目前国内外主流云原生公司都推出了自己的数据库存算分离解决方案。

想要快速体验云原生数据库?可以点击下方链接:

1. 数据库免费试用链接及上手教程:上手试用

2.云原生数据库在线大会:云原生数据库在线大会

亚马逊Aurora

首个云原生数据库存算分离技术实践

亚马逊Aurora数据库是与 MySQL 和 PostgreSQL 兼容的关系数据库,专门为云原生而打造。在2014年,在AWS大会上,AWS就宣布推出Aurora。这是一个面向亚马逊关系数据库服务的兼容MySQL的数据库引擎,Aurora完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。

工作原理

Aurora将MySQL存储层变为为独立的存储节点,在Aurora中认为日志即数据,将日志彻底从Mysql计算节点中抽离出来,都由存储节点进行保存,并且也取消了undolog用于减小计算存储之间的交互和传输数据带宽。

当我们创建一个Aurora实例时,我们先创建一个数据库集群。数据库集群由一个主实例和一个集群卷组成。此外,我们还可以创建一个Aurora副本集,可以进行连续备份到AWS S3(简单存储服务)。

主实例支持读/写工作负载,对集群卷执行所有数据修改;集群卷支持多个可用区域(AZ),每个AZ都有两个集群数据副本,由主实例和Aurora副本共享;副本集支持只读操作,以支持读取工作负载的分发,多个Aurora副本意味着增加数据库可用性,如果主实例失败,其中一个Aurora副本将被提升为主实例。

存储引擎的创新设计

Amazon Aurora存储引擎是一个分布式SAN,它跨越一个区域中的多个AWS 可用区(AZ)。AZ是由物理数据中心组成的逻辑数据中心。每个AZ彼此隔离,但低延迟链接除外,该链接允许与该区域中的其他AZ快速通信。Amazon Aurora中心的分布式低延迟存储引擎取决于可用区。

每个保护组中的数据将在六个存储节点之间复制。然后,将这些存储节点跨Amazon Aurora群集所在区域中的三个可用区分配。创建集群后,它只占用很少的存储空间。随着数据量的增加和超过当前分配的存储量,Aurora会无缝扩展卷以满足需求,并根据需要添加新的保护组。

在每个存储节点上,记录首先进入内存队列。此队列中的日志记录已删除重复数据。例如,在主节点成功写入存储节点,但主节点与存储节点之间的连接中断的情况下,主节点重新发送日志记录,但是重复的日志记录将被丢弃,要保留的记录在热日志中被加固到磁盘上。

计算和存储是分离的。这允许Aurora副本充当存储层的计算接口,而无需在副本本身上保留任何数据。这使Aurora副本在实例联机后即可开始提供流量,而无需同步任何数据。同样,Aurora副本的丢失对基础数据也没有影响。当Aurora副本成为主节点时,不会丢失数据。通过支持多达15个Aurora副本以及这些Aurora副本之间是内置负载均衡的,使得Amazon Aurora非常适合于高可用性,读取密集型工作负载。

优势:性能强悍、可用性、耐用性、安全性

Amazon Aurora提供的吞吐量是MySQL的五倍,是PostgreSQL的三倍,其商业数据库的安全性,可用性和可靠性仅为成本的十分之一。目前的Aurora可跨3个可用区的6-路复制、30秒内便可完成故障转移、同时具备快速的crash recovery能力。

Amazon Aurora仅将日志记录发送到存储节点,并且所有操作是并行进行的。使用组提交可以并行执行写操作,以减少延迟并提高吞吐量。实际上,与MySQL相比,即使将数据写入六个不同的节点,Amazon Aurora对于类似的工作负载平均也需要大约1/8的IOPS。

Amazon Aurora 提供内置的安全性、几乎连续的备份、无服务器计算、最高 15 个只读副本、自动多区域复制以及与其他 AWS 服务的集成。

Amazon Aurora允许用户使用行业标准AES-256加密来加密所有静态数据。用户还可以使用(AWS KMS)管理密钥,可以通过与Amazon Aurora集群的TLS连接来保护飞行中的数据。除了这些功能之外,Amazon Aurora还拥有多种认证/证明,包括SOC 1,SOC 2,SOC 3,ISO 27001/9001,ISO 27017/27018和PCI。

为什么选择亚马逊云原生数据库?

完善的基础设施

2005年,亚马逊发布了AWS(亚马逊网络服务)云计算平台,2006年亚马逊正式推出了他们的前三款产品:EC2(弹性计算机云)、S3(简单存储服务)、SQS(简单队列服务),标志着云计算新的商业模式诞生,成为第一个做商用云服务的科技巨头。可以说亚马逊一直是云时代的领跑者,并在今天牢牢占据市场的头号座椅。

亚马逊不仅仅走在最前面,还从未停止前进的脚步,不断完善自身的基础设施。亚马逊杰出工程师汉密尔顿曾说:“亚马逊每天正以疯狂的速度添加足够的服务器容量、存储系统,建设新的数据中心,以支持亚马逊所有的全球基础设施”。

高性能、低运维成本、安全可靠

亚马逊云数据库在雄厚的基础设施建设和先进的架构基础上,能够提供微秒到亚毫秒延迟的非关系数据库,支持不停机扩展业务需求,关键性能指标上遥遥领先竞争对手。

在重视性能建设的同时,AWS始终把安全性放在第一位,安全性具有最高优先级。AWS数据库提供具有多个安全级别的完整数据监督,在所有数据在流动之时,都要经过物理层自动加密,通过深度集成的服务实现自动化并降低风险。

庞大的客户群体和蓬勃发展的技术生态

亚马逊数据库提供了覆盖面极广的服务,包括内容管理、企业资源管理、设备维护等,如下图所示:

无论客户有什么需求,总能在亚马逊云上找到成熟的应用,非常方便!

AWS在市场占有率上遥遥领先,是很多客户的选择,例如纳斯达克将分阶段把全部业务迁移到AWS上,并将美国的一个期权交易市场上云。纳斯达克跟AWS的合作,还将为纳斯达克分布在全球的130多个企业客户带来长远影响,这些客户包括交易所、银行、清算所等,并将在更大范围推动相关企业的上云。

亚马逊云率先推出了专业认证AWS Certification, AWS Certification 可验证云专业知识,帮助专业人员突出紧缺技能,并且组织可以使用 AWS 为云计划组建有效的创新团队。认证包括AWS认证云从业者、AWS认证解决方案架构师,AWS认证数据库等,通过学习和考试,能让开发者们快速掌握云服务相关的专业知识,形成良好的技术生态和技术社区。据统计AWS 认证人员的需求为170万,越来越多的人参与到AWS认证学习中来,形成了良好的技术氛围,让开发者们在前行的过程中不再形单影只,星星之火可以燎原。

亚马逊云科技专为开发者们打造了多种学习平台:

1. 入门资源中心:从0到1 轻松上手云服务,内容涵盖:成本管理,上手训练,开发资源。AWS入门_AWS入门使用教程_AWS云计算资源-AWS云服务

2. 架构中心:亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。AWS架构中心部署说明_AWS云架构白皮书-AWS云服务

3. 构建者库:了解亚马逊云科技如何构建和运营软件。Amazon Builders' Library*all&awsf.filter-content-type=*all&awsf.filter-content-level=*all&trk=835e6894-d909-4691-aee1-3831428c04bd&sc_channel=el

4. 用于在亚马逊云科技平台上开发和管理应用程序的工具包:aws工具下载_aws开发工具_资源下载-AWS云服务

重磅福利!

最后,博主为粉丝们争取到了专属福利!亚马逊云科技专为开发者们打造了多种学习平台:

1. 入门资源中心:从0到1 轻松上手云服务,内容涵盖:成本管理,上手训练,开发资源。AWS入门_AWS入门使用教程_AWS云计算资源-AWS云服务

2. 架构中心:亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。AWS架构中心部署说明_AWS云架构白皮书-AWS云服务

3. 构建者库:了解亚马逊云科技如何构建和运营软件。Amazon Builders' Library*all&awsf.filter-content-type=*all&awsf.filter-content-level=*all&trk=835e6894-d909-4691-aee1-3831428c04bd&sc_channel=el

4. 用于在亚马逊云科技平台上开发和管理应用程序的工具包:aws工具下载_aws开发工具_资源下载-AWS云服务

大话云原生数据库中的存算分离相关推荐

  1. 解读clickhouse存算分离在华为云实践

    摘要:本文是我们对clickhouse做了最简单的支持obs的适配改造. 本文分享自华为云社区<clickhouse存算分离在华为云实践>,作者: he lifu. clickhouse是 ...

  2. 大数据上云存算分离演进思考与实践

    作者:汤祯捷 阿里云智能计算平台团队 存算分离.数据湖.在离线混部,这些名词越来越多的出现在各行各业数字化转型的关键活动中.本文仅从大数据产品商业化从业者的视角来探讨与分析大数据领域的存算分离演进过程 ...

  3. 从 Hadoop 到云原生, 大数据平台如何做存算分离

    Hadoop 的诞生改变了企业对数据的存储.处理和分析的过程,加速了大数据的发展,受到广泛的应用,给整个行业带来了变革意义的改变:随着云计算时代的到来, 存算分离的架构受到青睐,企业开开始对 Hado ...

  4. 什么是数据库“存算分离”架构?

    今天的话题要从一个朋友的咨询开始 所以准备写一篇短文谈谈我对"存算分离"架构的理解,不一定全面,欢迎在评论区探讨. 其实这个朋友是误解了"存算分离"这个概念.他 ...

  5. 存算分离架构的高斯Redis,用强一致提供可靠保障

    摘要:其实开源Redis的弱一致性已经不满足很多应用场景的诉求.怎么,不信? 本文分享自华为云社区<华为云企业级Redis揭秘第15期:Redis为什么需要强一致?>,作者: GaussD ...

  6. GaussDB(for Redis)揭秘:Redis存算分离架构最全解析

    前言: 本文根据华为云NoSQL数据库架构师余汶龙,在今年的中国系统架构师大会SACC上的演讲整理而成,内容如下. 本次分享的大纲分成如下四个部分: 什么是GaussDB(for Redis)? 为什 ...

  7. 2022 IoTDB Summit:IoTDB PMC 曹高飞《Apache IoTDB 秒级扩容能力与存算分离实践》

    12 月 3 日.4日,2022 Apache IoTDB 物联网生态大会在线上圆满落幕.大会上发布 Apache IoTDB 的分布式 1.0 版本,并分享 Apache IoTDB 实现的数据管理 ...

  8. 存算分离实践:JuiceFS 在中国电信日均 PB 级数据场景的应用

    01- 大数据运营的挑战 & 升级思考 大数据运营面临的挑战 中国电信大数据集群每日数据量庞大,单个业务单日量级可达到 PB 级别,且存在大量过期数据(冷数据).冗余数据,存储压力大:每个省公 ...

  9. Hadoop存算分离实现方案探讨

    传统的 Apache Hadoop架构存储和计算是耦合在一起的, HDFS作为其分布式文件系统也存在诸多不足.那么,如何实现Hadoop的存算分离,以规避HDFS的问题.降低成本.提升性能? 01.H ...

最新文章

  1. 只做macd二次金叉_【教你一招】MACD低位二次金叉
  2. 前端学习(3187):ant-design的button介绍按钮属性
  3. bzoj2561 最小生成树
  4. 利用TICK搭建Docker容器可视化监控中心
  5. minist _On_[GoogleNet]
  6. sql_action
  7. Zabbix 对接 LDAP 实现用户统一登录的方法
  8. 计算机课题立项申报书范文,课题立项申请书怎么写
  9. 编程语言难度排名_文言文可编程乎?CMU中国大四学生:开源文言文编程语言获1万+标星...
  10. 配置PotPlayer和Dolby Access启用耳机杜比全景声
  11. vscode试图写入的管道不存在
  12. java 图形_java 画立体图形
  13. jquery easyui datagrid 列自适应窗口宽度
  14. 网格画法:原生 Canvas 画网格,可拖动、可放大缩小、并带有坐标系 0 0 位置辅助线
  15. 量化投资和主观投资到底有什么区别?
  16. 【软件架构】Michael Perry关于不可变架构、CAP定理和CRDTs
  17. Apriori算法例子
  18. TextView简介
  19. 如何判断合法的立即数
  20. 机器学习(线性模型)

热门文章

  1. Spring Boot pdf文件转图片
  2. win7防火墙怎么关_win7系统防火墙开启失败怎么办【解决方法】
  3. JSP自定义带属性的标签
  4. 天嵌科技恭祝大家元宵节快乐
  5. 《黃帝內經》第一章《上古天真論》
  6. 51单片机WIFI手机APP智能窗户窗帘控制系统手动自动定时
  7. 网格环境配置(三):安装SGE
  8. L2-039 清点代码库
  9. VGA、DVI、HDMI、DP 接口介绍及优劣
  10. JAVA版商城 spring boot商城 spring cloud商城 B2B2C商城 多用户商城 直播带货商城 新零售商城 b2b供应链 电子商务 拼团商城 分销商城 直播商城 社交电商