生产数据库架构改造方案.pdf

  1. 1、本文档共6页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
生产数据库性能优化方案(初稿) 1. 背景 生产数据库上线一段时间后由于数据量远大于预期, 导致数据库性能低下而 影响正常业务,故需要对数据库进行性能优化。 2. 现状 当前数据库结构如下图所示: 图 2-1 系统结构示意图 上游三个数据源通过 DI 工具以定时任务的方式将上游数据抽取到基础数据 库中(红色部分) ,从基础库到下游目标库则是通过用户操作应用程序将基础数 据库中的数据调度到目标数据库中。根据目前对数据量的统计基础库约为 400GB+的数据总量。 目前基础数据库的性能低下, 主要表现于定时抽取任务执行时间过长, 任务 间的时间间隔变短; 应用执行数据调度时间过长, 导致应用长时间处于无响应状 态。 3. 分析 基础数据库获取上游数据时, 数据传输量较大, 数据库写操作频繁, 操作系 统层表现于数据文件所在磁盘 写 IO 高,并持续时间长。 由于基础库放数据到下游数据库是人为操作, 数据库读操作频繁, 操作系统 层表现于数据文件所在磁盘 读 IO 高,且经常会与 DI 定时任务同时执行, 通过系 统监控发现磁盘出现大量 IO 等待状态。 图 3-1 磁盘 IO 状态 图 3-2 磁盘等待状态 由于基础库保存原始数据并不对数据进行处理,所以 CPU 消耗很低,从监 控看 CPU 不视为性能瓶颈点。 图 3-3 CPU 使用率 从以上分析可以判断数据库操作性能低下主要在高磁盘 IO 时造成 IO 挣用较 大导致拖慢整体性能。故本次优化将重点放在解决磁盘 IO 挣用问题和提高磁盘 IOPS上。 4. 优化方案 本着应用层变动最小的原则,为解决基础库磁盘 IO 性能低下问题,我们将 从三个方面着手进行,即:优化数据库物理架构、优化 DI 任务执行时间和优化 数据库数据文件所在 Path 的磁盘 VG 结构。 4.1. 优化数据库物理架构 根据基础库的业务特点,这里将对基础库的读写操作进行分离(即:读、写 分离)。这样做的好处在于可以最大限度规避数据库读、写同时操作所带来的磁 盘 IO 挣用问题。调整后的架构如下图: 数据库采用主 / 从模式,使用 binlog 复制方式实现数据同步。由于考虑到大 数据量复制可能带来的同步延迟问题,实现时需要 注意优化复制线程参数 。 4.2. 优化 DI 任务执行时间 为了避免多任务同时写一个数据库产生磁盘写 IO 过高的问题,需要对每一 个 DI 任务的执行时间进行估算,并根据磁盘性能合理编排任务并行度。同时还 需要考虑数据单位时间内的数据增长量对任务执行时间的影响, 避免由于数据量 的增加延长任务执行时间而导致的任务并行执行。 4.3. 优化磁盘 VG 提高磁盘 IOPS最有效的方法就是增加通过增加物理磁盘数量并实现条带化 来提高整体的 IOPS。但随之带来的硬件投资成本也会增加。这里我们可以通过 将现有磁盘更换成等容量的小磁盘, 目的是为了增加磁盘数量从而提高整体磁盘 IOPS性能。如:当前一块磁盘容量为 600GB,我们可以将其拆解成

文档评论(0)

麻麻 + 关注
实名认证
内容提供者

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

1亿VIP精品文档

相关文档