关于数据库工作方面的一些感悟

原创 2016年08月07日 08:57:00

之前搞oracle,最近在搞mysql,之前没有接触过mysql,所以经过了一段时间的接触后,有一些自己的感悟。抛出深入到源码层面,总体的个人感觉是搞3年oracle的可以在3个月内搞定mysql,搞3年mysql的人不太可能在3个月内搞定oracle,mysql与oracle的管理上主要在下面几点有所区别。
备份恢复监控
备份方面差别不是很大,都是有逻辑备份和物理备份,有点区别的地方就是mysql的增量备份上,使用的第三方的软件xtrabackup,不是自带的,oracle的rman是原生的,量小的库都使用逻辑备份即可。
恢复上,根据自己的经历,oracle出问题的情况较多,数据文件的损坏,日志文件的损坏,控制文件的损坏等等,rac的异常等,每种情况都要根据具体的情况去处理,复杂度比较高,mysql出现的问题比较少,都是一些简单的故障,基本上能很快的修复,复杂度较低。
监控上,基本上监控的方法一样,没什么说的
日常管理上
个人感觉这部分是差别最大的,一般情况下oracle的dba管理的oracle数据库数量可能不是很多,通常一个业务上顶多rac+dg就能搞定了,但是mysql的数据库数量是非常多的,通常是上百台的实例,数量上的差距就导致了管理的理念上的不同,这个可能也与我的工作经历有关,oracle的工作经历是支持客户为主,主要是解决单个环境下的问题,oracle自带的工具可以很方便的定位处理问题,所以对于平台化管理数据库的概念上基本没有,而对于mysql,面对如此众多的实例,单个的管理肯定是行不通的,要从系统的角度去考虑怎么能自动化,平台化,这样才能节省管理上的支出,而系统化平台化的前提是标准化,没有统一的标准,在后续做平台,系统的时候是非常痛苦的。在标准化的层面,有如何统一的部署,统一的监控,统一的配置,端口管理等等。
部署结构上
oracle的部署结构可以很简单,所有高可用,异地备份实现等都可以通过自带组建实现,可选择的余地不是很多,而对于mysql的高可用,有很多实现方式,很多的可选择方式,这个就要看公司是怎么去选型了,有的用mha,有的就自己去实现,所以对mysql来说,在某一方面都有很多的可选项,这个要去评估哪个是最适合自己的,通常这部分也比较占时间,要去做很多测试。对于mysql,尽管有很多的开源软件可以使用,但在线上来讲,还是要能hold住,所以还是需要开发很多自己的一些工具,系统。
在业务开发方面
由于oracle很完善,所以在部署上线后,一般都不需要去管oracle,很多不需要考虑系统化管理,同时使用oracle的系统一般都很复杂,在出现问题的时候,可能需要dba有深入的业务知识,对于编写sql有较高的要求。mysql的dba基本上的开发都投入到了系统平台的建设,同时使用mysql的业务都比较简单,sql也很简单所以对sql,业务要求较低,java,python等开发能力要求较高。
现在考虑到的只是上面的几点,后续有感悟继续补充

后续补充–关于nosql的感悟
搞redis,mongodb也有段时间了,之前很多人说nosql会替代sql,当时对这种说法就很不屑,说出这种话的基本上都是不懂数据库的,sql与nosql只能是互相补充,互相共存。以后没准那个牛逼的公司会出个牛逼的库,把2者的特性都集中在一个产品上,首先说redis,这个东西很简单,原则上是只放缓存的数据,部署也很简单,对于集群方面,自己没有测试过redis cluster,只是用了codis,集群的部署上向来不是简单的,组件很多,但部署上后,基本没有出现过问题,上了后是高可用的,不用担心挂掉。总体上redis的问题是很少的,基本没有投入过多的精力。对于mongodb,这个是介于传统关系数据库与redis类库的一种中间形态的库,有传统库上的概念,也有缓存类型库的概念。部署的方式有很多,线上基本都是replica set的模式,但是最好还是用shared cluster这种形式,做成了集群后,也是更加有保障,shared cluster的部署比较简单,但是看了官方文档,感觉数据量上来后,还是有很多维护方面的坑需要注意,线上的量还没有那么大,肯定就踩不到了,总体来说,nosql的东西还是比sql的东西简单很多的,毕竟放的不是强一致性的数据,丢些也可以接受。

