DB 也可以成为一个系统级别的半仙

都说各行如隔山, 此篇仅献给不要脸的自己,写这个纯属灵感,题目亦是.

DB 本身并非大众思维里面的管管数据库, 敲敲数据库命令, 看看慢查询, 改改SQL, 审核SQL , 那么简单. 其实上都属于 DB的初级级别, DB 的追求的终极水平就是一个系统级别的半仙.

当然当一个半仙也不是那么简单的, 99-81渡难到时没有, 但背锅那必然是常有的事情. 成为半仙也是要从背锅开始,例如可能因为莫名的硬件问题, 你的数据库就不稳定了,此时你就的化身为除了DB 层次以外的, 系统级别的专业或非专业认识,将自己从泥潭里面"择"清楚, 所谓莲花出污泥而不染.

或者系统本身设计的漏洞百出, 你也要变换角色,从架构的某些层次来看反应在你数据库的问题, 这当然不是简简单单会看个慢SQL能解决的问题, 因为那样太LOW了.

从某个系统设计之初,其实作为DB 就已经大概了解这个系统设计人员的层次和知识水平了. 例如将一堆应用系统,架设在一台 ORACLE 的架构师和应用开发,你就知道他的水平如何了, 因为这样的系统,要不就是没数据, 没并发,随便搞搞,糊弄领导, 要比就是在作死, 在程序设计初期根本不考虑并发, 扩展,只能说明这个设计人员,道航尚浅. 

在往深层次去,就是看系统中的表设计和业务的逻辑结构之间的问题, 例如一个系统表完全要根据三范式来设计, 那你就要预想到,很可能因为业务复杂,你的一个查询就会变成 N 个表的 LEFT JOIN , 系统的性能如何. 

一个系统设计,尤其复杂系统的设计,在数据库中的体现, 表如何分冷热, 某些字段是否要冗余, 有些数据存储是否要分库分表, 数据存储的格式,是传统还是JSON.  数据库要不要解耦, 程序在使用多种数据库时是不是要解耦, 等等. 系统设计初期,到底那个数据库适合这个系统,这个系统到底可能会涉及几种数据库, 那种高可用方式可以被接受, 设计的能耗比在哪里,界限在哪里.

此时,DB 要不是一个半仙, 那就只能听命于人, 然后我们就继续背锅.

可能修炼成半仙的路途, 一口口大黑锅,就是你修炼的过程, 一次次的涨见识,一次次的升级打怪, 认识到一个个曾经踏平的坑, 就是成仙的筋斗云.

在认知了这一切后,就可以开始反客为主了, 熟悉多种的数据库,以及其功能特性, 哪些数据库适合出现在那个场合, 哪个功能可以解决那个问题, 哪个数据库的弱势在哪里, 为某些数据库扬长避短,在系统成型前就介入到系统的设计当中,而不是为了用数据库而用数据库, 最终不是拿着一把剑,从头杀到尾, 就是成仙的领一个境界了.

举例, 当你某一耳朵,听到VARCHAR(xxxx) 的设计时,并且还是在一个OLTP系统中频繁调用, 第一个反应是什么及后续的顺序是什么

1 这个设计的需求是什么

2 他为什么要这样设计

3 这个设计在系统中承接了什么,要不要查询,要不要UPDATE

4 是冷数据还是HOT 数据

5 哪种数据库我就可以忍了, 哪种打死都不行

6 哪个系统能容忍,哪个系统不能容忍,目前系统的底线是什么

7 有没有化解的方法, 例如在本数据库就地解决, 还是利用其他数据库联合解决, 或者,直接上到业务逻辑,看看合理不合理, 如果能从需求上就灭绝他,那就再好不过了.

所以何时能将自己练就出火眼金睛, 一眼识别出XX的行为, 并且能在利用数据库原理,特殊功能, 技巧,规范,加上口吐莲花的辅助功能, 等等将一个个 "牛鬼蛇神" 挡在门外的时候, 可能就开始要成仙了.