数据库顶会VLDB论文解读:阿里数据库智能参数优化的创新与实践

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 本文将对入围Research Track的论文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》进行详细解读,以飨读者。

前言

一年一度的数据库领域顶级会议VLDB 2019于美国当地时间8月26日-8月30日在洛杉矶召开。在本届大会上,阿里云数据库产品团队多篇论文入选Research Track和Industrial Track。

本文将对入围Research Track的论文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》进行详细解读,以飨读者。

注:本文由阿里云智能事业群艾奥、池院、洪林、谭剑、祺星、铁赢共同撰写。

1、背景

大概五六年前,阿里数据库团队开始尝试如何将DBA的经验转换成产品,为业务开发提供更高效,更智能的数据库服务。从14年CloudDBA开始为用户提供自助式智能诊断优化服务,经过四年的持续探索和努力,18年进化到CloudDBA下一代产品 —— 自治数据库平台SDDP(Self-Driving Database Platform)。

SDDP是一个赋予多种数据库无人驾驶能力的智能数据库平台,让运行于该平台的数据库具备自感知、自决策、自恢复、自优化的能力,为用户提供无感知的不间断服务。自治数据库平台涵盖了非常多的能力,包括物理资源管理,实例生命周期管理,诊断优化,安全,弹性伸缩等,而其中自动异常诊断与恢复和自动优化是自治数据库平台最核心的能力之一。

2017年底,SDDP开始对全网数据库实例进行端到端的全自动优化,除了常见的自动慢SQL优化和自动空间优化外,还包含了本文重点介绍的大规模数据库自动参数优化。

基于数据驱动和机器学习算法的数据库参数优化是近年来数据库智能优化的一个热点方向,但也面临着很大的技术挑战。要解决的问题是在大规模数据库场景下,如何对百万级别运行不同业务的数据库实例完成自动配置,同时权衡性能和成本,在满足SLA的前提下资源成本最低,该技术对于CSP(Cloud Service Provider)有重要价值。

学术界近一两年在该方向有一些研究(比如CMU的OtterTune),但该算法依赖于一些人工先验经验且在大规模场景下不具备可扩展性。据了解, 其他云厂商Azure SQL Database以及AWS该方向都有投入,目前尚未看到相关论文或产品发布。

从18年初开始我们开始数据库智能参数优化的探索,从问题定义,关键算法设计,算法评估及改进,到最终端到端自动化流程落地,多个团队通力合作完成了技术突破且实现了大规模落地。

由谭剑、铁赢、飞刀、艾奥、祺星、池院、洪林、石悦、鸣嵩、张瑞共同撰写的论文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》被VLDB 2019 Research Track接受,这是阿里巴巴在数据库智能化方向的重要里程碑事件。

这项工作不仅在数据库智能参数优化理论方面提出了创新想法,而且目前已经在阿里集团~10000实例上实现了规模化落地,累计节省~12%内存资源,是目前业界唯一一家真正实现数据库智能参数优化大规模落地的公司。

2、问题定义

参数优化是数据库优化的重要手段,而数据库参数之多也增加了参数调优的难度,比如最新版本的MySQL参数超过500,PostgreSQL参数也超过290。通常数据库调优化主要关心性能相关的参数,而其中对性能影响最大的是Buffer Pool的设置。

目前集团环境多个数据库实例共享主机的部署方式导致经常出现主机内存严重不足,但CPU和存储资源还有较多剩余,造成了机器资源浪费,因此内存资源紧张成为影响数据库实例部署密度的关键瓶颈。

Buffer Pool是内存资源消耗的最大头,如何实现Buffer Pool最优配置是影响全网机器成本的关键,同时也是影响数据库实例性能的关键,因此我们将智能参数优化重点放在了Buffer Pool参数优化。

对于大规模数据库场景,挑战在于如何为每个数据库实例配置合理的Buffer Pool Size,可以在不影响实例性能的前提下,Buffer Pool Size最小。传统大规模数据库场景为了方便统一管控,通常采用静态配置模板的配置数据库实例参数。

以阿里集团数据库场景为例,集团内提供了10种BufferPool规格的数据库实例供业务方选择。开发同学在申请实例时,由于不清楚自己的业务对BP的需求是什么,通常会选用默认配置规格或者较高配置规格。这种资源分配方式,带来了严重的资源浪费。

