【经验】7年数据库经历的感悟

发布作者：微思网络   发布时间：2016-11-25   浏览量：0次

备份恢复监控 

  备份方面差别不是很大，都是有逻辑备份和物理备份，有点区别的地方就是mysql的增量备份上，使用的第三方的软件xtrabackup,不是自带的，oracle的rman是原生的，量小的库都使用逻辑备份即可。 
        恢复上，根据自己的经历，oracle出问题的情况较多，数据文件的损坏，日志文件的损坏，控制文件的损坏等等，rac的异常等，每种情况都要根据具体的情况去处理，复杂度比较高，mysql出现的问题比较少，都是一些简单的故障，基本上能很快的修复，复杂度较低。 
       监控上，基本上监控的方法一样，没什么说的。 

日常管理上 

个人感觉这部分是差别最大的，一般情况下oracle的dba管理的oracle数据库数量可能不是很多，通常一个业务上顶多rac+dg就能搞定了，但是mysql的数据库数量是非常多的，通常是上百台的实例，数量上的差距就导致了管理的理念上的不同，这个可能也与我的工作经历有关，oracle的工作经历是支持客户为主，主要是解决单个环境下的问题，oracle自带的工具可以很方便的定位处理问题。

所以对于平台化管理数据库的概念上基本没有，而对于mysql，面对如此众多的实例，单个的管理肯定是行不通的，要从系统的角度去考虑怎么能自动化，平台化，这样才能节省管理上的支出，而系统化平台化的前提是标准化，没有统一的标准，在后续做平台，系统的时候是非常痛苦的。在标准化的层面，有如何统一的部署，统一的监控，统一的配置，端口管理等等。 

部署结构上 

oracle的部署结构可以很简单，所有高可用，异地备份实现等都可以通过自带组建实现，可选择的余地不是很多，而对于mysql的高可用，有很多实现方式，很多的可选择方式，这个就要看公司是怎么去选型了，有的用mha，有的就自己去实现，所以对mysql来说，在某一方面都有很多的可选项，这个要去评估哪个是最适合自己的，通常这部分也比较占时间，要去做很多测试。 

在业务开发方面

 
       由于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的东西简单很多的，毕竟放的不是强一致性的数据，丢些也可以接受。