DB or Beyond the DB

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

本来想节前把之前Oracle 19c RAC多租户环境授权异常的问题给解决了，已经总结出了一些workaround，但是SR那边还没有给出最终结论。休息了几天，打完了《战锤40K：星际战士2》，手痒就继续写文章，不要背题目吓到了，本期大概率是扯淡。

1 蹭个过气热点

上周，在那5分钟，错过了好几个亿，这里就不详细点名具体事件了。这次故障和之前的故障不同，之前的故障有很多人会怀疑是数据库的问题，而这次就没有听到这样的怀疑，大家都会认为是相关技术人员把代码写错了或者到正式环境中测试了，同样是数据（钱）的问题，为何差别会这么大。
其实这就要从另一个角度看业务逻辑是如何实现的，对于互联网公司来说，快速实现业务需求是重中之重，那么类似于这次补贴的业务上线就只需要在应用侧匹配好参与补贴的消费并扣除对应折扣费用即可（我估摸着这次故障没有匹配消费是否满足条件）。当然写个稍微复杂点的SQL不是不行，但是会带来更多的测试要求（主要是不能影响性能）。而且从互联网公司的IT架构来看，大多数业务逻辑的实现也是放在应用层而不是那么依赖数据库，数据库仅仅是存取数据的地方。
但是为什么在其他的故障里面大家会去怀疑是数据库的问题呢，因为那些故障大多数会涉及多种多样的数据（用户信息、账号密码、钱等等）没了，要么完全不显示，要么慢到超时…当然有些时候应用程序会反馈的更加明显，比如找不到数据库或者数据库异常，这就更好判断了。

2 业务逻辑放哪

既然说到这里了，加上上周和一些圈内好友也讨论到这些了，上次数据库大赛也和很多前辈聊起过，那就是业务逻辑到底该有应用代码来实现还是数据库来实现。

• 应用代码派的观点：业务系统要做单元化、异地多活，业务发展还要经常变更数据模型，数据会在结构化和非结构化中转换，传统的复杂SQL几乎无法实现需求。（来自于DB历史学家司马辽太杰的总结）
• 数据库派的观点：数据都是关联的，加上多模数据库的发展，可以使得原来割裂在不同类型数据库中的数据更加便捷关联在一起发挥价值，同时SQL的上手速度还是比较快的。

其实，还是得回到业务场景或者说就用俩字概括：成本。对于互联网企业IT就是业务，成本自然没有问题，和互联网企业出来的人不要谈成本（来自于白鳝老师的总结）；而很多传统行业，IT就是锦上添花，少了其实影响也没那么大。肯定很多人会觉得，这不是放屁么，离了IT就算是传统行业也无法运转，其实，那么我再引用下梁敬彬老师分享的一个故事：如果哪一天电池技术发生了革新，那么宁德时代是可以完全放弃IT去追赶新技术并扩充对应产能，这时候即便互联网IT再快也跟不上这样的变更。
我觉得，业务逻辑变更快的可以用应用代码来实现，不过转过头去看看应用代码大多数也是简单的SQL再组合结果；而长期稳定的业务或者是一些周期性操作场景确实也可以放到数据库，而且我认为一个好的数据库模型设计虽然很难，但是也能很好的满足业务变更。二者各有优劣，最终还是看实际需求。

3 一根筋变成两头堵

细观很多地方的IT费用，会放在两个地方，一块是硬件，另一块则是应用开发，中间的操作系统、数据库、中间件为啥投入会很少，一方面是习惯了白嫖，另一方面无论是白嫖的商业还是免费的开源都能提供稳定、功能足够的基础软件。而现在国产化的浪潮，并不能在原有使用方式不便的情况下提供相同能力，尤其是数据库，那么这也势必带来了在很多必需的场景下需要降低数据库在业务逻辑实现中的比重，有些本适合数据库去解决的问题被迫用应用代码去解决，这就是另一个方面我们在数据库国产化中需要考虑的成本问题。
但是当国产数据库经过足够的打磨、发展过后，在将来能够提供比肩国产数据库产品的能力的时候，那么架在业务和硬件之间的数据库也需要去完成它的本职工作，打通一根筋的两头。

4 复杂与简单

曾几何时，装一套Oracle数据库并用起来然后用好是一件很复杂的事情，这需要非常专业的DBA（当然现在其实也需要），但是对比一下当下版本Oracle带来的数据库能力，Oracle DB+APEX还是可以解决绝大部分场景需求的；再对比一下互联网IT架构中和数据相关的内容，多种数据库需要应用代码使用多种中间串在一起。两种实现业务需求的思路没有高下之分，有的只是选择。

5 变化

最后再扯点其他的，这个是梁敬彬老师的DBA²和白鳝老师的DBA需要积累的一点现实的感触，作为一个DBA无论是做技术交流，还是解决生产中的实际问题，我不再单纯的从数据库角度去看待问题，很多时候会去了解业务逻辑及实现方式，找到其中的问题，从更高的维度提供更全面的解决方案，这就是题目中的Beyond the DB。这可能就是刘华阳老师说的和大佬混的近，进步比较快。

总结

做DBA需要了解数据库，也要了解运行在数据库上的应用，如何实现业务逻辑，是依靠数据库SQL还是业务代码，取决于场景、行业以及数据库的能力。
老规矩，不知道写了些啥。