1 / 30

数据库的优化和管理

数据库的优化和管理. 盛大文学小说阅读网 李明珠 2012.07. 什么是数据库 ?. 保存数据的仓库就是数据库。 除了 mysql 以外，还有： Memcache Redis MongoDB ……. 一、小说阅读网的技术架构变化 -1. 小说阅读网的技术架构变化 -2. 小说阅读网的技术架构变化 -3. 小说阅读网的技术架构变化 -4. CDN 是什么. LVS 是什么. 小说阅读网的技术架构变化 -5. 唯一不变的是变化. 大型网站的共同点： 负载大有突发流量 数据量持续增长 服务越来越复杂 业务持续变化 总结几点运维管理的经验：

hallam
Download Presentation

数据库的优化和管理

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 数据库的优化和管理 盛大文学小说阅读网 李明珠 2012.07

  2. 什么是数据库? 保存数据的仓库就是数据库。 • 除了mysql以外，还有： • Memcache • Redis • MongoDB • ……

  3. 一、小说阅读网的技术架构变化-1

  4. 小说阅读网的技术架构变化-2

  5. 小说阅读网的技术架构变化-3

  6. 小说阅读网的技术架构变化-4

  7. CDN是什么

  8. LVS是什么

  9. 小说阅读网的技术架构变化-5

  10. 唯一不变的是变化 大型网站的共同点： • 负载大有突发流量 • 数据量持续增长 • 服务越来越复杂 • 业务持续变化 总结几点运维管理的经验： • 系统优化是持久战 • 消灭单点是系统成熟的重要标志 • 系统监控很重要 • Cacti、短信报警、关键业务监控、性能监控、防黑监控

  11. 二、数据服务的稳定至关重要 MySQL是重点，常见问题： • 数据表慢查询 • 数据库同步和编码问题 • 数据库如何配合业务扩展 • 表数据量过亿如何管理？ • 其他数据库的管理

  12. 2.1 数据表慢查询 数据表慢查询定义： • 跟产品要求有关，一般来说超过0.2秒都属于很慢的sql了 木桶原理：数据库的性能由最慢的sql决定 如何避免慢查询： • SQL优化，explain，建索引 • 合理建表结构，选择合适的engine • 控制表的大小，加强监控 • 尽量避免联表查询，严禁跨库查询，分拆sql • 提高sql效率，严控产品上线流程

  13. 建表SQL示例： （注意索引） CREATE TABLE `pay_expend` ( `id` int(10) unsigned NOT NULL auto_increment, `pid` varchar(64) NOT NULL, `userid` int(10) unsigned NOT NULL, `type` tinyint(1) NOT NULL, `subject` varchar(255) NOT NULL default '', `amount` int(10) NOT NULL, `price` decimal(13,1) NOT NULL, `totalprice` decimal(13,1) NOT NULL, `time` int(10) unsigned NOT NULL, `user_level` tinyint(2) NOT NULL default '1', PRIMARY KEY (`id`), KEY `Index_pid` (`pid`), KEY `Index_userid` (`userid`,`type`,`time`), KEY `Index_time` (`time`,`type`) ) ENGINE=MyISAM DEFAULT CHARSET=gbk;

  14. Explain的使用 注意：explain只是一个辅助工具，实践才是检验真理的唯一标准。

  15. SQL优化实例 select a.userid, a.addtime, a.mobile From pay.pay_mobile_month a LEFT JOIN (select mobile,count(*) num from support.sohu_msg_status_log where gwdate>unix_timestamp('20120701') group by mobile) tmpON ( a.mobile=tmp.mobile ) Where a.addtime>unix_timestamp(20120710) order by a.addtime; 有趣的现象： SQL初学者很喜欢写长长的SQL； 希望一个SQL搞定好几个事情，但往往效率很差。

  16. SQL优化实例 select a.userid, a.addtime, a.mobile From pay.pay_mobile_month a LEFT JOIN (select mobile,count(*) num from support.sohu_msg_status_log where gwdate>unix_timestamp('20120701') group by mobile) tmpON ( a.mobile=tmp.mobile ) Where a.addtime>unix_timestamp(20120710) order by a.addtime;

  17. 建表SQL反面实例： （注意索引） CREATE TABLE `pay_mobile_month` ( `userid` int(10) unsigned NOT NULL default '0', `mobile` char(11) NOT NULL, `addtime` int(10) unsigned NOT NULL default '0', `status` tinyint(1) unsigned NOT NULL default '0', `endtime` int(10) unsigned NOT NULL default '0', PRIMARY KEY (`userid`,`mobile`), KEY `userid` (`userid`), KEY `status` (`status`), KEY `mobile` (`mobile`) ) ENGINE=MyISAM DEFAULT CHARSET=gbk;

  18. 优化后 select a.userid, a.addtime, a.mobile From pay.pay_mobile_month a LEFT JOIN pay.sohu_tmp_msglogtmp ON ( a.mobile=tmp.mobile ) Where a.addtime>unix_timestamp(20120710) order by a.addtime; 优化SQL重要原则： • 尽量避免联表，尤其是大表相联； • 严禁跨库操作； 尽量不要使用临时表； • 确定使用了index；

  19. 再谈： MyISAM 或 InnoDB ? MyISAM： • 适合大部分以查询为主的数据表 • 适合常有select count(*) 的sql查询 • 适合日志类型表，写入效率常比InnoDB还高 • 备份和运维管理较方便 • 缺点：1. 数据表和索引常需要repair 2. 表锁 InnoDB： • 适合有事务处理需求的情况：消费、注册 • 不适合数据经常会被删减，空间不释放 • 写入量多的表不一定选InnoDB 总的来说，大多数情况用MyISAM，事务处理用InnoDB。

  20. 为什么不能建外键？ • 不管哪种表，都不要建外键 • 尽量少使用存储过程。 为什么？ 原因： • KISS原则 =Keep It Simple Stupid • 业务逻辑前移原则

  21. 2.2 数据库同步和编码问题 数据表同步： • 选择需要同步的库和表 • 不是所有的数据库和数据表都需要同步，比如：统计和搜索应用 • 合理分担同步压力 • 例子： 移动机房数据同步 数据库编码： • 优先选择UTF8 • 如果无法选择，至少保证编码一致 • 导入导出注意编码问题 set names gbk

  22. 2.3 数据库如何配合业务扩展 业务的发展常常会有很多意料之外，比如： • 手机站半年流量增长4倍 • 暑期用户注册人数每天超过5万 • 哀悼日网站总访问量增100% 数据库： • 异常增长的监控 • 数据库可扩展设计 • 消灭单点，有灾备方案

  23. 2.3.1 数据库的监控 数据库的监控： • 数据表文件和数据量增量： 抓住主要矛盾 • 数据表是否损坏 • mysql是否可以正常访问 • 最大连接数和buffer是否设置正确 • 是否有异常慢查询堵塞

  24. 2.3.2 数据库的可扩展性 数据库的可扩展性： • 数据库分库原则：按业务划分 • 应用接口要符合OCP原则和KISS原则 • 一个软件服务应当对扩展开放，对修改关闭。（Open-Closed Principle ) • 例子： 小说正文数据服务接口 • 设计数据结构时，对未来2-3年做合理预期 • 避免考虑未来过长过细，技术架构一般2-3年都会变化 • 避免常识性的基本错误，比如：表索引。 • 一般来说，重建要比修改要省力 • 例子：重装系统常常比花时间修复系统漏洞要省时省力 • 例子：pay_expend重建索引

  25. 2.3.3 消灭单点、灾备方案 消灭单点： • Master DB是重点也是难点 • MMM 的尝试 • MM和Heart-beat配合使用 • Slave DB和LVS配合使用 • 重视数据备份和验证 • 监控和优化是常态 灾备方案： • 每个业务核心数据服务都需要有明确的灾备方案 • 什么是灾备方案： 就是一个服务或一个点出了问题，该如何处理。重要业务要有多项灾备方案。

  26. Master DB单点解决方案基本原理示意图

  27. 2.4 数据表过亿怎么办 数据表过亿怎么办： • 不要紧张，mysql很强大 • 例子： 07年做抓虾网的时候数据单表数据量接近4亿条 • 分表和归档是主要思路，如何分则要具体分析 • 按业务逻辑分 • 按时间周期分 • 按统计需求分 • 总表是否保留取决于业务需要 • 分表后的管理和数据统计需要提前考虑好 • 前台各数据接口尽量保持不变（OCP原则） • 数据文件存放和管理，历史数据同样需要备份

  28. 2.5 其他数据库的管理 Redis的管理： • 建议大家使用redis，不用memcache • 效率更高，数据更可靠 • master-slave管理 • 内存使用的控制 • 服务的监控 Session的管理： • 内存表方案 • 分布式存储方案 • 无状态验证方案

  29. 2.6 数据库优化和管理的重要原则 重要原则： • 增加系统冗余、提高可用性：消灭单点 • 设计可扩展的数据库结构 • 永远的监控，要对变化敏感 • 要主动出击，不要被动挨打 • 业务逻辑前移原则 • OCP 和 KISS原则 = Keep It Simple Stupid • 谨慎使用新技术，新技术常=不成熟不稳定 • 实践是检验真理的唯一标准

  30. Thank You ! 欢迎提问！

More Related