【经验】GaussDB(for MySQL)性能优化 —— 日志的“快递驿站”
GaussDB(for MySQL)数据库在写入性能上,在业界同类产品中是最好的,这主要得益于GaussDB(for MySQL)在MySQL内核方面的诸多优化。其中有一项从“送快递”得来灵感的优化——事务异步提交,值得我们分析。
背景
我们先来看看MySQL 8.0的事务提交的大致流程
图1 MySQL 8.0事务执行流程
以上流程,是MySQL8.0对WAL原则的一种实现,这个流程意味着,任何一个事务的提交,一定要完成write buffer和flush to disk流程。
然而那么这个流程中,有一个问题:每个服务器的CPU是有限的,服务器能处理的Thread也是有上限的,那么当我们的业务的并发数量,远远大于我们服务器能并行处理的数量时,那么后来的事务,只能等待前面的事务提交后才能被处理。在这之前,他们什么也做不了。因此,在大并发场景下,如何进一步提升线程的使用率,是大并发事物写入的一个关键。
灵感来源于生活
一个优化,并不是凭空想象出来的,有时候,往往来源于现实生活。下面,我们先来看看我们身边,和事务提交流程非常类似的一个例子:快递。
现在的快递配送,一般一个快递员会负责一片区域,快递刚开始兴起时,数量不多,那么一个快递员基本上可以在规定时间内完成配送。
图2 过去的快递配送
但是,随着快递数量越来越多,一个快递员要在一个小区配送很长的时间,才能到下一个小区,常常导致了快递员无法准时的配送。在这个问题的催动下,随后,一个新的行业开始出现 – 快递驿站。
图3 现在的快递配送
快递的优化原理
接下来,让我们来看下,快递驿站究竟解决了什么问题。
快递的配送过程中,最耗时的,不是装货,不是卸货,而是电话和等待。配送一个小区的时间,取决于这个最后一个来取快递的人的时间,在最后一个人取完快递钱,快递员除了打电话,做不了其他任何事情(也没有办法通知下一个小区的人,因为最后一个人来取得时间是无法确定的)。那么这个等待的时间,对于快递员来说,就是一种浪费。
快递驿站可以很大程度解决这个问题,快递员到了以后,只需要将快递卸货,即可前往下一个小区,剩下的事情,就可以由驿站的人员来完成,大大提升了快递员的配送效率。
分析
回过头来,我们看看数据库,如果把Transaction线程看做快递员,存储上的文件看做取快递的人,那么我们会发现两者有非常大的相似性。那么我们可以像快递配送优化那样去优化事务的处理流程吗?答案是可以的。
图4 事务处理和快读配送非常类似
根据快递驿站的优化原理,我们知道,快递驿站帮快递员免去了等待客户取货的时间,那么事务处理过程中,有没有等待的过程呢?答案是有的,存储的IO就是一个较长的等待。数据库使用经验丰富的开发人员来都知道,等待redo日志写入存储的磁盘IO性能,很大程度上决定了数据库的写入性能。对于现代数据库来说,尤其对于GaussDB(for MySQL)这样计算于存储分离的数据库,存储的IO耗时,在事务处理的总耗时中,占据了不小的比例,虽然有log buffer的合并写入,提升并发情况下的整体吞吐,但是如果在等待IO的这段时间中,这些线程能够去做别的事情(例如处理等待中的其他事务)。那么将会有进一步的性能提升。
GaussDB(for MySQL)的优化
既然找到了等待的点,那么我们就可以像快递配送的优化方法,为数据库,也创造一个“快递驿站”,让“快递驿站”来做等待的事情,而事务线程就可以去处理其他等待中的事务,让CPU不会“闲下来”。
图5 GaussDB(for MySQL)的“快递驿站”
如图5所示,GaussDB(for MySQL)当redo日志的flush to disk动作完成后,即可进行事务提交,但是此时并不应答客户端,而是直接处理下一个事务。同时使用少量”post comit worker线程”,来批量等待日志写入完成(等待的过程其实并不占用CPU),并应答客户端,这就可以让“等待”和“下一个事务的处理”并行化,让CPU“闲不下来”。
实际测试
图6 Sysbench write only 模型下写入性能测试
根据实际测试,在标准的sysbench写入模型下,没有使用Post Commit时,极限性能是35万QPS左右,而使用Post commit后,可以到大42万以上的QPS,提升了20%的写入性能。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
京东毫秒级热key探测框架设计与实践,已实战于618大促
在拥有大量并发用户的系统中,热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款,或许是海量用户突然涌入某个店铺,或许是秒杀时瞬间大量开启的爬虫用户, 这些突发的无法预先感知的热key都是系统潜在的巨大风险。 风险是什么呢?主要是数据层,其次是服务层。 热key对数据层的冲击显而易见,譬如数据存放在redis或者MySQL中,以redis为例,那个未知的热数据会按照hash规则被存在于某个redis分片上,平时使用时都从该分片获取它的数据。由于redis性能还不错,再加上集群模式,每秒我们假设它能支撑20万次读取,这足以支持大部分的日常使用了。但是,以京东为例的这些头部互联网公司,动辄某个爆品,会瞬间引入每秒上百万甚至数百万的请求,当然流量多数会在几秒内就消失。但就是这短短的几秒的热key,就会瞬间造成其所在redis分片集群瘫痪。原因也很简单,redis作为一个单线程的结构,所有的请求到来后都会去排队,当请求量远大于自身处理能力时,后面的请求会陷入等待、超时。由于该redis分片完全被这个key的请求给打满,导致该分片上所有其他数据操作都无法继续提供服务,也就是...
- 下一篇
Spring Boot 2.3 分层jar包、优雅停机、完美支持 Docker\k8s,一起尝鲜儿吧
我是风筝,公众号「古时的风筝」,一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农! 文章会收录在 JavaNewBee 中,更有 Java 后端知识图谱,从小白到大牛要走的路都在里面。 Spring Boot 2.3 已经发布一个月了,这两天才想起来尝一尝鲜儿。除了常规的升级外,很大部分的升级是针对 Docker 的,让你不得不相信,Docker 容器化微服务已然大势所趋。还没有用过的同学,再不下手就晚了。 此次升级主要包括如下几个方面,接下来就跟着我一起来尝一尝吧。 准备工作 为了说明 Spring Boot 2.3 的新特性,必须创建一个项目,以便试验。 创建一个项目并启动 1、创建一个 Spring Boot 项目,可以到 https://start.spring.io/ 上创建,也可以使用 IDEA 自带的功能创建。选择版本 2.3.1,JDK 还是选择亲爱的 Java 8,引入 Web 和 Actuator 两个依赖包。 有一点要注意一下,在我写本文的时候,Spring Boot 2.3.1 还不能从中央仓库下载,需要添加 Spring Boot 官方的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Mario游戏-低调大师作品
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装