另外业务多样性和持续可变性使得传统依赖DBA手工调优方式在大规模场景下完全不可行,因此基于数据驱动和机器学习算法来根据数据库负载和性能变化动态调整数据库Buffer Pool成为一个重要的研究问题。

3、问题分析

从问题本身来看,缓存的大小(BP)与缓存命中率(hit ratio)是存在直接关系的。设想一下,如果可以找到一个公式BP=Function(hit_ratio),然后从业务方或者DBA的视角找到一个业务可接受的缓存命中率,就可以下调BP且不影响业务。

经过调研,我们发现在操作系统的Cache研究领域中,研究者已经对buffer size和hit ratio的对应关系有了很多研究,其中有研究表明在数据长尾部分这二者的关系服从Power Law分布,即:

IMG_0845.jpg

在集团DBA同学开发的Frodo工具帮助下,我们针对集团内的几个重要OLTP场景(例如购物车场景、交易支付场景)进行了不同BP配置的压测实验。实验结果也印证了前面的理论结果,在长尾部分MySQL的缓存确实是符合Power Law分布假设的。

插图.png

03.jpg

寻找合适的miss ratio

阿里巴巴集团中有3w+的数据库实例主节点,我们考虑从这3w+的数据库中寻找与待调整实例相似的实例,然后利用这些相似实例的miss ratio来找到待调整实例的目标miss ratio.

特征选择上,我们选用了CPU usage, logical read, io read, miss ratio, response time 等性能指标来描述一个业务workload,并对这些特征选取了几个统计量(如mean、media、70th percentile、90th percentile)作为具体的特征数值。

为了降低工作日、周末对数据的影响,我们选取了跨度4周的性能数据来做相似度计算,下图为两对相似实例的示例。
插图2.png

4、算法挑战

经过前部分的处理,公式、参数和目标mr都有了,已经可以代入公式计算出目标BP,接下来需要解决算法在工程落地过程中所面临的问题。

由于hit ratio这个指标并不能直接的反应数据库对业务的影响,导致业务方和DBA都没有直接的体感,并且该指标也不能用来直接衡量数据库业务稳定性。因此,受限于稳定性要求,该算法在无法给出对业务影响的量化数值情况下,尚不能落地具体业务。

针对这个问题,经过与DBA和业务方的多次讨论,我们发现业务方和DBA最关心的是数据库的Response Time(RT),尤其是数据库实例对应用服务时的最大RT。

设想一下,如果可以预测出BP调整后的数据库实例RT的最差值,也就是RT的上界RT upperbound,那么就可以量化的描述出调整BP之后对业务的影响,也就消除了业务方与DBA对该参数优化的担忧,算法就具备了落地生产环境的必要条件。于是,我们对数据库实例RT upperbound进行了算法预测。

RT预测模型

针对RT预测问题,我们提出了一个pairwise的DNN模型,具体的结构如图:

3 上午9.39.09.png
02.jpg

该DNN网络模型中采用了全连接形式,激活函数为ReLU,隐藏层节点数分别为100,50,50。

IMG_0844.jpg

实验

在预测RT的实验中,我们对比了包括线性回归模型(LR)、XGBoost、RANSAC、决策树(DTree)、ENet、AdaBoost线性回归(Ada)、GBDT、k近邻回归(KNR)、bagging Regressor(BR)、extremely randomized trees regressor (ETR)、随机森林(RF)、sparse subspace clustering (SSC)等回归算法,DNN模型、添加了embedding层进行instance-to-vector转换的DNN(I2V-DNN)模型,以及pairwise DNN模型等深度学习算法。

I2V-DNN的结构如图:

4 上午9.39.09.png

为了证明该算法的普适性,我们从集团数据库的几个重要业务场景中选择了1000个实例,覆盖了不同读写比的示例,包括只读示例、只写实例、读写均衡实例等情况。

在评价算法效果方面,我们主要采用了如下3个评价指标:

标准.jpg

其中,AMRAE可以评估出RT预测结果的误差比例,MAE用于衡量RT预测的平均误差,UMAE用于衡量RT预测值低估的情况。

在实验数据集上,RT预测结果对比如图:

