在配置层面及使用层解决关系数据库的性能热点问题.docx

在配置层面及使用层解决关系数据库的性能热点问题.docx

  1. 1、本文档共16页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

?

?

在配置层面及使用层解决关系数据库的性能热点问题

?

?

云平台存储是用来存储数据的,简单的进行数据分类分为应用和数据库数据,其中数据库数据的安全可靠性、完整性、一致性、高性能等要求一直是存储领域里关注的热点,也是传统行业一直担心数据库上云时云平台无法满足数据库的要求。本议题将从数据库性能热点话题入手,谈谈云平台存储项目中如何设计并解决性能热点问题。

关系数据库的性能热点问题,在配置层面及使用层面如何解决?

一、关系型数据库云原生实践

当遇到云平台存储这个课题时,恰逢笔者在探索关系型数据库上云之路中,也遇到了要如何解决云环境下关系型数据库使用存储的问题。在讨论云平台存储之前,不妨先思考一下为什么企业的关系型数据库也要上私有云?

当前有很多公有云厂商提供了云数据库的服务,适合中小企业以低成本使用数据库。而金融行业公司出于对数据安全以及自身体量和管理经验的考量,更多的还是在考虑私有云的建设。

云原生存在众多收益点:例如标准化、自动化、DevOps集成、故障容忍自愈、平台无关、弹性伸缩、资源整合等等。企业在近几年的探索中,对于私有云的建设和管理也日趋成熟。因此对于无状态的应用迁移至云环境是天然适合的。然而对于传统关系型数据库能否上云,的确有很多需要顾虑的方面。

从技术发展趋势来看,企业传统架构在走向云,传统运维管理也走向DevOps管理,这两大趋势还是相辅相成的。从实际需求来看,传统关系型数据库上云也存在几大核心优势:

1.性能优势

轻量化的容器相对于虚拟机的性能优势是非常明显的。这也是企业虚拟化走向容器化的最核心因素。运行在虚拟机上的数据库性能对比同样配置的物理机或者是容器,差异是非常明显的。因此对于运行在虚拟机上的数据库定位,就是容量低性能需求低的业务场景,仅仅是利用虚拟化的高可用性和资源整合优势。因此容器化才是关系型数据库的适用方向。

2.成本优势

容器化对于资源整合是拥有巨大优势的。参考笔者近期对操作系统CPU数据的分析,可以看到90%的系统CPU使用率在10%以下。当前银行很多都是两地三中心的灾备建设,资源的闲置非常大。如果能够利用好私有云的资源整合优势,将大大降低银行成本。关系型数据上云就是要在保障性能的情况下,实现资源整合,减少成本。

3.可用性优势

云原生的另外一大优势就是高可用性。因此笔者也一直致力于探索数据库上云符合云原生而不是把容器纯粹当个虚拟机来管理。所以笔者设计开发了openGauss数据库的Operator,把数据库的管理提到Kubernetes这一层,实现数据库节点的故障发现和自愈,充分利用云原生的技术优势。

4.易维护优势

数据库上云后,实现了更高层次的标准化和自动化,让统一管理更容易实现。云环境的弹性能力也让维护、迁移、扩缩容等维护任务更简单高效。上述优势是数据库上云的动力,然而这里面有个核心问题需要解决:数据库是有状态的服务,也就是数据库上云是依赖存储的。而我们在维护数据库的过程中会发现,其实存储是数据库运行过程中性能最慢的环节。

二、数据库云平台存储方案思考

在数据库云原生方案设计初期,笔者先学习参考了大厂公有云上数据库的云原生方案对于存储的定义和解决方法,也对分布式存储的情况进行了调研。

1.主流云原生数据库的存储解决方案

当前最具有代表性的云原生数据库是阿里的PolarDB(图1)和AmazonAurora。这两家都是存算分离的方案。存储都是自己开发的分布式存储系统,通过硬件加速和对数据库的技术改造来解决数据库访问存储的性能问题。但遗憾这些方案无法落地企业私有云。

图1:采用了存算分离方案的PolarDB数据库架构图

2.集中式和分布式存储方案

云环境下采用分布式存储是看起来非常完美的方案,除了性能。因此我们也对主流的分布式存储做了测试。从测试的部分结论来看,测试Ceph发现在写入并发稍高的情况下,IO的响应时间是比较高的,基本上不能满足数据库的应用需求。而事实上我们也做了在容器环境下数据库使用分布式存储的压测,性能也不好。从这点来看,直接使用分布式存储是行不通的,这也是为什么那些公有云大厂的数据库存储方案要做很多硬件和技术上的改造。

采用集中式存储方案,虽然对于组网会有一定的要求,但性能特点上更符合数据库的应用特点,对比分布式存储方案性能更好。

3.本地盘方案

这种方案是一种当前关系型数据库对云原生存储的需求妥协。没有特别合适的云原生存储情况下,我选择了用本地盘来保障高性能,因此也无法做到Serverless,数据库节点不可漂移。数据库的高可用只能依赖主从切换的方式来实现。下面是当前的方案架构图(图2):

图2:本地盘方案架构图

如图2所示,本地盘通过TopoLVM插件来管理,可以说是非常不完美的方案。除了做不到Serverless之外,本地盘的扩容也是个问

文档评论(0)

134****4691 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档