梁敬彬梁敬弘兄弟出品
往期回顾
未来已来，把握机会，从DBA到DBA²⓵不幸的DBA各有各的不幸
未来已来，把握机会，从DBA到DBA²⓶DBA的‘DB‘非‘数据库‘而是‘数据‘与‘业务‘
未来已来，把握机会，从DBA到DBA²⓷DBA的‘A‘是‘管理员‘也是‘架构师‘
⓸从DBA到DBA²，似乎一切都变简单了
大黄：嗯，Data、Business、Administrator和Architect组成新时代DBA的定义，太精彩了！对了，Administrator和Architect两者的结合是A+A。要不，咱们把新时代DBA称之为DB2A如何。
L：两者的结合不是简单的能力叠加，而是会产生质的飞跃，尤其是在人工智能大模型技术飞速发展的当下，更是如此。所以不应该是A+A，而是A×A，即A²。其实，我早就为新时代DBA想了一个新名词，叫DBA²。这些概念我做了解释，如下表所示。
阿牛：DBA²，这个称谓好，又形象又霸气！对了，L老师，您表格中展示的数据和数据架构，业务和业务架构，听起来有些相似，您能否给我们解释一下。
L：数据与业务是内容，架构是为内容服务的设计，二者相辅相成。
数据是广泛的内容来源，包括业务数据、系统日志和外部数据。数据架构是存储和管理数据的设计，如压缩节省空间、分区优化查询性能、分布式存储提升并发及容错、数据湖存储原始数据、数据仓库清洗后用于分析等。架构根据数据特性优化数据使用效率。
业务是具体操作，比如下单、支付、发货；业务架构则是对这些操作的规划，比如模块化管理订单、库存、物流，或通过服务化设计让模块独立又协作。业务架构还依赖数据架构支持决策。
阿牛：我明白了。对了，咱们系统尚未规划从源头大幅精简优化，所以技术栈繁杂这事短期内无法改变，DBA根本就忙不过来也学不进去。您说如果能从DBA到DBA²，是不是就能有所改观。
L：会的！因为看待问题的角度不同结果自然不同。接下来，我给大家分享第四个案例，关于深入数据架构带来的好处。
D企业由于历史原因，数据库技术栈极为复杂，DBA团队需要掌握多种数据库的操作命令，学不过来也极易混淆出错。对此，我建议他们暂时忘掉数据库，只关注业务和数据。不管是什么数据库，都以业务逻辑为单元，将操作封装成脚本，并形成清单在团队内推广。操作时原则上只允许执行脚本，而非直接输入命令。
阿牛：只执行脚本，不用记操作命令？那确实轻松多了！
L：没错，这样做有几个好处。首先，操作与具体的数据库技术实现脱钩，让团队更顺畅地完成任务。其次，这些脚本通常是团队集体智慧的结晶，质量高、可靠性强。
接下来进入第二阶段，将这些封装脚本迁移到界面上，逐步实现操作的可视化。经过一段时间努力，几乎所有常见的数据库操作都可以在界面上完成，并且增加了许多细节功能，比如操作权限控制、日志记录、申请和审批过程的透明化等。
最终，虽然技术栈没有减少，但是DBA团队的压力却大幅缓解。团队成员变得更加了解数据规律，理解业务逻辑，熟悉架构，整个团队已经从DBA迈向了DBA²。对纷繁复杂的数据库技术栈，他们轻松应对，一笑置之，再也没人说学不过来了。
阿牛：如果团队有人牵头，大家拧成一股绳，确实可以这样啊，很受启发！这是非常巧妙的思路，让团队从琐碎的技术细节中解放出来，去做更有效率、更有意义的事。
L：是的，你总结得很好。既然你提到效率，我继续分享第五个案例，关于熟悉业务架构带来的好处。
还是D企业，在运营中发现类似count(*)这种针对大表的SQL执行频繁极高且性能耗性能巨大。这种情况在各个数据库都普遍存在。如果是以前的做法，DBA们会进各个数据库，查看执行计划，优化表、索引等，逐一解决。
但这次，团队已经升级为DBA²，他们迅速理解了这些SQL的业务含义。原来只是通过记录数判断表中是否有记录——如果有，执行逻辑A；如果没有，执行逻辑B。
了解业务逻辑后，大家意识到，如果只是判断表中是否有记录，根本不需要统计总记录数。只要找到表中的第一条记录即可。如果有记录，值为1；如果没有记录，值为空。通过这种方式，只需定位第一行记录，无需扫描全表，开销自然大幅下降。
大家订下方案后，从SQL测试到上线申请到SQL上线到上线验证，整个过程都在界面上一气呵成。操作者甚至感觉不到不同技术栈数据库的存在，就顺利完成了优化，而最终效果也非常理想。
阿牛：叹为观止！老师，我也悟了！
未完待续…
未来已来，把握机会，从DBA到DBA²⓹DBA²+人工智能（大模型）=无限可能
公众号：收获不止数据库
系列回顾
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