5.png

由上图看出,PW-DNN模型在AMRAE这一指标上对比其他算法优势比较明显,综合其他指标,PW-DNN模型的算法效果最好,所以我们最终选择用来预测RT的算法是PW-DNN。

实际效果

为了更加直观的观察实例变更BP前后的变化,我们随机选择了10个实例来展示调整BP前后数据库各项指标,数据如图:

6.png

从上图中可以看出,不同规格实例在调整BP之后的RT与调整之前的RT相差不大(实例1除外)。通过QPS、CPU usage可以看出,调整前后的业务访问量相差不大,并且资源消耗很接近,但节省了不同幅度的内存。

在实例1中出现了调整后RT大幅上升的情况,经过对该case的仔细排查发现,该业务的日常QPS非常低,耗时占比最高的只有一个query,在调整后该query查询的值不一样,导致logical read和physical read升高很多,因此最终平均RT的值也升高很多。但是调整后RT的绝对值并不大,没有发生慢SQL异常,对业务来说是可以接受的,因此没有触发回滚操作。

5、落地

我们实现了一个端到端的算法落地流程,从数据采集到BP优化指令的执行。该系统包含4个主要模块,分别是指标采集、数据处理、决策和执行,模块设计如图:

7.png

  • 指标采集:数据库管控平台已经实现对集团内全部数据库实例的指标数据采集,覆盖了算法所使用的各项指标;
  • 数据处理:采集后的指标经过流式处理进行不同窗口维度的统计汇总,并存储在odps中供算法使用;
  • 决策:本文算法的具体实现部分,读取odps中存储的指标统计数据,经算法模型计算得到待优化实例调整后的BP值;
  • 执行:数据库管控平台对BP优化指令进行专项实现,并调度该优化操作的具体执行时间窗口,在符合发布约束的前提下高效执行该操作。

稳定性挑战

由于降低BufferPool配置的这个操作是个会降低稳定性的操作,一旦操作不当,轻则给DBA带来额外工作,重则引发业务故障。因此,该项目受到了BU内DBA和各稳定性相关同学的挑战和压力。

我们主要采取了多项措施来确保业务稳定性,具体包括:

  1. 算法模型: 调整BufferPool大小与缓存命中率映射关系的敏感系数αα,使调整结果较为保守;
  2. 在线调整:我们仅针对可online调整参数的实例进行调整,避免因MySQL内核原因导致MySQL crash的情况;
  3. 灰度策略:全网规模化参数调整采用了严格的灰度策略,最开始由业务DBA根据算法给出的BP大小进行少量实例调整,确保业务稳定;然后通过较多实例的白名单机制,仅对白名单中的实例自动调整BufferPool大小,在指定范围内实例上进行灰度;最后,在业务DBA确认过非核心实例上,严格按照发布流程和管控流程进行规模化全自动操作,并严格限制每次操作的数量。
  4. 流程闭环:从数据采集,BP大小决策、自动化BP调整到调整后的量化跟踪,以及回滚机制,整个流程闭环,每天发出调整后的统计分析报告。

6、成果

经过算法探索和端到端自动Buffer Pool优化流程建设,FY2019集团内全网最终优化 ~10000 个实例,将整体内存使用量从 217T内存缩减到 190T内存,节省 12.44%内存资源(27TB)。

7、未来

  • 业务方面,FY2020我们一方面继续扩大BP优化的实例范围以节省更多的内存资源;另一方面将继续优化该算法模型通过HDM产品输出到公有云,为云上用户提供数据库实例规格建议。
  • 技术方面,我们将从Buffer Pool参数优化扩展到数据库其他性能参数优化,探索多性能参数之间的关系及影响,建立基于数据库负载和性能关系影响模型,从整个数据库实例视角进行统一数据库参数优化。

活动预告

嗨!这有一封Alibaba Night的邀请函!

在数据库领域顶级会议VLDB 2019

听阿里巴巴技术专家分享数据库洞察

8月29号 19:00-20:30(当地时间)

See you in Los Angles !

