RDS最佳实践 用户版 玄惭20140825.pptVIP

Confidential 思路+分类 .业务带来的QPS压力，达到数据库的瓶颈 .劣质的分页，排序查询导致CPU消耗过高 .无索引或劣质的索引导致查询效率过低 .函数计算和隐士转换导致索引不能使用 .MySQ子查询导致性能下降 .MySQL myisam引擎查询堵塞更新 .系统压力高写入，高更新带来的容量瓶颈 .SQL磁盘排序导致临时空间暴增 .长时间未提交的事务导致系统空间暴增 .大字段的频繁更新导致日志空间暴增 RDS最佳实践 阿里巴巴数据库技术 - 玄惭 * 我们的团队 .我们来自阿里集团数据库技术团队，负责维护RDS所有线上的数据库实例， .团队成员里有去IOE的直接操刀人，也有丰富双11经验的工程师 .涵盖了：Oracle，MySQL，SQLSERVER，Postgresql * 目录 最佳实践-优化路线图 最佳实践-定位瓶颈 最佳实践-设计优化 最佳实践-SQL优化 最佳实践-RDS弹性升级 * 我们使用RDS中遇到了什么？ 为什么我的RDS慢了？ 为什么我的RDS cpu ，iops，连接数 100%？ 为什么我的RDS 空间满了？ * 最佳实践-路线图 定位瓶颈 设计优化 1.首先定位系统的瓶颈，判断引起数据库瓶颈的原因 2.定位瓶颈后，根据应用访问特点，从应用设计和SQL优化上来优化数据库的访问 3.对数据库处理能力进行升级：弹性升级，只读节点 cpu、io conn、disk cache 读写分离 最佳实践路线图： DB扩容 弹性升级 SQL优化 分页、排序 索引、子查询 * 最佳实践-定位瓶颈 定位瓶颈 CPU IO 连接数 disk 性能瓶颈 空间瓶颈 * 最佳实践-设计优化 设计优化 .水平拆分： 所有的业务全部集中在一个实例中，需要对业务进行拆分，解耦 .增加缓存： 根据业务特点，实现应用缓存 .读写分离： 根据业务特点，实现读写分离 .数据库设计： 索引设计，主键设计，引擎设计，字段设计 性能瓶颈 * 应用设计优化 .水平拆分案例场景-电商CRM营销平台，用户数量增加，高峰RDS cpu 100% 应用特点：应用设计之初就考虑按照商家维度进行分库 应用可以灵活控制一个数据库中存放的商家数量 一个RDS存放多个DB，RDS压力上来后，把DB拆到其他RDS 最佳实践： MySQL支持最大DB：200，SQLSERVER支持最大DB：20 RDS支持实例间的DB迁移； Database A Database B App App Database A Database B App App * 应用设计优化 .缓存使用场景-新闻客户端app，热点新闻时候，RDS响应缓慢，连接数 100% 应用特点：以90%为查询，10%为写和更新 应用使用OCS作为缓存，减小了数据库的访问次数 新闻点击量定时异步更新到数据库中，减小了数据库的更新次数 图片存放到OSS，支持CDN加速 最佳实践： SLB+OCS+RDS+OSS已经成为众多用户的经典组合 RDS App RDS App App App OCS (cache) OSS App 90% select 10% U/I * 应用设计优化 .读写分离场景-报表统计业务开启时候影响前台应用访问，RDS cpu 100% 应用特点：主库承担着前台高并发的写入，更新，查询 同时也需要定时对数据做一些有复杂统计报表计算 采用只读节点的方案，将报表统计业务拆分到只读节点上 最佳实践： 只读节点在只支持MySQL 5.6版本，同时一些create as select的操作不能完成 主节点在高压力的更新下，只读节点在会出现延时 RDS App RDS App RDS 只读节点 Write/Read sum/count Write/Read App sum/count * 最佳实践-设计优化 一.主键设计：使用自增id主键 在开始表设计之初就默认加上自增主键 .自增型主键以利于插入性能的提高 .自增型主键设计可以降低二级索引的空间(MySQL)； 最佳实践（以MySQL为例）： create table t( id bigint not null auto_increment ..... primary key(id) ) engine=innodb * 最佳实践-设计优化 二.引擎选择：使用innodb引擎 最佳实践： create table t( id bigint not null auto_increment ..... primary key(id) ) engine=Innodb 引擎