Transcript 邵宗文：如何利用

高可用数据库平台架构
及日常管理经验介绍
研发中心
邵宗文
[email protected]
传统基础设施平台
无法解决拥堵问题，不适合繁华地区。
高可用的基础设施平台
为何需要搭建数据库平台







各大部门自己申请数据库服务器，运维成本过高。
操作系统，数据库版本不一。
出现突发热点，造成数据库读写访问巨增，受限于部门数
据库资源机器，而错失扩大业务良机。
缺乏统一的数据库服务器性能监控和报警。
新项目产品上线数量过多，单个部门的数据库资源无法满
足。
无专门的人进行全局数据库各种读写操作统计的分析。
存在磁盘故障导致不可访问，无自动切换的问题。
目前新浪数据库平台现状






多个IDC数据中心
Mysql5.0
数据库服务几百台.(不断增长中)
约有几百T的数据量.（线上+备份存档）
约有几百个项目产品使用。
平台重点产品有：财经，体育，统一通行证，无
线wap，读书，音乐，空间, 通用投票，博客圈，
博客杂志，汽车，科技，发布系统等。
不可避免的故障
机器故
障容错
自动化
监控报
警
高可用
数据库
架构
误操作
之后快
速恢复
IDC级
容灾
数据库网络结构简图
数据库平台的其他好处：



提升全球扩展性，包括新浪香港和北美等都能共
享到重要数据资源，如体育，财经数据。
让用户访问就近IDC，提升服务质量。
很多刚开始的项目可以混用同一个服务器资源。
关于一些数据库日常管理的经验介绍






如何去了解应用项目的数据库使用情况？
大项目的有效切分方式？
一个库下多少表比较合适？
长期运行的数据库，如何避免表性能下降？
减少慢查询语句的方法有哪些？
数据库服务器负载急剧上升的主要原因？
不要超过自身运输能力
数据库应用项目规划和优化原则
1. 了解自己的应用

应用类型
读多写少（如体育，读书），读写比例差不多（如音乐），和写多读少（如
投票，统计）

预计数据量
半年？一年？后续扩展？ 决定单表还是多表，扩展的方法(hash分表)

预计访问量
多少读？多少写？峰值？ Com_select,Com_update(insert,delete)

实时数据和非实时数据
哪些必须实时查询？哪些可以预先准备或可以cache？哪些用于统计汇总？

时间的要求
实时性高的项目，如财经，体育，实时性低的项目如博客圈等。
合理分配调度，实现全球快速到达。
2.如何对大应用项目切分


保证数据库单个实例尽量不要超过150G。
切分尽量多的小实例，一个机器跑7-8个实例，平
常load avg不超过1-2，峰值不超过6-7为合理。

分表原则的选择
按时间(财经)
按ID号hash分(统一通行证)
按业务项目(通用投票)
3. 单库表数量的限制
-- 为什么？
- 受文件系统操作限制，文件数过大需要更多文件句柄，
且大目录 操作造成复制、压缩、备份效率低。
- 打开表占用数据库资源（table_cache）
√ 建议一个库不应超过300-400个表
√ 建议一般带char字段的表不应超过500万rows.基于数字
的字段为主的表不要超过1000万rows.
4.表的优化



正确使用索引，避免全表搜索
使用定长表,且定期做OPTIMIZE TABLE命令（注
意这个命令会锁表，请在数据库访问小的时候做）
在对大表进行添加索引，一定要选择访问小的时
间段做，否则会导致严重问题。
注:一般临晨2-3点时候是大部分项目访问的低谷。
5.索引优化、选择和试验

稳妥地改进
 将需要优化的相关表复制到测试环境
 在测试环境启动一个测试daemon，关闭query
cache
或是使用select SQL_NO_CACHE 方式。
 未优化时测试若干次查询时间，以及explain检查扫描
集。
 选择合适的索引试验建立。可以通过use index(xx)来强
制使用。检查是否有效。
 测试查询时间变化，反复试验得到最优结果

保持关注，根据情况随时改变索引设置
6.关于排序的问题


尽量使用带主键的字段做order by 的排序
尽量不要多提供页面的查找（最好只提供100页
内），避免机器爬虫抓取数据，导致数据库压力
负载过高。因为做order by field1 limit xxxxxx,20
是非常消耗数据库资源。
结语
“结合实际情况不断优化”
“让数据库多做它擅长的工作”
 谢谢参与！
 问题和讨论