邀请海报.jpg

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
29天前
|
存储 人工智能 Cloud Native
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
在9月20日2024云栖大会上,阿里云智能集团副总裁,数据库产品事业部负责人,ACM、CCF、IEEE会士(Fellow)李飞飞发表《从数据到智能:Data+AI驱动的云原生数据库》主题演讲。他表示,数据是生成式AI的核心资产,大模型时代的数据管理系统需具备多模处理和实时分析能力。阿里云瑶池将数据+AI全面融合,构建一站式多模数据管理平台,以数据驱动决策与创新,为用户提供像“搭积木”一样易用、好用、高可用的使用体验。
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
|
21天前
|
关系型数据库 MySQL Linux
Linux环境下MySQL数据库自动定时备份实践
数据库备份是确保数据安全的重要措施。在Linux环境下,实现MySQL数据库的自动定时备份可以通过多种方式完成。本文将介绍如何使用`cron`定时任务和`mysqldump`工具来实现MySQL数据库的每日自动备份。
44 3
|
23天前
|
SQL druid 数据库
如何进行数据库连接池的参数优化?
数据库连接池参数优化包括:1) 确定合适的初始连接数,考虑数据库规模和应用需求;2) 调整最大连接数,依据并发量和资源状况;3) 设置最小空闲连接数,平衡资源利用和响应速度;4) 优化连接超时时间,确保系统响应和资源利用合理;5) 配置连接有效性检测,定期检查连接状态;6) 调整空闲连接回收时间,适应访问模式并配合数据库超时设置。
|
1月前
|
NoSQL Cloud Native atlas
探索云原生数据库:MongoDB Atlas 的实践与思考
【10月更文挑战第21天】本文探讨了MongoDB Atlas的核心特性、实践应用及对云原生数据库未来的思考。MongoDB Atlas作为MongoDB的云原生版本,提供全球分布式、完全托管、弹性伸缩和安全合规等优势,支持快速部署、数据全球化、自动化运维和灵活定价。文章还讨论了云原生数据库的未来趋势,如架构灵活性、智能化运维和混合云支持,并分享了实施MongoDB Atlas的最佳实践。
|
28天前
|
缓存 监控 关系型数据库
如何根据监控结果调整 MySQL 数据库的参数以提高性能?
【10月更文挑战第28天】根据MySQL数据库的监控结果来调整参数以提高性能,需要综合考虑多个方面的因素
71 1
|
2月前
|
NoSQL Cloud Native atlas
探索云原生数据库:MongoDB Atlas 的实践与思考
【10月更文挑战第20天】本文探讨了MongoDB Atlas的核心特性、实践应用及对未来云原生数据库的思考。MongoDB Atlas作为云原生数据库服务,具备全球分布、完全托管、弹性伸缩和安全合规等优势,支持快速部署、数据全球化、自动化运维和灵活定价。文章还讨论了实施MongoDB Atlas的最佳实践和职业心得,展望了云原生数据库的发展趋势。
|
2月前
|
SQL 关系型数据库 MySQL
Go语言项目高效对接SQL数据库:实践技巧与方法
在Go语言项目中,与SQL数据库进行对接是一项基础且重要的任务
83 11
|
2月前
|
SQL 存储 关系型数据库
添加数据到数据库的SQL语句详解与实践技巧
在数据库管理中,添加数据是一个基本操作,它涉及到向表中插入新的记录
|
2月前
|
Rust 前端开发 关系型数据库
Tauri 开发实践 — Tauri 集成本地数据库
本文介绍了在 Tauri 框架中集成本地数据库的几种方案,包括直接绑定 SQLite、使用第三方数据库库和使用 tauri-plugin-sql-api 插件。最终选择了 tauri-plugin-sql-api,因为它集成简单、支持多种数据库类型,并且与 Tauri 框架深度整合,提升了开发效率和安全性。文章详细介绍了如何安装和使用该插件,以及如何编写核心代码实现数据库操作。
180 2
|
2月前
|
SQL 关系型数据库 数据库
SQL数据库:核心原理与应用实践
随着信息技术的飞速发展,数据库管理系统已成为各类组织和企业中不可或缺的核心组件。在众多数据库管理系统中,SQL(结构化查询语言)数据库以其强大的数据管理能力和灵活性,广泛应用于各类业务场景。本文将深入探讨SQL数据库的基本原理、核心特性以及实际应用。一、SQL数据库概述SQL数据库是一种关系型数据库
74 5