现在个人感觉运维这个工作可以分为几个阶段:
1第一个阶段,能搞定单机,常见运维问题能处理
2第二个阶段,优化,能对一些场景提供解决方案
3第三个阶段,大量库的管理,能系统化的去管理大批量数据库
4第四个阶段,能在整体上对大量数据库又系统的维护方案。
5第五个阶段,脱离运维本身了,应该进入架构的层级了

上面的排除一些特例,比如oracle的应用数据量很大,部署是dg+多个节点的rac,这种的能维护好也很好了。但是运维的价值体现还是应该能出一些产品出来,还是要能开发,还是要devops。

版权声明:本文为博主原创文章,未经博主允许不得转载。

写给想从事数据库方面工作的朋友

经常有人问我,有关数据库方面的职位、职业规划、转型等相关的问题。对于经常听到的“DBA(数据库管理员)、数据库开发工程师、数据挖掘工程师、数据库架构师......”这些职位,之前我也比较迷惑,甚至搞不...
  • dinglang_2009
  • dinglang_2009
  • 2012年04月12日 13:02
  • 31675

使用PLSQL导入导出数据库

Oracle如何实现创建数据库、备份数据库及数据导出导入的一条龙操作 Oracle中对数据对象和数据的管理,无疑都是使用PL/SQL Developer来进行管理,该工具也提供给我们很多方便...
  • lifuxiangcaohui
  • lifuxiangcaohui
  • 2012年07月20日 16:14
  • 59832

关于数据库工作方面的一些感悟

之前搞oracle,最近在搞mysql,之前没有接触过mysql,所以经过了一段时间的接触后,有一些自己的感悟。抛出深入到源码层面,总体的个人感觉是搞3年oracle的可以在3个月内搞定mysql,搞...
  • aoerqileng
  • aoerqileng
  • 2016年08月07日 08:57
  • 727

在此提醒广大web程序员们一定要作好数据库备份工作

今天公司的同事突然告诉我某个项目的数据全部错乱了,跑到全部都另一个项目去了。 我当时就懵了,我什么时候改过了。后来忆起昨天测试的时候有直接把整个本地数据库覆盖到上面去了。 之后没两个小时听说这个项...
  • u012187684
  • u012187684
  • 2014年01月17日 20:05
  • 586

一些数据库优化方面的经验

用PreparedStatement 一般来说比Statement性能高:一个sql 发给服务器去执行,涉及步骤:语法检查、语义分析, 编译,缓存 “inert into user values(1...
  • lixiaoming000
  • lixiaoming000
  • 2013年10月29日 15:29
  • 1176

SQL数据库优化经验

一、人们在使用SQL时往往会陷入一个误区,即太关注于所得的结果是否正确,而忽略了不同的实现方法之间可能存在的性能差异,这种性能差异在大型的或是复杂的数据库环境中(如联机事务处理OLTP或决策支持系统D...
  • emailqjc
  • emailqjc
  • 2009年08月05日 11:34
  • 6051

关系数据库是如何工作的

一提到关系型数据库,我禁不住想:有些东西被忽视了。关系型数据库无处不在,而且种类繁多,从小巧实用的 SQLite 到强大的 Teradata 。但很少有文章讲解数据库是如何工作的。你可以自己谷歌/百度...
  • zcjcsdn
  • zcjcsdn
  • 2016年08月18日 10:44
  • 2309

【连载】关系型数据库是如何工作的?(1) - 前言

译者说明这一系列博文翻译自一篇国外博主Christophe的博文《How does a relational database work》。该博文详细介绍了关系型数据库是如何工作的,其详实程度堪比专业...
  • u013721793
  • u013721793
  • 2016年05月03日 20:38
  • 532

数据库的一些常见问题

分布式数据库: 数据库应该常注意的点: 1、事务 2、主从同步 3、分库 4、分表 5、数据库恢复和备份 6、数据库复制 7、垂直拆分和水平拆分 (分库和分表) 垂直拆分: 根据业...
  • onedaycbfly
  • onedaycbfly
  • 2017年06月17日 14:12
  • 141

工作方面的一些事

  • jhy088
  • jhy088
  • 2009年05月08日 22:04
  • 286
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于数据库工作方面的一些感悟
举报原因:
原因补充:

(最多只允许输入30个字)