阿里巴巴云时代的数据库管理
阿里巴巴云时代的数据库管理 目录 阿里数据库技术团队概述 && 个人简介业务发展与规模化挑战与机遇 : 性能 系统性问题 多样化 DBA 的挑战与进化云时代 : 让研发具备 DBA 的能力
个人简介 阿里巴巴数据库团队高级专家 高性能 MySQL 第三版 译者 09 年研究生毕业加入阿里数据库团队, 负责淘宝核心数据库运维 管理 优化 配置, 构建了淘宝数据库第一代 MySQL 运维监控系统 2013 年开始支持阿里云数据库 RDS 运维与线上故障处理, 并开始探索并实践数据库服务产品化之路, 向用户提供数据库管理 数据传输 数据库优化等服务产品 个人博客 :http://www.orczhou.com Google: orczhou
阿里巴巴数据库技术团队概述 负责阿里旗下所有子公司的数据库管理 负责历年双 11 双 12 春节红包等大型活动的数据库容量规划 架构升级 运行稳定性等 主导了阿里去 IOE 异地多活等架构落地, 负责阿里巴巴 MySQL 内核研发 研发了 idb( 企业数据库研发流程平台 ) OceanBase 云平台 数据管理 DMS 数据传输 DTS 等云产品
数据库团队的进化 运维工具时代 Oracle 小型机 存储 脚本 平台与服务时代 双 11 去 IOE 异地多活 云服务时代 云计算 OceanBase Docker DevOps 自助
来自业务的压力 2012 年 : 某核心集群总共执行 293 亿次 SQL/ 天, 集群总 QPS 达 86 万 / 秒, 集群 TPS11 万 / 秒, 单机 QPS 高达 6.5 万 / 秒 2015 年 : 约 500 万 QPS
规模化与性能优化 简单的数学 :5% 的性能提升意味什么? 10000 台主机 *5 万 *5% = 2500 万 10000 台主机 *5 万 *10% = 5000 万 技术进化 1: 对性能极致的追求
对性能极致的追求 : 电商库存场景 原生 MySQL 版本事务数 :550 业务 : 每秒卖出多少商品 成本巨大 架构复杂
对性能极致的追求 : 电商库存场景 Version 1 InnoDB Strict Concurrency Version 2 commit on success select from update Version 3 Row Cache Group Update
对性能极致的追求 : 电商库存场景 Transactions per Second 45000 40000 35000 30000 25000 20000 15000 10000 5000 0 1400 1300 40000 1200 1000 800 600 450 400 5500 200 90 550 1400 7 0 Original Strict Hints + Strict Doing Responce Time / milliseconds TPS RT
对性能极致的追求 : 电商库存场景 T1 Transaction model: 1 begin; 2 insert normal row; 3 update hot row; 4 selecthot row; 5 commit; Deadlook Searching T2 T3... T1000 lock_sys->mutex InnoDB Row Locks hot rows normal rows T1 T2 InnoDB Concurrency InnoDB Row Locks lock_sys->mutex InnoDB Concurrency normal rows normal rows T3 T4 T5... hot rows normal rows normal rows Limit The Waiters
对性能极致的追求 : 电商库存场景 Transaction model: Transaction model: 1 begin; 1 begin; 2 insert normal row; 2 insert normal row; 3 select * from update hot row; 3 update hot row; 4 commit; 4 select hot row; 1 5 commit; st step 2 nd step Transaction model: 1 begin; 2 insert normal row; 3 select * from update commit_on_success rollback_on_fail
对性能极致的追求 : 电商库存场景 自动热点识别 批量提交
规模化与系统问题 简单的数学 : 如果某个系统正常运行十年出一次故障, 那么运行一万个该系统的实例, 每个月会有多少次故障? (1/10/12)*10000 = 83.33
规模化与系统问题 标准化 : 让系统更稳定 上线前压测提升稳定性 让自动化成为可能 每次解决一个问题, 其实是解决了整个平台的问题 解决每一个暴露的系统问题
系统问题案例 :Bug#77572 现象 :5.6 在 online DDL 的时候, 如果其他客户端写入数据出现了 UK 冲突后, 那么会导致 online DDL 失败 DDL 表有 UK 键 DDL 的表比较大时会出现 DDL 时其他客户端写入了冲突数据会出现
系统问题案例 :Bug#77572 背后的原因分析 : 在 Online DDL 过程中, 会记录所有对目标表的 PK 的修改行为, 即 Online Log 在 Insert 的时候先插入 PK, 发现成功, 记录一条 Insert log 再插入 UK, 发现冲突, 回滚 Insert 操作, 记录一条 Delete log 全量数据拷贝完成后, 在应用增量 Online Log 的时候, 在应用第一条 Insert log 时, 发现 UK 冲突, 报错退出,DDL 失败
系统问题案例 :Bug#77572 官方态度 : 是一个明确的 Limitation; 只修改报错内容 ; 阿里数据库 : 修复该 bug 通过平台自动化处理
业务扩张与多样化 淘宝 1688 支付宝 余额宝 高德 阿里云 优土 菜鸟 天猫 速卖通 口碑招财宝 UC 钉钉 虾米 数据库技术与产品服务 MySQL OceanBase MongoDB SQLite
阿里巴巴云时代的数据库管理 目录 阿里数据库技术团队概述 && 个人简介业务发展与规模化挑战与机遇 : 性能与系统稳定性 DBA 的挑战与进化云时代 : 让研发具备 DBA 的能力
DBA 的挑战与进化 不再处理重复的日常 制定标准与规范 解决深入的 极端的系统问题 形成新的最佳实践 解决多样化需求与标准化的矛盾 让新技术成为新常态 专职的 DBA 会越来越少 : 平台会取代 DBA 的所具备的基础能力专业的 DBA 会越来越贵 :DBA 的专业能力会被平台所放大
云时代 : 让研发具备 DBA 的能力 idb: 企业数据库研发流程平台 流程与规范 性能优化与诊断 研发 idb 平台
让研发具备 DBA 的能力 : 流程与规范 研发直接变更 DBA 手动 快 但是质量良莠不齐 质量高 但是慢 结构规范索引合理 SQL 高效 引擎使用 InnoDB 不使用外键 表必须加上注释 尽量使用 UNSIGNED 字符集使用 UTF8 默认定义为 NOT NULL 表必须有数值主键 (InnoDB) 索引命名规范 不要过多使用单列索 字符串尽量定义前缀 质量高 但是略慢 DB Task 自动化 尽量使用索引 尽量使用索引覆盖 核心 SQL 避免复杂逻辑 : 计算 避免 WHERE 中的隐式转换 建议使用合理的分页实现 快 质量比较高 研发自助完成
让研发具备 DBA 的能力 : 诊断与优化 内部用户 idb SQL 诊断引擎 空间诊断 诊断与优化 会话诊断 安全诊断 高级功能 全链路诊断 云用户 DMS 索引推荐 SQL 改写 专业建议 空间分布 空间增长 碎片分析 会话来源 等待事件 连接增长 账号安全 配置安全 SQL 注入分析 实时预警 容量评估 手机 APP 健康评分 锁诊断 配置诊断 网络诊断 主动实时采集 操作链路 jdbc staragent/ssh 基础采集与流计算平台 Top SQL SQL 直方图 Top 空间 性能基线 空间增长基线 会话基线 性能指标 SQL/ 日志专业数据 CPU 内存 QPS TPS Net in/out, SQL 流水 慢 SQL 会话 SQL alert log, 锁 表容量 会话 账号 参数 状态, 公司内部 DB RDS MySQL MongoDB OceanBase SQLServer ECS 自建库
挑战还在继续, 欢迎加入