存档

文章标签 ‘随便说说’

【内容简介】
本书以 MySQL 数据库的基础及维护为切入点,重点介绍了 MySQL 数据库应用系统的性能调优,以及高可用可扩展的架构设计。
全 书共分3篇,基础篇介绍了MySQL软件的基础知识、架构组成、存储引擎、安全管理及基本的备份恢复知识。性能优化篇从影响 MySQL 数据库应用系统性能的因素开始,针对性地对各个影响因素进行调优分析。如 MySQL Schema 设计的技巧,Query 语句的性能优化方式方法及MySQL Server中SQL层和存储引擎层的优化思路。同时还分析了 MySQL 数据库中主要存储引擎的锁定机制。架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication 的利用、数据切分、如何使用 Cache 和 Search,以及 NDB Cluster等内容。高可用则主要包括 Dual Master、DRBD、NDB Cluster,以及系统监控等方面。
【作者介绍】
简朝阳,毕业于南京工业大学管理科学与工程学院,管理学学士。擅长MySQL & Oracle数据库应用系统的性能调优与高可用可扩展架构设计,有一定的对Java 和C语言基础。目前就职于阿里巴巴(中国)网络技术有限公司,曾参与过公司多个核心数据库应用系统的设计与实施,目前主要负责 MySQL 数据库应用系统的架构设计与相关维护工作。活跃于 iMySQLer 数据库论坛(http://imysqler.com) 和 MySQL 邮件组(mysqler@googlegroups.com, http://groups.google.com/group/mysqler)。
–EOF–
本书的作者是我的同事,2006年大学毕业后来到Alibaba DBA team,还记得当时DBA没有招聘应届毕业生的计划,但是在校园招聘中,他被评估为“潜力无限”的增值股,所以被破格录用。而我(一个刚刚上路的菜鸟DBA)是他的导师。事实证明,当时的招聘人员的眼光是犀利的,正如他的名字朝阳一样,他成长的速度超过了我们所有人的期望。从最初的Oracle DBA转型到MySQL方向后,迅速成为MySQL领域内的专家。
在这本书之前,中文版的MySQL图书要不是译作,要不就是官方文档的简单翻译,几乎没有自己的思想。而这本书则完全不同,首先它不是一本MySQL的入门书,也不是用命令堆砌的参考书,而是一本深入介绍MySQL原理的故事书。作者通过大量实际的案例,讲述了MySQL数据库优化原理,以及架构设计方面的内容,这些内容都是在实际工作中不断积累的宝贵财富,在其他任何文档中都找不到。
作者从一个应届毕业生到数据库大师,只花了三年时间,在这个过程中,我见证了他的成长,也从他的导师变成了学生(我也开始学MySQL啦)。在他的成长轨迹中,我看到了信念,坚持,行动和态度。对于每一个想成为DBA的年轻人来说,现在就像朝阳那样开始吧。
我们,依然在路上……

6 11th, 2009 | Filed under 一地鸡毛

DBA(DataBase Administrator )数据库管理员,我每次和公司其他非技术部门的同事解释我的工作的时候都要颇费口舌,直到最后如果他还是不明白的话,我只好说我们的工作其实和仓库管理员没什么区别,都是管理一个仓库。更多的时候,我还要解释数据库和数据仓库的区别(因为在公司里,我们是两个部门),一般我给出的解释是:DBA虽然是仓库管理员,但是里面的数据不是我们的,你如果需要数据的话,还得找数据仓库。
我把DBA分为三类:第一类:顾问型,他们属于DBA中的高端人才,经验丰富,技术全面,提供专业的数据库咨询服务或培训,擅长用偏门的技术解决问题。第二类:技术支持型,他们属于各集成商或者专业的数据库维护公司,最擅长搭建各种环境,从主机,存储到OS和数据库都很熟悉,经常troubleshooting各种数据库问题。第三类:运维型,他们维护自己公司的数据库系统,稳定是对他们的唯一要求,他们经常要和集成商或者应用开发人员打交道。这三类DBA中都有牛人,而且很多DBA并不局限于其中的一类,他们既是运维DBA,也提供数据库咨询或培训服务。
我们属于运维型DBA,但不同于其他公司的是,我们的数据库每天都要上大量的项目,数据库承受着巨大的压力。由于数据库的可用性基本上决定了网站的可用性,所以必须有人能够对应用加以控制,保证数据库被正确的使用,所以我们的DBA又分为产品DBA和开发DBA,其中产品DBA负责产品数据库的维护,包括主机存储等,而开发DBA则主要与开发人员打交道,为他们提供数据库方面的支持,并参与到项目的设计过程中,开发DBA的权力很大,当一个项目设计不合理,可能会对数据库造成危害时,我们有权力say:No!
我是公司的第一个开发DBA,在我没进公司之前,那时的硬件比较差,流程和规范也没有,经常上一个项目就把整个数据库搞宕机,DBA总是手忙脚乱的四处救火。开发人员只关注SQL是否能得到正确的结果,根本不关心SQL的性能,而如果当项目上线后再发现问题,代价非常高,所以当时的DBA老大就想到了开发DBA这么一个角色(感谢rudolf)。我第一阶段的工作,主要是优化每个项目的SQL,保证每条SQL是最优化的,通过建立适当的索引提高SQL的效率。刚开始优化SQL时,都是采用尝试的方式,就是不断调整执行计划并一次次测试,直到测试的结果满意,到后来就变成了先了解表和索引的状况,看到SQL后,最优的执行计划就在脑海中出现了,然后再去验证是否和我的想法一致。在这个阶段,通过不断建立流程和培训开发人员来简化我的工作。但我逐步发现,如果一个项目在前期设计时就不正确的使用了数据库,即一个不合理的设计,后期很难通过优化SQL来提高性能。第二阶段,我开始逐步参与到项目的设计中去,基于我对数据库的理解,给产品设计人员甚至需求方提供更好的建议。在这个过程中,最难的一件事就是如何说服别人作改变,我觉得最重要的就是信任感。虽然我经常say:No!但同时我一定会给出我的建议,通过一个个项目的证明,使得设计和开发人员越来越信任我并依赖我,后来的所有重大项目,设计人员都会找我商量并听取我的建议,这样我的工作就变得越来越简单。不过同时我也面临着一个问题:就是如何在项目开始时,就评估出对数据库产生的影响。首先你必须非常了解应用,哪些功能会被频繁使用到;第二你必须非常了解数据库,表,索引以及相关的SQL等等;第三你必须非常了解整个系统,当前的负载,逻辑读和事物数等等,根据这样一系列的信息,并结合以往的项目,给出一个综合的判断,事实上这是一个非常困难的事,很多时候我们也是凭借经验来判断。第三阶段,DBA开始与架构部门合作开发一些系统优化的项目,以前我们都是通过statspack发现一些TOP SQL,可能是执行计划不正确或者SQL不够优化,我们会要求开发人员修改。后来DBA就开始主动推动一些数据库优化项目,这些项目往往需要其他部门的协助,比如搜索引擎和架构部门,所以现在我们的很多项目,都是由DBA和架构部门共同来完成,比如今年我们的分布式数据库(amoeba 变形虫)项目。
后来,我转向了产品DBA方向,在这段时间内,我接触到了各种主机和存储,学习了很多硬件和OS的知识,同时对两种DBA的角色也有了更深的理解,产品DBA和开发DBA对于数据库的关注点是不同的,产品DBA更关注运行维护,troubleshooting,备份恢复等方面,而开发DBA更倾向于应用开发,性能优化等方面。
数据库未来发展的方向,智能化自动化一定是个趋势,各数据库厂商也为DBA提供了更方便更强大的管理和诊断工具。并且随着大家使用数据库的不断成熟,低级的错误越来越少见,我们不可能再通过调整某个“参数”就让系统性能大幅度得到提升,尤其是我们管理的数据库,参数基本上都已经是最优化了,调整的机会很少。那是不是都数据库都自动化了,就不需要DBA或者DBA的重要性降低了,我倒不这么认为。但是如果DBA只具备数据库的知识,应该是不足够了。未来的DBA不仅仅要了解主机,存储,操作系统,并时刻关注硬件发展趋势和数据库新特性以外,还应该朝着DA(Data Architect 数据架构师)的方向发展,从Database到Data就说明以后数据不一定在数据库里面了,从Administrator到Architect说明我们要懂架构,虽然我们不一定要懂得coding(PL/SQL不算)。对于开发DBA和产品DBA来说,只是工作职责上的侧重点不同,未来的环境肯定是要求DBA掌握更多方面的知识。另外,好的沟通能力和团队合作能力对于一个优秀的DBA也是必不可少。
–EOF–

3 21st, 2009 | Filed under 大话技术
标签: