第五十五期 DBA

这两天在DBA圈子里有几篇文章比较火，《你怎么还在招聘DBA?》，《云数据库是不是智商税？》，《你怎么不招聘DBA？》和薛大佬刚刚出品的《蹭个热度–要不要DBA和云数据库》。文章的具体内容就请自行搜索了。前面这几篇文章已经对DBA和云数据库进行了广泛的讨论，我也就不好再去重复其中的一些观点，但是对于一些文章里的细节和自己的整体观点还是有几句想说的。

1 数据库管理员

其实回到我文章的第四十五期，第一章节也讨论过“到底需不需要DBA”的问题，有兴趣的可以返回去看看。当然，那一篇文章从标题来看就是《又一期杂谈》，奔着划水去的。但是观点还是很明确，我是站DBA的，但是从我文章一贯的观点来看，又不是那种站所谓仅仅懂数据库维护的DBA。我
认为的DBA是必须要有一种数据库专精，多种数据库熟悉，广泛了解各类数据库特性及用法的，能够合理规划并使用各类数据库；熟悉或了解数据库使用环境全链路，比如操作系统、服务器硬件、网络、存储等；熟悉或有能力去了解业务逻辑，并能够协助开发从业务逻辑层面对数据库使用的不合理进行优化而不仅仅只是去优化索引和SQL等等；等等的复合型专业人才。其实从我文章一直写来，记录自己的工作内容和观点，一直都覆盖了这些内容。

2 数据库

我很赞同大佬的观点，IT建设最大的投入或者浪费是数据库的不合理使用，无论是对某一种数据库的不合理使用（例如之前的“壮汉挤门”），还是整个数据架构对数据库的不合理选择。
之前失业的时候，面试过不少游戏公司，他们使用MongoDB的原因是：行业内都在用这个，我们也就用这个了，这个有啥好的我们也不晓得，开发也不懂，因此需要一个懂点的人来加入团队。其实这种所谓的流行度影响数据库选型的现象是比较常见的，当然我也遇到过用redis跑计算的，原因是没有架构师。
《你怎么还在招聘DBA?》这篇文章里面有个观点，滥用关系型数据库，但是NoSQL数据库何尝不是在被滥用呢，很多时候那些所谓的“架构师”，他们了解的完整架构是必须包含关系型数据库、redis来缓存、ELK存日志、MongoDB存文档、ZK或ETCD搞ID、Hadoop跑大数据…不管实际业务场景需求，不管自己数据量咋样，不管自己用不用得上。
回归我以前文章的观点，数据库选型与使用，必须从实际的业务需求触发，并由一个合格的DBA去引导开发合理的使用这些数据库。而不是完全由开发或者“流行度”引导来搞。

3 云数据库

这里说一下以前使用国内某云RDS遇到的一个问题：有俩RDS，分别位于两个可用区，A是标准版（没有实时高可用，仅有定期备份那种），在比较新的可用区；B是高可用版（除了备份，也可失败转移那种），在较老的可用区。B的CPU、内存资源是A的1.5倍左右，存储都是SSD，算上高可用费用也搞了2倍还多。A之前跑得生产业务，为了更安全，将数据库内容迁移到了B，但是发现性能下降十分严重。在业务和压力一致的情况下，甚至主要SQL执行计划都一致的情况下，B的SQL运行时间就是要长于A，和云厂商确认，云厂商说高可用（说白了就是主备同步）会耗费较多的资源，影响数据库性能。
一个“传统”DBA肯定会说这个结论挺放屁的，但是…似乎没啥办法，上云了在自身力量不够（其实我感觉够也没啥用）的时候只能被云厂商牵着走。这个现象我觉得有两个原因：一是云上卖的东西都是CPU核心数+内存大小+存储种类，其实不通的可用区就跟不通的机房或数据中心一样，很可能不是同一时间建设的，那么划归到提供云算力最基本的硬件资源，比如CPU型号、内存频率、磁盘性能就很可能不一样，那么相同云上规格的两个云服务展现出来的性能也可能有不小的差距，很可能出现花更多的钱获得更低的性能；另一方便则是云上超分现象很严重，比私有云（或者说叫资源池）严重多了，虽然资源动态分配是云上的优势，但是架不住大多数业务高发期时间都比较统一，前前后后各类争用特别是在比较老的可用区里面就比较明显了。
不得不说，云数据库解决了“部署、安装、备份、恢复”这些低价值工作，但是云并不能解决怎么使用数据库的问题，纵使云专家是多么的牛逼，一旦这些专家开始侵入客户业务，那就不仅仅是安全的问题了，而是一纸诉状的问题了。

4 “列强是我自己”？

客观来说，并不是所有的地方都能上云，很多地方是不允许上云的，那么在这些地方私有云（资源池）则用的更多。转过头来说就拿我现在在移动做的工作来说，其实我也算是个使用Oracle多租户环境提供云化数据库资源池的“云”服务商。以前各业务厂商自己维护自己的数据库，没有DBA或者全国共用DBA，现在都整到我这统一维护管理，并在可控的范围内去侵入业务，提供优化建议，这些厂商又能把这些优化成果拿去反推到其他地方的同类项目上（我觉得我还是亏了，该找这些厂商收点顾问费的）。
其实在我看来数据库本身的发展，越来越智能：自动索引、AI自治、快速部署等功能，并不会绞杀掉DBA的工作机会，而是会帮助DBA更好的开展工作并更加专注于更加需要关注的领域，比如数据库架构、业务逻辑等方面，发挥更大的价值。