关于高性能:针对-MySQL-IO-特点进行的存储优化揭秘

2次阅读

共计 1936 个字符,预计需要花费 5 分钟才能阅读完成。

性能优化,是存储工程师们永远的谋求,在咱们看来,除了调整存储架构、优化 IO 门路,能对利用做出有针对性的优化,也是十分重要和有意义的事件,这意味着,除了要理解存储自身,还须要对下层利用或中间件有足够的意识。这次,咱们就来看看 MySQL 的 IO 特点和存储针对 MySQL 的优化思路。

MySQL 架构组件阐明

MySQL 及其连续的 MariaDB 是目前市场上最风行的关系型数据库管理系统,在很多利用场景中,MySQL 都是用户首选的 RDBMS(Relational Database Management System 关系数据库管理系统)。

MySQL 大抵包含如下几大根底模块组件:

  • MySQL 客户端连贯组件(Connectors)
  • 系统管理和管制工具组件(Management Service & Utilities)
  • 连接池组件(Connection Pool)
  • SQL 组件(SQL Interface)
  • 解析器组件(Parser)
  • 查问优化器组件(Optimizer)
  • 缓存组件(Caches & Buffers)
  • 存储引擎(Pluggable Storage Engines)
  • 文件系统(File System)

InnoDB 存储引擎

存储引擎在 MySQL 的体系架构中位于第三层,负责对 MySQL 中的数据进行存储和提取,是与文件打交道的子系统,它是依据底层提供的文件拜访层形象接口定制的一种文件拜访机制,这个机制就叫作 MySQL 存储引擎。从 MySQL 5.5 开始,默认采纳 InnoDB 作为存储引擎。因而,优化底层存储对 MySQL 业务的的性能,就要从理解和剖析存储引擎如何与底层的存储系统进行交互开始。

下图是官网的 InnoDB 引擎架构图,InnoDB 存储引擎次要分为内存构造和磁盘构造两大部分。

InnoDB 磁盘次要蕴含 Tablespaces、InnoDB Data Dictionary、Doublewrite Buffer、Redo Log 和 Undo Logs。Redo Log 和 Binlog 是 MySQL 日志零碎中十分重要的两种机制,本文次要谈一下对 Redo Log 和 Binlog 进行的剖析及存储优化。

MySQL IO 模型和特点

MySQL 写数据过程中,有两个重要的日志文件,Redo Log 和 Binlog。Redo Log 记录了对 InnoDB 存储引擎的事务日志,Redo Log 的写 IO 是固定文件范畴内的循环写,IO 大小是 512 字节对齐(存在局部 offset 相等,执行的是笼罩写)。Binlog 记录了对 MySQL 数据库执行更改的所有操作,Binlog 的写 IO 是文件 append 写,IO 不对齐。MySQL 写申请时的存储行为:单线程执行 MySQL insert 写数据时,一个 insert 对应一个 write 操作;多线程并发执行 insert,MySQL 会将局部 IO 合并,而后下发到文件系统(如果是应用近程文件系统,这个 IO 会被近程文件系统的客户端捕捉,例如 YRCloudFile 的客户端),调用 write 申请写入到 /MySQL/ib_logfile 文件中。一次 write IO 之后,立刻调用 fsync。

在开启 Binlog 的场景下,写完一次 Redo Log 后会再写一次 Binlog,而后对 Binlog 做一次 fsync,以保障数据安全。当日志数据写入一定量之后,MySQL 后盾另外一个线程会将所有的写入,以每个 IO 16K 的大小进行整顿,并以 aio 形式写入到 /MySQL/ibdata 表文件中。

MySQL 读申请时的存储行为:MySQL 读时,会从 MySQL 的缓存中查找数据,缓存命中,就不会理论下发 read IO 到底层文件系统中。

YRCloudFile 针对 MySQL 日志 IO 行为优化

因为 Redo Log、Binlog 都是一次 IO 写入随同着一次 fsync,而依据理论测试发现,fsync 对于存储的开销比拟大。所以,对 MySQL 性能的优化,咱们须要在齐全确保这两个日志文件数据安全的前提下调整这两个 Log 的 IO 行为。

在 YRCloudFile 数据服务端,Redo Log 写文件以 direct 形式写入,写入之后咱们主动做一次 fsync。Binlog 因为 IO 不对齐,不能够采纳 direct 形式写,须要先写入零碎缓存,而后做一次 fsync。这样,其实客户端就不必再对 Redo Log 和 Binlog 文件做 remote_fsync 了,省去了客户端调用 fsync 的开销影响。上面是一组实测的数据比照:

从实测后果上,咱们能够看出,在调整了 YRCloudFile 后端针对性的写逻辑后后,MySQL 单线程写入的性能失去了翻倍的晋升。

存储的研发工程师们就是这样,岂但要把握存储的外围技能,还要关注和剖析下层利用的业务行为,能力对利用做出针对性的优化。当前,咱们还会带来更多面向利用的优化过程和剖析,大家敬请期待。

正文完
 0